[KDE/Mac] Review Request 120319: Make Kate mousewheel zoom feature respect the corresponding global setting (KGlobalSettings::wheelMouseZooms())

Tue Sep 23 19:20:07 UTC 2014

> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20140923/74762ba8/attachment.html>