> On Sept. 23, 2014, 5:01 p.m., Thomas Lübking wrote: > > Qt cannot "distiguish" because there's nothing to distinguish - the driver > > generates synthetic wheel event for the inertia. > > You can btw. turn that <censored> off. > > > > Seems an issue with inertial scrolling on X11 as well > > https://bugs.freedesktop.org/show_bug.cgi?id=38909 > > Otherwise i'd have opted for "the driver shall please stop this when you > > hit a key". > > > > On a random note, I can't find that setting in systemsettings? > > If there's a config GUI for this, aligning to it seems reasonable, BUT does > > no way fix the actual issue w/ inertia (ie. "you don't have control over > > your input device") > > René J.V. Bertin wrote: > You may not believe it, but I actually prefer the UE with the feature on. > Probably because it saves me some movements, which is always good (less RSI). > > Yes, I imagine that the issue can occur on Linux as well if inertial > scrolling works the same way there. It just never bit me on Linux - and yet I > run that on underpowered machines ... > Might be a thought to define the modifier key to get wheelMouseZooms in > that case, or at least make that possible somewhere in systemsettings? > > You're right, I haven't been able to find the setting in systemsettings. > The setting *is* part of the standard settings, though, no idea why it > slipped through and remained a hidden setting. But because it's part of the > standard settings I went with aligning to it, instead of hacking in a new > switch as in Konsole. > NB, seems likely that Konsole offers its own switch because the authors > didn't go the length I did to find out about the one in `kdeglobalrc`? > > Thomas Lübking wrote: > UX isn't my concern - but doing that in the driver is simply idiotic. > (Sorry, but hey - Peter H. shares that opinion ;-) > What eg. happens when you reached the end of the document? The driver > keeps scrolling and you don't even notice that. > > Either the view provides inertic scrolling or you purchase a rodant that > can alter between swing and precise wheel (w/o trying to advertise here, eg. > Logitech M500 is an affordable device with this capability) > > Choosing another modifier won't help, but at best move the problem around > (ok, there's no META key on OSX, but it is indeed used for shortcuts on > linux/windows - often global ones. So instead of scaling the text, you end up > scaling the entire desktop ;-) > > While I personally don't use text scaling in kate (this way), if there's > no present UI for the global config, it can hardly be used and we can't (?) > introduce config GUI for the kate part in SC4, I assume (kate devs will know > better) > Also simply disabling a feature because it is *one* occasion of a driver > issue doesn't sound too reasonable - what if I'd in general like to scale the > text this way but am still annoyed by the driver behavior? > > One way to deal with this is to measure the time between the last > unmodified wheel event and the now modified wheel event. If that is too low > to be reasonably caused by a human being (ie. the scroll "started" unmodified > and suddenly a modifier kicks in) one could ignore the modifier. > That would however have to apply to all items. > Stupid question: how does (Qt)WebKit behave (eg. in qt-assistant?) in > this regard? > > René J.V. Bertin wrote: > I use Apple's Magic Trackpad, no spamming intended, but I wouldn't want > to change for anything else anymore... > > > ok, there's no META key on OSX > > There is. META is mapped to Ctrl by default on OS X (and CTRL to Command, > which is the real Meta key), but there is a setting to switch that back. I > presume the default is conceived to reflect the fact that OS X uses the > Command key in place of Ctrl for shortcuts. It apparently never occurred to > them to define a special code (`ACCEL`) for the standard accelerator "opcode" > ;) > > > Also simply disabling a feature because it is one occasion of a driver > issue doesn't sound too reasonable > > How do you think I found the global setting and how to read it out? It's > used exactly this way in KTextEdit (see `KTextEdit::wheelEvent`) which again > raises the question why the setting isn't exposed in systemsettings. > > > - what if I'd in general like to scale the text this way but am still > annoyed by the driver behavior? > > The only solution in that case would be to configure the feature to use > another key or key combination, one that works for you and your workflow and > doesn't risk to get triggered unexpectedly. > > > Stupid question: how does (Qt)WebKit behave (eg. in qt-assistant?) in > this regard? > > Not so stupid: Qt does exactly the same thing, and it doesn't appear to > be optional in any way there. This is probably why `KTextEdit` overrides the > `wheelEvent` it inherits from the parent Qt widget.
BTW: > What eg. happens when you reached the end of the document? The driver keeps > scrolling and you don't even notice that. But the view knows. On iOS and newer OS X versions it actually bounces when this happens. Which is why I learned that I prefer the inertial scrolling, because I tried switching it off to get rid of the bouncing and felt like handicapped. BTW, the OS X driver's inertial feature can be stopped very easily: swipe to get the view to scroll; place back 2 fingers and the scrolling stops at once. Exactly as it did with the big thumb trackball I had before. - René J.V. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120319/#review67302 ----------------------------------------------------------- On Sept. 22, 2014, 5:16 p.m., René J.V. Bertin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120319/ > ----------------------------------------------------------- > > (Updated Sept. 22, 2014, 5:16 p.m.) > > > Review request for Kate, KDE Software on Mac OS X and kdelibs. > > > Repository: kate > > > Description > ------- > > KDE has a global text editor option that can be used to let Ctrl-MouseWheel > events zoom the text font being used. Kate does not respect this setting, > which is an omission that can lead to unexpected behaviour. > > On OS X, the feature works slightly differently in the sense that > `Qt::ControlModifier` does not designate the control key, but the command (?, > Apple) key. In addition, Qt's event handling does not appear to be able to > distinguish between scrolling under direct control, and residual scroll > movement that's due to simulated inertia. As a result, any attempt to use a > keyboard shortcut while a text view has not stopped moving completely will > lead to text zooming. > See https://bugreports.qt-project.org/browse/QTBUG-41475 . > > At first I thought to replace `Qt::ControlModifier` with `Qt::MetaModifier` > on OS X but that would probably require changes in many locations, and thus > best be preceded by a design decision if the standard shortcut modifier key > ought not be referenced via a symbolic platform constant not named after a > specific key, instead of being hardcoded (and using a key name). > > Therefore, I present a small patch that checks > `KGlobalSettings::wheelMouseZooms()` when the platform's `ControlModifier` is > held and a wheel event received. > > An alternative solution could introduce a Kate-specific setting (just like > Konsole has one), but that would require far more changes. > > > Diffs > ----- > > part/view/kateviewinternal.cpp a2906f3 > > Diff: https://git.reviewboard.kde.org/r/120319/diff/ > > > Testing > ------- > > On OS X against kdelibs 4.14.1 (git/kde4). The change consists of an > additional call to a standard kdelibs function which I do not expect to > introduce regressions on any platform. > > I looked at kate's git/master code, which lacks a `wheelEvent` handler > suggesting the feature works differently there. However, Qt 5.3.1 > applications (like Digia's own Qt Creator) still suffer from the phenomenon > described above, so a fix would be beneficial for KF5 too) > > > Thanks, > > René J.V. Bertin > >
