Review Request 120319: Make Kate mousewheel zoom feature respect the corresponding global setting (KGlobalSettings::wheelMouseZooms())

[Thomas Lübking]

> On Sept. 23, 2014, 3:01 nachm., 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`?

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?


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120319/#review67302
-----------------------------------------------------------


On Sept. 22, 2014, 3:16 nachm., 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, 3:16 nachm.)
> 
> 
> 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-core-devel/attachments/20140923/7ac702dc/attachment.htm>