> 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`? > > 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. > > René J.V. Bertin wrote: > 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. > > Dominik Haumann wrote: > Did you reach any consensus about this patch? If this is not going in, it > should be discarded. > > René J.V. Bertin wrote: > Good question, I guess that we both forgot about the whole thing ... > Thomas? > > Thomas Lübking wrote: > I still oppose the idea to try to fix this in client code. > > a) the setting is KDE4/support only, ie. deprecated code anyway > b) there's apparently no config GUI for that setting?! > => secret workaround > c) You suggested that (all?) Qt5 applications suffer from this problem > (where we cannot even involve this solution -> problem globally remains. Let > alone gtk+ etc. clients) > d) The setting can no more be used to prevent eg. accelerated scrolling > (which it originally selected) > e) There may be random custom handling of modifiers on wheel events > everywhere - and they all needed to be stripped/made configurable at least. > > > Let alone that faking scroll inertia in the server is silly itfp. > > a) The server must either simply stop faking inertia with the next > keyboard/crossing event (while apparently that's not simple on evdev) or > (rather) scrolling inertia has to be done in the client (w/o faking input > events) > b) Eg. when I scroll and move the mouse to another window or just > scrollview while the inertia faking is going on, I suddenly scroll the other > window/view? (the view is not "fixable" on serverside inertia faking) > c) Do I really want scrolling inertia on the destkop to change virtual > desktops? > > René J.V. Bertin wrote: > a) yay, stable release code that actually allows you to get some work > done without fearing whatever tomorrow's update might break. Fixing naggles > in KDE4 is like showing love to unknown hordes of users who stick with LTS or > non-Linux distributions for good reasons. > b) So? If that's really a serious issue for you (you know what vi[m] is, > right? :P) then there's always the possibility to add a setting to Kate that > is first-time initialised off the global setting and then maintained > independently. > c) I haven't checked with Qt5 for this since I created the RR, nor KF5 > applications so I don't know to what extent my claim still stands, nor why > the proposed fix wouldn't work there. (I'd hope there's something comparable, > in fact, I seem to recall that Qt also has a "should the mouse wheel zoom" > setting.) But we're talking about a KDE4 application here in which the issue > is particularly noticeable (to me). KDE. 4. Not GTk or anything else. > d) eh? The setting I use is called `KGlobalSettings::wheelMouseZooms()`. > I don't see what that has got to do with accelerated scrolling, nor how > checking the setting prevents that kind of scrolling? > e) again, so? This is a patch for Kate. It's not intented to cure all > pain in the world, but it could show how this issue can be tackled to others > who're bothered by it in a random other application. > > a) I don't agree and also think neither of us gets to dictate what the > server may not or must do. Besides ... what server, on platforms that don't > use X11? > b) I don't know what happens to you, but in my case on OS X this is not > possible because the inertial scrolling stops as soon as I move the pointer. > It does not when I press or release a key, and I think that's rightly so. I > could in fact find a use for such an event in Kate (like the accelerated > scrolling you mentioned). > c) ditto. (In fact, you actually want to disable virtual desktop change > coupled to mouse *movement* that's not part of a multi-touch gesture, trust > me ;)) > > Thomas Lübking wrote: > a) and will see maybe one more release - at best. > b) this typically means "my secret pet feature workaround with no use for > anyone else" - if it's so important, it must be exposed to the common user. > c) kdeglobals is gone (ok, deprecated to kdelibs support) and this > setting isn't invoked by any QPA - what you set here has no whatsoever impact > on plain Qt5 applications. > d) look up the code, the comment describes the history of the feature. > e) this means you seriously want to fix clients one-by-one by stripping > features instead of simply addressing to core culprit? > > -- > > a) I don't dictate, but merely state sane behavior. If OSX btw. fakes > this through a common input lib, it could just as well fix it there (despite > the feature belongs into the clients) > b) I frankly would have to try, but then the solution is simple: slightly > move the mouse before pressing a modifier... > c) what "ditto"? if i'm above the desktop and rotate the wheel by > one/two/three iteration/s, I expect to end up one/two/three desktops ahead, > not 13 or 25. I'm talking about a mouse wheel, not a touch device (which > isn't controllable itr. anyway) > > > You may have a point though in that altering the font scale (or anything > like that) is of no use from a touch device, because it can/does not generate > clean wheel clicks. > However, the proper™ solution is then to base this behavior on the nature > of the input device and/or eg. ignore scroll events for such behavior when > many™ of them occur in short™ time. > Not some obscure and deprecated setting that you luckily happen to know. > > René J.V. Bertin wrote: > I've got better things to do than keep up a tit-for-tat dialogue, but I > do not agree that simulating inertial scrolling is anything but the "event > server's" business. That's not any less the case than that it's some server's > role to provide access to any other kind of events, or fonts. > What's more, that event server probably has access to lower-level > information from the input device anyway, and can use that information to > determine whether simulation is needed or not (a trackball wouldn't require > it). And above all, it can provide the simulated events in a consistent > manner across all clients. > > But I'm not going to insist ... nor feel inclined to discard this request > because there's only been feedback from a single person who has failed to > come up with (AFAIC) convincingly valid arguments against my change.
> that event server probably has access to lower-level information from the > input device anyway Which it can (and does) easily pass downstream while it completely lacks (by nature) private client detail informations. > it can provide the simulated events in a consistent manner across all clients What apparently leads to glitches. You however completely ignored any technical issues - and suggestions. Reading across https://bugs.freedesktop.org/show_bug.cgi?id=38909 again, it seems the faked events have a higher valuator (scrollDistance) than usual. If that's the same on OSX, it could be used (next to an absurd frequency?) to control the feature. Relying on a deprecated and hidden config key is no solution at all - I'm sorry if that doesn't convince you. - 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 > >
