Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
Hey, In order to provide some background to the ML, scroll events were being sent to widgets with GDK_BUTTON_PRESS_MASK (no scroll mask required), but this played odd with smooth scrolling as scrolled windows get scroll events in 2 ways: 1) bubbled up from the child within 2) received directly via priv-overshoot_window, only if no child handles scrolling With the old behavior, 1) would happen on every widget that would handle button presses, but not necessarily scrolling, so scrolling in a viewport or textview (handling smooth scroll) with eg. buttons (handling just button presses) would intermittently coerce smooth and non-smooth scrolling depending on the widget below the pointer, the weighted solutions were: 1) Requiring apps to set GDK_SMOOTH_SCROLL_MASK on *every* widget within a scrolled window if they want smooth scrolling, or face odd behavior 2) Changing GDK so scroll events are only sent if GDK_[SMOOTH_]SCROLL_MASK is in the evmask. Both options required changes to applications (different sets though), and there are likely way more applications with custom UIs within a viewport than custom scrollable widgets out there, so 2) was chosen On jue, 2012-03-15 at 12:52 -0400, Colin Walters wrote: On Thu, 2012-03-15 at 08:10 -0400, Matthias Clasen wrote: Thanks for bringing these up. I'm sure there will be some more fallout from the xi2 changes. I don't know if we'll be able to have perfectly seamless compatibility in the scroll event case, there are some complications that make that hard. But do you have a global sense of whether we should at this point: 0) Patch affected applications I think that should be done anyway for coherence (if you expect scroll events, setting the scroll mask shouldn't hurt). I could just count 3 custom scrollable widgets in gnome outside of gtk (webkit, g-t and gucharmap), so it shouldn't be a big effort either. 1) Pursue hacks (or non-hacks?) in GTK+ to improve compatibility 2) Make it opt-in Hard to come up with a compatible solution, even if smooth scrolling is optional. Carlos ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
Em Fri, 2012-03-16 às 12:51 +0100, Carlos Garnacho escreveu: Hey, In order to provide some background to the ML, scroll events were being sent to widgets with GDK_BUTTON_PRESS_MASK (no scroll mask required), but this played odd with smooth scrolling as scrolled windows get scroll events in 2 ways: 1) bubbled up from the child within 2) received directly via priv-overshoot_window, only if no child handles scrolling With the old behavior, 1) would happen on every widget that would handle button presses, but not necessarily scrolling, so scrolling in a viewport or textview (handling smooth scroll) with eg. buttons (handling just button presses) would intermittently coerce smooth and non-smooth scrolling depending on the widget below the pointer, the weighted solutions were: 1) Requiring apps to set GDK_SMOOTH_SCROLL_MASK on *every* widget within a scrolled window if they want smooth scrolling, or face odd behavior 2) Changing GDK so scroll events are only sent if GDK_[SMOOTH_]SCROLL_MASK is in the evmask. So gtk_widget_add_events (widget, GDK_SCROLL_MASK); for every widget for which we want the old behaviour back, correct? Sounds doable by 3.4. snip 0) Patch affected applications I think that should be done anyway for coherence (if you expect scroll events, setting the scroll mask shouldn't hurt). I could just count 3 custom scrollable widgets in gnome outside of gtk (webkit, g-t and gucharmap), so it shouldn't be a big effort either. There's a gazillion pieces of code that use scroll events and that'll need updating. The smaller the quick fix, the better. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
On vie, 2012-03-16 at 12:56 +0100, Bastien Nocera wrote: So gtk_widget_add_events (widget, GDK_SCROLL_MASK); for every widget for which we want the old behaviour back, correct? Sounds doable by 3.4. Exactly, it's pretty much that snip 0) Patch affected applications I think that should be done anyway for coherence (if you expect scroll events, setting the scroll mask shouldn't hurt). I could just count 3 custom scrollable widgets in gnome outside of gtk (webkit, g-t and gucharmap), so it shouldn't be a big effort either. There's a gazillion pieces of code that use scroll events and that'll need updating. The smaller the quick fix, the better. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
Le 16/03/2012 12:56, Bastien Nocera a écrit : So gtk_widget_add_events (widget, GDK_SCROLL_MASK); for every widget for which we want the old behaviour back, correct? Sounds doable by 3.4. Well old behaviour back, you will still not get GDK_SCROLL_UP,DOWN events so any code checking for those will need updating. Speaking about trivial it's not really, it took 5 patches to nautilus, one of the patches created a segfault and there are still issues unsorted after that. Grepping though GNOME sources there is at least 15 sources that will need to be patched, that also doesn't include out of GNOME softwares... -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
Le 16/03/2012 13:33, Sebastien Bacher a écrit : Grepping though GNOME sources there is at least 15 sources Ryan came with a list built from precise gtk3 rdepends which includes those components: abiword anjuta-extras brasero cheese epiphany-browser eog evince evolution gedit glade gdm ghex gnome-applets gnome-control-center gnome-documents gnome-panel gnome-utils goocanvas gtk-vnc gucharmap libwnck nautilus notification-daemon rhythmbox seahorse totem vte webkit There is about the same number of source out of GNOME, including sources like cairo-dock, bluefish, libreoffice, ... -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
W dniu 16 marca 2012 13:33 użytkownik Sebastien Bacher seb...@ubuntu.com napisał: Le 16/03/2012 12:56, Bastien Nocera a écrit : So gtk_widget_add_events (widget, GDK_SCROLL_MASK); for every widget for which we want the old behaviour back, correct? Sounds doable by 3.4. Well old behaviour back, you will still not get GDK_SCROLL_UP,DOWN events so any code checking for those will need updating. Shouldn't that be the case unless you explicitly ask for GDK_SMOOTH_SCROLL_MASK? -- Patryk Zawadzki I solve problems. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
On Fri, Mar 16, 2012 at 8:50 AM, Patryk Zawadzki pat...@pld-linux.org wrote: W dniu 16 marca 2012 13:33 użytkownik Sebastien Bacher seb...@ubuntu.com napisał: Le 16/03/2012 12:56, Bastien Nocera a écrit : So gtk_widget_add_events (widget, GDK_SCROLL_MASK); for every widget for which we want the old behaviour back, correct? Sounds doable by 3.4. Well old behaviour back, you will still not get GDK_SCROLL_UP,DOWN events so any code checking for those will need updating. Shouldn't that be the case unless you explicitly ask for GDK_SMOOTH_SCROLL_MASK? Yes, that should be the case ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
On Fri, Mar 16, 2012 at 8:43 AM, Sebastien Bacher seb...@ubuntu.com wrote: Le 16/03/2012 13:33, Sebastien Bacher a écrit : Grepping though GNOME sources there is at least 15 sources Ryan came with a list built from precise gtk3 rdepends which includes those components: abiword anjuta-extras brasero cheese epiphany-browser eog evince evolution gedit glade gdm ghex gnome-applets gnome-control-center gnome-documents gnome-panel gnome-utils goocanvas gtk-vnc gucharmap libwnck nautilus notification-daemon rhythmbox seahorse totem vte webkit There is about the same number of source out of GNOME, including sources like cairo-dock, bluefish, libreoffice, ... Thanks for keeping us honest. Our rule of thumb has been: 'Only gnome3 uses gtk3 so far, thus we can get away with bending some compatibility rules in the name of a better future'. Clearly, that is (beginning to) change. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
Le 16/03/2012 13:50, Patryk Zawadzki a écrit : Shouldn't that be the case unless you explicitly ask for GDK_SMOOTH_SCROLL_MASK? Well then maybe there is a bug in GTK with scale widgets, sliders stopped reacting to up,down scroll events i.e in the control center sound panel... -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
On vie, 2012-03-16 at 13:59 +0100, Sebastien Bacher wrote: Le 16/03/2012 13:50, Patryk Zawadzki a écrit : Shouldn't that be the case unless you explicitly ask for GDK_SMOOTH_SCROLL_MASK? Well then maybe there is a bug in GTK with scale widgets, sliders stopped reacting to up,down scroll events i.e in the control center sound panel... http://git.gnome.org/browse/gtk+/tree/gtk/gtkrange.c#n2819 maybe dx is mistakenly non-0 in evdev's wheel up/down? -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
On Wed, Mar 14, 2012 at 2:17 PM, Sebastien Bacher seb...@ubuntu.com wrote: Hi everyone, GTK 3.3.18 and smooth scrolling landing created quite some issues which seems to have been mostly unnoticed, unaddressed so far, since the hard freeze for GNOME 3.4 is next week I'm bringing the topic there. Some of the details there might be wrong and I'm happy to be corrected, it's just my understanding of the changes * widgets need to opt-in for scroll events (GDK_SCROLL_MASK), that makes scrolling stop working in applications using custom widgets (example: http://git.gnome.org/browse/nautilus/commit/?id=04116ab2876412445c788091be07d7f7321a4a94) * if you are on xserver 1.12 with xinput 2.2 your application stop receiving GDK_SCROLL_DOWN and GDK_SCROLL_UP events, but receive GDK_SCROLL_SMOOTH with an increment instead that change seems to create quite some issue, it breaks for example mouse wheel scrolling over sound sliders in the control center, or scrolling in nautilus compact view Grepping around in my work tree I see there are quite a lot of GNOME components using GDK_SCROLL_UP,DOWN, I guess those will stop working as they should. Nautilus fixed a such issue in http://git.gnome.org/browse/nautilus/commit/?id=1a76e044a2c9b834d00c4ea30f1e3af3321d8cdd It's likely that other applications will need to add extra cases to handle the new way I think that's an issue we should look at addressing before 3.4, either by doing some compat work in GTK (i.e keep emiting the scroll up down events as well as the smooth ones if possible) or by patching the applications, the rdepends list is likely not trivial though... Thoughts? Thanks for bringing these up. I'm sure there will be some more fallout from the xi2 changes. I don't know if we'll be able to have perfectly seamless compatibility in the scroll event case, there are some complications that make that hard. Unfortunately, I have no time at all this week to dive into this; so any help in diagnosing and coming up with fixes will be appreciated. You could also ask Carlos if he has time to look. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
On Wed, Mar 14, 2012 at 06:24:02PM -0500, Diego Escalante Urrelo wrote: This explains why gnome-terminal does not scroll with the mouse wheel for me now. Fixed in vte: https://bugzilla.gnome.org/show_bug.cgi?id=671305 -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
On Thu, 2012-03-15 at 08:10 -0400, Matthias Clasen wrote: Thanks for bringing these up. I'm sure there will be some more fallout from the xi2 changes. I don't know if we'll be able to have perfectly seamless compatibility in the scroll event case, there are some complications that make that hard. But do you have a global sense of whether we should at this point: 0) Patch affected applications 1) Pursue hacks (or non-hacks?) in GTK+ to improve compatibility 2) Make it opt-in ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
On Thu, 2012-03-15 at 12:52 -0400, Colin Walters wrote: But do you have a global sense of whether we should at this point: 0) Patch affected applications 1) Pursue hacks (or non-hacks?) in GTK+ to improve compatibility 2) Make it opt-in Are there some rough docs on the new scrolling stuff? Even pointers to the relevant commits? I can work on adding some event masks for compatibility, or whatever - make old-style apps get the discrete events they expect, and new apps can opt in for smooth scrolling events. Or something like that. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
Em Wed, 2012-03-14 às 19:17 +0100, Sebastien Bacher escreveu: snip I think that's an issue we should look at addressing before 3.4, either by doing some compat work in GTK (i.e keep emiting the scroll up down events as well as the smooth ones if possible) or by patching the applications, the rdepends list is likely not trivial though... It should really be opt-in indeed. I couldn't scroll in older versions of Epiphany or gedit with the new GTK+ for example. Quite a big thing to break. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
This explains why gnome-terminal does not scroll with the mouse wheel for me now. On Wed, Mar 14, 2012 at 1:27 PM, Bastien Nocera had...@hadess.net wrote: Em Wed, 2012-03-14 às 19:17 +0100, Sebastien Bacher escreveu: snip I think that's an issue we should look at addressing before 3.4, either by doing some compat work in GTK (i.e keep emiting the scroll up down events as well as the smooth ones if possible) or by patching the applications, the rdepends list is likely not trivial though... It should really be opt-in indeed. I couldn't scroll in older versions of Epiphany or gedit with the new GTK+ for example. Quite a big thing to break. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
