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
