Re: High-resolution scroll events
Hi!, On Wed, 2010-11-17 at 13:29 +0100, Max Schwarz wrote: Hi, I'm currently developing patches for the X11 ecosystem to provide higher- resolution scrolling for devices that support it (touchpads, trackpoints, etc). My patches are kept in a github repo ([1]). Was aware of your work, awesome stuff. It looks like my patch will get merged into Xorg eventually (see my thread over at xorg-devel [2]) and I wanted to have a first look at GTK/GDK and how to implement support there. It seems to me that the crux of the matter is the GdkEventScroll, which has no way of specifying the precise amount to scroll. It's just emitted for each old-style scroll tick. Do you have an idea on how to implement this? I think Qt's model is quite nice, they have a 'delta' field in their event [3] which gives more precise information. Of course, If you want to retain API compability (which I think you do) a new event would have to be introduced that is emitted in parallel. Thoughts? How do you think packing both old and new information in the same event struct work? the current GdkScrollDirection could remain as a hint. I don't know the rate difference in the emission of both events, so perhaps apps relying on the old behavior could get far too fast (or slow) scrolling. As for how the information could be stored, I see you went for implementing a single valuator with the delta value, IMHO it'd be great have both delta and angle, so two finger scrolling in touchpads could happen both horizontally and vertically within a single event whenever there is support for that beneath GTK+. Also, I think delta in QWheelEvent feels to tied to hardware details, I think it'd be simpler to have the event's delta represent a real distance in the screen, say in pixels. Cheers, Carlos Thanks, Max [1]: http://github.com/x-quadraht/pscroll . [2]: http://www.mail-archive.com/xorg-de...@lists.x.org/msg14536.html [3]: http://doc.qt.nokia.com/4.7/qwheelevent.html#delta ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: High-resolution scroll events
Hi, Am Mittwoch, den 17.11.2010, 13:29 +0100 schrieb Max Schwarz: Do you have an idea on how to implement this? I think Qt's model is quite nice, they have a 'delta' field in their event [3] which gives more precise information. Of course, If you want to retain API compability (which I think you do) a new event would have to be introduced that is emitted in parallel. No, you don't have to. Here is a patch for the Mac OS X backend which implements this. (Let me check tonight whether I can find my cleaned up version and attach it to that bug.) https://bugzilla.gnome.org/show_bug.cgi?id=516725 Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: High-resolution scroll events
On Wed, Nov 17, 2010 at 7:29 AM, Max Schwarz m...@x-quadraht.de wrote: Do you have an idea on how to implement this? I think Qt's model is quite nice, they have a 'delta' field in their event [3] which gives more precise information. Of course, If you want to retain API compability (which I think you do) a new event would have to be introduced that is emitted in parallel. just as a confirmation, OS X does the same thing with scroll events there. its quite irritating to have to convert a single scroll event in quartz into N different GDK scroll events in order to maintain the effect of a large delta value. i would be very happy to see GDK gain a delta field for scroll events. --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: High-resolution scroll events
On Wed, Nov 17, 2010 at 9:56 AM, Sven Herzberg he...@gnome-de.org wrote: No, you don't have to. Here is a patch for the Mac OS X backend which implements this. (Let me check tonight whether I can find my cleaned up version and attach it to that bug.) https://bugzilla.gnome.org/show_bug.cgi?id=516725 heh :) sven, sorry i dropped the ball on that. glad that you were able to finish it off. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: High-resolution scroll events
Hi, Do you have an idea on how to implement this? I think Qt's model is quite nice, they have a 'delta' field in their event [3] which gives more precise information. Of course, If you want to retain API compability (which I think you do) a new event would have to be introduced that is emitted in parallel. No, you don't have to. Here is a patch for the Mac OS X backend which implements this. (Let me check tonight whether I can find my cleaned up version and attach it to that bug.) But that would mean changing the frequency of the events, correct? For every small wheel delta a new event has to be sent. Can current software cope with that? I'd expect that it starts scrolling wildly ;-) The problem is not with large deltas (which are thrown away in the current OSX version, if I understand the patch correctly), but with small deltas, which get emitted from Xorg with a pretty high frequency. Max ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: High-resolution scroll events
On Wed, Nov 17, 2010 at 10:25 AM, Max Schwarz m...@x-quadraht.de wrote: The problem is not with large deltas (which are thrown away in the current OSX version, if I understand the patch correctly), but with small deltas, which get emitted from Xorg with a pretty high frequency. my initial response to this was sent by completely forgetting what i had done with the original version of the patch. so no, its not true that anything is thrown away. the patch actually adds a new field to scroll events, so that they can have the same semantics as the events on win and quartz. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: High-resolution scroll events
Am Mittwoch, 17. November 2010, um 16:40:16 schrieben Sie: On Wed, Nov 17, 2010 at 10:25 AM, Max Schwarz m...@x-quadraht.de wrote: The problem is not with large deltas (which are thrown away in the current OSX version, if I understand the patch correctly), but with small deltas, which get emitted from Xorg with a pretty high frequency. my initial response to this was sent by completely forgetting what i had done with the original version of the patch. so no, its not true that anything is thrown away. the patch actually adds a new field to scroll events, so that they can have the same semantics as the events on win and quartz. That's correct, but the un-patched port throws away large deltas (there's a break; in there somewhere), and you got around it by storing the deltas in the events. What do you do with small -0.0001/+0.0001 deltas from Xorg? That's the question. If you forward it in GdkEventScroll (and optionally encode that in the proposed delta field), old applications end up getting many GdkEventScroll events, which they interpret as regular scroll events. Result: you scroll a mile when you just move your finger a little bit :-( That's the problem I see. Or is the only receiver of the events GTK itself (GtkRangeco)? Then it would be possible to patch it all at once... Thanks to all for your fast feedback ;-) Max ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: High-resolution scroll events
On Wed, 2010-11-17 at 16:53 +0100, Max Schwarz wrote: Am Mittwoch, 17. November 2010, um 16:40:16 schrieben Sie: On Wed, Nov 17, 2010 at 10:25 AM, Max Schwarz m...@x-quadraht.de wrote: The problem is not with large deltas (which are thrown away in the current OSX version, if I understand the patch correctly), but with small deltas, which get emitted from Xorg with a pretty high frequency. my initial response to this was sent by completely forgetting what i had done with the original version of the patch. so no, its not true that anything is thrown away. the patch actually adds a new field to scroll events, so that they can have the same semantics as the events on win and quartz. That's correct, but the un-patched port throws away large deltas (there's a break; in there somewhere), and you got around it by storing the deltas in the events. What do you do with small -0.0001/+0.0001 deltas from Xorg? That's the question. If you forward it in GdkEventScroll (and optionally encode that in the proposed delta field), old applications end up getting many GdkEventScroll events, which they interpret as regular scroll events. Result: you scroll a mile when you just move your finger a little bit :-( That's the problem I see. Or is the only receiver of the events GTK itself (GtkRangeco)? Then it would be possible to patch it all at once... Most application code probably doesn't use GdkEventScroll directly. It's handled inside GTK+ for things like scrolled windows. But some applications and some libraries might use GdkEventScroll for something clever. I know vte uses it to let your scroll wheel work in programs like less. If we break API on this, I think it would be best to do it in a way that the compiler catches it. Just adding a field to GdkEventScroll will trip up a lot of developers. -- Shaun McCance http://syllogist.net/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: High-resolution scroll events
On Wed, Nov 17, 2010 at 11:17 AM, Shaun McCance sha...@gnome.org wrote: If we break API on this, I think it would be best to do it in a way that the compiler catches it. Just adding a field to GdkEventScroll will trip up a lot of developers. Not really. There is (1) no change in the structure size (2) no change in (current) X11 semantics. Now, if X11 starts supplying delta information, then there is scope for a real API break, because rather than receiving N different scroll events for a large scroll motion, the app would only get one. This would only affect apps that use scroll events directly, as you noted, and the fix for their code would be very simple. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: High-resolution scroll events
Hi, Am Mittwoch, den 17.11.2010, 16:25 +0100 schrieb Max Schwarz: Do you have an idea on how to implement this? I think Qt's model is quite nice, they have a 'delta' field in their event [3] which gives more precise information. Of course, If you want to retain API compability (which I think you do) a new event would have to be introduced that is emitted in parallel. No, you don't have to. Here is a patch for the Mac OS X backend which implements this. (Let me check tonight whether I can find my cleaned up version and attach it to that bug.) So, I updated to patch to something that applies to the current master branch. But that would mean changing the frequency of the events, correct? For every small wheel delta a new event has to be sent. Can current software cope with that? I'd expect that it starts scrolling wildly ;-) Not at all. Because the widgets (usually) only modify GtkAdjustment and with that patch, the modification gets scaled with delta. So, if you emit 10 times more events and let them have a delta of 0.1, you'll still have the same effect (except for broken implementations outside of GTK+, but those will be pretty obviously broken in the way that they will scroll in huge steps and it will be difficult to accurately scroll at all -- those will have to be fixed to respect delta as well). The problem is not with large deltas (which are thrown away in the current OSX version, if I understand the patch correctly), but with small deltas, which get emitted from Xorg with a pretty high frequency. No, right now we implement the current X11 logic of scrolling on Mac OS X as well. There used to be multiple GdkEvents per NSEvent (but that didn't work out properly and thus, way reverted). So, feel free to go ahead with the patch I attached and you will see that applications without custom widgets work perfectly once you adapt the X11 backend of GDK to use the delta field as well. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
