Re: GTK adjustement changes create incompatible behaviour between versions?
(Sorry don't want to troll, just to justify me talking to Ubuntu to delay the change) Yes it is right but it should have been considered an API break and the announcement should have been far ahead of the change; this is a change that's even more problematic than an ouvert API change because apps keep compiling and running but not working right. Sadly, i really expect many apps still being broken long after the change has been finally applied. Cheers, M. Am 22. September 2008 11:32 schrieb Davyd Madeley [EMAIL PROTECTED]: I think GTK+ is now doing the right thing. From my understanding, this only affects UIs created with Glade (which has been setting a page_size of 10 -- and it seems still isn't fixed). Matt here developed a workaround for this in libglade. That sets the page_size to 0 and reports a warning that your app is broken. FWIW, I have mentioned this change in the developer section of the 2.24 release notes. --davyd On Mon, 2008-09-22 at 09:12 +0100, Ghee Teo wrote: Hi Vincent, While you have just announced 2.24.0 tarballs to be available for 22nd Sep. Does this mean we are going to ship 2.24.0 without an possible resolution to this regression? Since applications would not have a change to workaround this should gtk+ is not going to back up this feature. If gtk+ going to back out this feature, it can only be done after 23rd Sept! Have the release team considered moving the 2.24.0 release date by a couple of days to accommodate this? -Ghee Vincent Untz wrote: Le vendredi 19 septembre 2008, à 09:17 -0400, Matthias Clasen a écrit : I don't see any way around discussing this with the GTK+ team before taking any decisions. I was hoping this would be discussed on gtk-devel-list and that a decision would have been taken there :/ If you think this is a blocker for 2.24, then having it reverted on September 23 should still be good for a Gnome release on September 24. Hrm, well, that's definitely late for smoketesting... Vincent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Davyd MadeleySoftware Engineer Fugro Seismic Imaging, Perth Australia ___ gtk-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
2008/9/20 Emmanuele Bassi [EMAIL PROTECTED]: This is not true. See #307963. From the gtk 2.12 documentation for GtkAdjustment: The page size of the adjustment. Note that the page-size is irrelevant and should be set to zero if the adjustment is used for a simple scalar value, e.g. in a GtkSpinButton. ... and the documentation. both are telling you that you should set the page_size to 0 for SpinButtons or sliders. The operating word is irrelevant meaning inconsequential, not affecting, no impact. Please see the bug report I linked to, it discusses this problem. Previously it was irrelevant whether page_size was set to 9 or 0 for GtkSpinButtons, now it matters = breakage. the documentation for GtkAdjustment already says that the accepted value range is [lower, upper - page_size]. the enforcing apparently breaks broken application accessing the GtkAdjustment data structure - something gtk+ cannot prevent. That accessing the struct attributes in GtkAdjustment is broken needs to be spelled out more clearly. The documentation does not say that it is wrong. -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Hi Vincent, While you have just announced 2.24.0 tarballs to be available for 22nd Sep. Does this mean we are going to ship 2.24.0 without an possible resolution to this regression? Since applications would not have a change to workaround this should gtk+ is not going to back up this feature. If gtk+ going to back out this feature, it can only be done after 23rd Sept! Have the release team considered moving the 2.24.0 release date by a couple of days to accommodate this? -Ghee Vincent Untz wrote: Le vendredi 19 septembre 2008, à 09:17 -0400, Matthias Clasen a écrit : I don't see any way around discussing this with the GTK+ team before taking any decisions. I was hoping this would be discussed on gtk-devel-list and that a decision would have been taken there :/ If you think this is a blocker for 2.24, then having it reverted on September 23 should still be good for a Gnome release on September 24. Hrm, well, that's definitely late for smoketesting... Vincent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
On Mon, Sep 22, 2008 at 10:12 AM, Ghee Teo [EMAIL PROTECTED] wrote: Hi Vincent, While you have just announced 2.24.0 tarballs to be available for 22nd Sep. Does this mean we are going to ship 2.24.0 without an possible resolution to this regression? Since applications would not have a change to workaround this should gtk+ is not going to back up this feature. If gtk+ going to back out this feature, it can only be done after 23rd Sept! Have the release team considered moving the 2.24.0 release date by a couple of days to accommodate this? Can we get a precise list of affected applications? I only tripped over Inkscape so far but that's not part of GNOME and we'll likely patch it up downstream if there's no upstream fix. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
I think GTK+ is now doing the right thing.
From my understanding, this only affects UIs created with Glade (which
has been setting a page_size of 10 -- and it seems still isn't fixed).
Matt here developed a workaround for this in libglade. That sets the
page_size to 0 and reports a warning that your app is broken.
FWIW, I have mentioned this change in the developer section of the 2.24
release notes.
--davyd
On Mon, 2008-09-22 at 09:12 +0100, Ghee Teo wrote:
Hi Vincent,
While you have just announced 2.24.0 tarballs to be available for 22nd Sep.
Does this mean we are going to ship 2.24.0 without an possible
resolution to this regression?
Since applications would not have a change to workaround this should
gtk+ is not going to
back up this feature. If gtk+ going to back out this feature, it can
only be done after 23rd Sept!
Have the release team considered moving the 2.24.0 release date by a
couple of days to
accommodate this?
-Ghee
Vincent Untz wrote:
Le vendredi 19 septembre 2008, à 09:17 -0400, Matthias Clasen a écrit :
I don't see any way around discussing this with the GTK+ team before
taking any decisions.
I was hoping this would be discussed on gtk-devel-list and that a
decision would have been taken there :/
If you think this is a blocker for 2.24, then having it reverted on
September 23 should still be good for a Gnome release on September 24.
Hrm, well, that's definitely late for smoketesting...
Vincent
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
--
Davyd MadeleySoftware Engineer
Fugro Seismic Imaging, Perth Australia
--- libglade-2.6.3/glade/glade-gtk.c.orig 2008-08-18 15:58:59.0 +0800
+++ libglade-2.6.3/glade/glade-gtk.c 2008-09-22 11:59:39.0 +0800
@@ -1130,6 +1130,31 @@
return NULL;
}
+static GtkWidget *
+fsi_glade_build_gtkspinbutton(GladeXML *xml, GType widget_type,
+ GladeWidgetInfo *info)
+{
+GtkWidget *w;
+w = glade_standard_build_widget(xml, widget_type, info);
+if (w) {
+GObject *adj;
+g_object_get(w, adjustment, adj, NULL);
+if (adj) {
+double page_size;
+g_object_get(adj, page_size, page_size, NULL);
+if (page_size != 0.0)
+{
+g_warning (Spin button '%s' has non-zero page_size (%f). Workaround applied.,
+ info-name, page_size);
+}
+page_size = 0;
+g_object_set(adj, page_size, page_size, NULL);
+g_object_unref(adj);
+}
+}
+return w;
+}
+
void
_glade_init_gtk_widgets(void)
{
@@ -1313,7 +1338,7 @@
glade_register_widget (GTK_TYPE_SOCKET, glade_standard_build_widget,
NULL, NULL);
#endif
-glade_register_widget (GTK_TYPE_SPIN_BUTTON, glade_standard_build_widget,
+glade_register_widget (GTK_TYPE_SPIN_BUTTON, fsi_glade_build_gtkspinbutton,
NULL, NULL);
glade_register_widget (GTK_TYPE_STATUSBAR, glade_standard_build_widget,
NULL, NULL);
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Patryk Zawadzki wrote: On Mon, Sep 22, 2008 at 10:12 AM, Ghee Teo [EMAIL PROTECTED] wrote: Hi Vincent, While you have just announced 2.24.0 tarballs to be available for 22nd Sep. Does this mean we are going to ship 2.24.0 without an possible resolution to this regression? Since applications would not have a change to workaround this should gtk+ is not going to back up this feature. If gtk+ going to back out this feature, it can only be done after 23rd Sept! Have the release team considered moving the 2.24.0 release date by a couple of days to accommodate this? Can we get a precise list of affected applications? I only tripped over Inkscape so far but that's not part of GNOME and we'll likely patch it up downstream if there's no upstream fix. The list of applications affected were listed by Kjartan and Vincent on this thread previously. I guess my stand point is not so much which way should the community fix this, but rather a complete release of 2.24.0 rather than a patchy one. If every distros have to fix this downstream, would be better one fix upstream in GNOME :). Another more selfish reason, we want to release 2.24.0 in the next public release rather than 2.22.x, since there are applications within our release which will be impacted by the decision here, we like to find out here too and give them the head up :) -Ghee ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Can we get a precise list of affected applications? I only tripped over Inkscape so far but that's not part of GNOME and we'll likely patch it up downstream if there's no upstream fix. For one gnome-sudoku is hit by this. I have a patch ready that will be included in 2.24.1 We should fix the apps regardless of whether gtk reverts the change or not. Would anyone object if I set up a gnome goal to check/fix/track this? - Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Davyd Madeley wrote: I think GTK+ is now doing the right thing. From my understanding, this only affects UIs created with Glade (which has been setting a page_size of 10 -- and it seems still isn't fixed). Matt here developed a workaround for this in libglade. That sets the page_size to 0 and reports a warning that your app is broken. This is GREAT! Does this imply the bug is in libglade since it does not conform to the GTK+ spec? Should the fix be made in libglade also so that new glade file will conform to the GTK+ glade. FWIW, I have mentioned this change in the developer section of the 2.24 release notes. Have you a pointer to the latest 2.24 release note? Thanks, -Ghee --davyd On Mon, 2008-09-22 at 09:12 +0100, Ghee Teo wrote: Hi Vincent, While you have just announced 2.24.0 tarballs to be available for 22nd Sep. Does this mean we are going to ship 2.24.0 without an possible resolution to this regression? Since applications would not have a change to workaround this should gtk+ is not going to back up this feature. If gtk+ going to back out this feature, it can only be done after 23rd Sept! Have the release team considered moving the 2.24.0 release date by a couple of days to accommodate this? -Ghee Vincent Untz wrote: Le vendredi 19 septembre 2008, à 09:17 -0400, Matthias Clasen a écrit : I don't see any way around discussing this with the GTK+ team before taking any decisions. I was hoping this would be discussed on gtk-devel-list and that a decision would have been taken there :/ If you think this is a blocker for 2.24, then having it reverted on September 23 should still be good for a Gnome release on September 24. Hrm, well, that's definitely late for smoketesting... Vincent ___ 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: GTK adjustement changes create incompatible behaviour between versions?
On Mon, Sep 22, 2008 at 12:19 PM, Thomas H.P. Andersen [EMAIL PROTECTED] wrote: Can we get a precise list of affected applications? I only tripped over Inkscape so far but that's not part of GNOME and we'll likely patch it up downstream if there's no upstream fix. For one gnome-sudoku is hit by this. I have a patch ready that will be included in 2.24.1 We should fix the apps regardless of whether gtk reverts the change or not. Would anyone object if I set up a gnome goal to check/fix/track this? Can we request a global freeze break permission to fix this and only this? It would be easier if we can just commit and re-roll a 2.24.0.1 release or something. That's why I asked for a list of affected GNOME modules (I think the previous list was not complete as it only included .ui files and there was no indication if it was from a complete GNOME build). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
On Mon, 2008-09-22 at 10:23 +0100, Ghee Teo wrote: Davyd Madeley wrote: I think GTK+ is now doing the right thing. From my understanding, this only affects UIs created with Glade (which has been setting a page_size of 10 -- and it seems still isn't fixed). Matt here developed a workaround for this in libglade. That sets the page_size to 0 and reports a warning that your app is broken. This is GREAT! Does this imply the bug is in libglade since it does not conform to the GTK+ spec? Should the fix be made in libglade also so that new glade file will conform to the GTK+ glade. This is a complicated question. There are 3 ways I can think of to create a GtkSpinButton: - using GTK+; - using GtkBuilder; and - using libglade If you've called the function in GTK+ directly, you never specify a page_size (it doesn't make sense). If you've set a non-zero page_size, it's really your own fault. But if you've used Glade, you've got the problem that it was always setting the default page_size to 10. Since this never worked AFAIK, it seems unlikely that anyone was intentionally setting this to a value. You could probably safely add a workaround in libglade. I assume libglade will go away with GTK+ 3.0. But GtkBuilder doesn't go away for GTK+ 3.0. So by adding a workaround for GtkBuilder, we've made it so that you can never set a page_size, even if you wanted to. Off the top of my head, one option would be to make GtkBuilder 2.x fudge page_size to 0 and give a g_warning saying your app is broken with a #define GTK_BUILDER_ENFORCE_PAGE_SIZE to enforce the correct behaviour (which would be the only behaviour in 3.0). On the question of why is Glade wrong. I notice (in older manuals at least) that while the docs tell you to set a page_size of 0. The examples don't actually follow this advice, and set page_size == page_increment .I've not checked the new manual to see if someone has corrected the examples. spinner_adj = (GtkAdjustment *) gtk_adjustment_new (2.500, 0.0, 5.0, 0.001, 0.1, 0.1); spinner = gtk_spin_button_new (spinner_adj, 0.001, 3); FWIW, I have mentioned this change in the developer section of the 2.24 release notes. Have you a pointer to the latest 2.24 release note? http://svn.gnome.org/viewvc/release-notes/branches/gnome-2-24/ --davyd -- Davyd Madeley,Software Engineer Fugro Seismic Imaging, Perth, Australia http://www.fugro-fsi.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Le lundi 22 septembre 2008, à 12:24 +0200, Patryk Zawadzki a écrit : On Mon, Sep 22, 2008 at 12:19 PM, Thomas H.P. Andersen [EMAIL PROTECTED] wrote: Can we get a precise list of affected applications? I only tripped over Inkscape so far but that's not part of GNOME and we'll likely patch it up downstream if there's no upstream fix. For one gnome-sudoku is hit by this. I have a patch ready that will be included in 2.24.1 We should fix the apps regardless of whether gtk reverts the change or not. Would anyone object if I set up a gnome goal to check/fix/track this? Can we request a global freeze break permission to fix this and only this? Could work, especially since we have a list of files that might need to be fixed. It would be easier if we can just commit and re-roll a 2.24.0.1 release or something. It doesn't really make sense to release GNOME 2.24.0.1 for this. But we can re-roll tarballs for individual modules for 2.24.0, sure. Or we can delay 2.24.0. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Le lundi 22 septembre 2008 à 18:47 +0800, Davyd Madeley a écrit : If you've called the function in GTK+ directly, you never specify a page_size (it doesn't make sense). If you've set a non-zero page_size, it's really your own fault. Hi, how do you expect the people using gtk to guess that? the gtk_spin_button has no note about the adjustement and the example are buggy and use a non null value Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
On Mon, 2008-09-22 at 13:50 +0200, Sebastien Bacher wrote: Le lundi 22 septembre 2008 à 18:47 +0800, Davyd Madeley a écrit : If you've called the function in GTK+ directly, you never specify a page_size (it doesn't make sense). If you've set a non-zero page_size, it's really your own fault. how do you expect the people using gtk to guess that? the gtk_spin_button has no note about the adjustement and the example are buggy and use a non null value Here: http://library.gnome.org/devel/gtk/stable/GtkAdjustment.html#GtkAdjustment--page-size Yes, the examples are wrong. Also redundant. You don't need to provide functions to access ints or floats. I admit, it was probably a bit mean of me to say to it's their own fault. I hadn't read the examples when I wrote that. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
On Mon, Sep 22, 2008 at 1:07 PM, Vincent Untz [EMAIL PROTECTED] wrote: Le lundi 22 septembre 2008, à 12:24 +0200, Patryk Zawadzki a écrit : Can we request a global freeze break permission to fix this and only this? Could work, especially since we have a list of files that might need to be fixed. Ok, first patch is attached - putting the end to the root of all evil - glade3 itself. -- Patryk Zawadzki Index: plugins/gtk+/gtk+.xml.in === --- plugins/gtk+/gtk+.xml.in (wersja 1953) +++ plugins/gtk+/gtk+.xml.in (kopia robocza) @@ -741,7 +741,7 @@ property id=text disabled=True/ property id=value disabled=True/ property id=can-focus default=True/ -property id=adjustment default=0 0 100 1 10 10/ +property id=adjustment default=0 0 100 1 10 0/ property id=update-policy displayable-values value id=GTK_UPDATE_ALWAYS _name=Always/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Le lundi 22 septembre 2008, à 16:50 +0200, Patryk Zawadzki a écrit : On Mon, Sep 22, 2008 at 1:07 PM, Vincent Untz [EMAIL PROTECTED] wrote: Le lundi 22 septembre 2008, à 12:24 +0200, Patryk Zawadzki a écrit : Can we request a global freeze break permission to fix this and only this? Could work, especially since we have a list of files that might need to be fixed. Ok, first patch is attached - putting the end to the root of all evil - glade3 itself. And I've created patches for quite some modules: http://tmp.vuntz.net/adjustpatches/ accerciser.patch anjuta.patch dasher.patch deskbar-applet.patch eog.patch evolution.patch file-roller.patch gcalctool.patch gedit.patch gnome-applets.patch gnome-games.patch gnome-nettool.patch gnome-sharp.patch gnome-system-tools.patch gtkhtml.patch hamster-applet.patch mousetweaks.patch orca.patch seahorse.patch seahorse-plugins.patch vino.patch It's probably a good idea to double-check them to be sure I didn't do something wrong. Note that it only fixes glade/ui files. If the code is wrong, then we have to fix it too... Doing a giant grep for this at the moment. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
On Mon, Sep 22, 2008 at 4:56 PM, Vincent Untz [EMAIL PROTECTED] wrote: Le lundi 22 septembre 2008, à 16:50 +0200, Patryk Zawadzki a écrit : On Mon, Sep 22, 2008 at 1:07 PM, Vincent Untz [EMAIL PROTECTED] wrote: Le lundi 22 septembre 2008, à 12:24 +0200, Patryk Zawadzki a écrit : Can we request a global freeze break permission to fix this and only this? Could work, especially since we have a list of files that might need to be fixed. Ok, first patch is attached - putting the end to the root of all evil - glade3 itself. And I've created patches for quite some modules: http://tmp.vuntz.net/adjustpatches/ dasher.patch This one looks like it touches some sliders instead of spin buttons, if these behave like scrollbars then page_size should be set to the handle length in units (as you don't want the handle to move past the end nor the end, you restrict values to MIN, MAX - HANDLE). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
On Mon, Sep 22, 2008 at 5:02 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote: dasher.patch This one looks like it touches some sliders instead of spin buttons, if these behave like scrollbars then page_size should be set to the handle length in units (as you don't want the handle to move past the end nor the end, you restrict values to MIN, MAX - HANDLE). Ignore this, I need more coffee. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
2008/9/22 Davyd Madeley [EMAIL PROTECTED]: I think GTK+ is now doing the right thing. I believe it would do twice the right thing if it also ignored page_size for spinenr buttons. As it is used to represent the number of data records (be it table rows, canvas pixels or something else) presented at a time, it makes absolutely no sense to use it in spin controls where there is no data involved. You always want the user to pick from the full range and you are free to override that behavior when subclassing. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Le lundi 22 septembre 2008, à 16:56 +0200, Vincent Untz a écrit : And I've created patches for quite some modules: http://tmp.vuntz.net/adjustpatches/ accerciser.patch anjuta.patch dasher.patch deskbar-applet.patch eog.patch evolution.patch file-roller.patch gcalctool.patch gedit.patch gnome-applets.patch gnome-games.patch gnome-nettool.patch gnome-sharp.patch gnome-system-tools.patch gtkhtml.patch hamster-applet.patch mousetweaks.patch orca.patch seahorse.patch seahorse-plugins.patch vino.patch It's probably a good idea to double-check them to be sure I didn't do something wrong. Note that it only fixes glade/ui files. If the code is wrong, then we have to fix it too... Doing a giant grep for this at the moment. This is probably missing some stuff and there are probably false positives (GtkAdjustment which are used for widgets for which it's fine to work this way), but it help to know where to look if we want to fix this in GNOME: grep of usage of GtkAdjustment API which might be wrong: http://tmp.vuntz.net/adjustpatches/gtk_adjustment_.txt grep of direct access to page_size (which might contain some non-GtkAdjustment results): http://tmp.vuntz.net/adjustpatches/set-page_size.txt Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Le samedi 20 septembre 2008 à 12:17 +0100, Emmanuele Bassi a écrit : read this bit above again... This is not true. See #307963. From the gtk 2.12 documentation for GtkAdjustment: The page size of the adjustment. Note that the page-size is irrelevant and should be set to zero if the adjustment is used for a simple scalar value, e.g. in a GtkSpinButton. ... and the documentation. both are telling you that you should set the page_size to 0 for SpinButtons or sliders. There is a difference between should and must. As it is currently worded, the documentation lets you think the value can be safely ignored, which is the case in 2.12. Even worse, since Glade uses a default of 10 which was ignored, it has certainly slipped in hundreds, if not thousands of applications. the documentation for GtkAdjustment already says that the accepted value range is [lower, upper - page_size]. the enforcing apparently breaks broken application accessing the GtkAdjustment data structure - something gtk+ cannot prevent. No. The documentation says that the accepted value range *for GtkScrollbar*. Which implies this is not the case for other widgets! Definitely it is a break. No opinion on if the new behavior is better or not. now tell me: what difference do you see between the documentation and the enforcing of the documentation that you consider a break? The difference is that you are knowingly breaking hundreds of applications. You are able to fix those distributed by GNOME in a snap and that’s all good, but you let downstream distributors with hundreds of broken applications in their hands. The only solution we have is to revert this change, because we simply can't afford it. Even if we fix all our packages (and that would take a few weeks), the problem of non-free applications remains. GTK+ is not just a random library that you can afford to break a each and every release, it is one of the more widely used toolkits. If the wording of the documentation was not clear enough, that’s bad, but it’s too late, you can’t break it now. Now for more constructive discussion: * would it work if GtkSpinButtons (and maybe GtkScale) forced page_size to be 0 in the constructors and in ..._set_adjustment? * if it is not the case, the only sane solution is to delay this change until GTK+ 3.0, as already suggested. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
2008/9/22 Josselin Mouette [EMAIL PROTECTED]: The difference is that you are knowingly breaking hundreds of applications. You are able to fix those distributed by GNOME in a snap and that's all good, but you let downstream distributors with hundreds of broken applications in their hands. The only solution we have is to revert this change, because we simply can't afford it. Not true, we can avoid all the breakage inside GtkSpinButton. Even if we fix all our packages (and that would take a few weeks), the problem of non-free applications remains. GTK+ is not just a random library that you can afford to break a each and every release, it is one of the more widely used toolkits. If the wording of the documentation was not clear enough, that's bad, but it's too late, you can't break it now. Now for more constructive discussion: * would it work if GtkSpinButtons (and maybe GtkScale) forced page_size to be 0 in the constructors and in ..._set_adjustment? That's what I proposed. If it's != 0, force it to 0 and issue a warning. Spin controls have no concept of data set so there is no such thing as a page and therefore there's no use for limiting the offset to a certain subrange of (min, max). It's a two-three line change for GTK and was already worked around in libglade (patch posted earlier in this thread). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
On Mon, Sep 22, 2008 at 12:41 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote: 2008/9/22 Josselin Mouette [EMAIL PROTECTED]: The difference is that you are knowingly breaking hundreds of applications. You are able to fix those distributed by GNOME in a snap and that's all good, but you let downstream distributors with hundreds of broken applications in their hands. The only solution we have is to revert this change, because we simply can't afford it. Not true, we can avoid all the breakage inside GtkSpinButton. Even if we fix all our packages (and that would take a few weeks), the problem of non-free applications remains. GTK+ is not just a random library that you can afford to break a each and every release, it is one of the more widely used toolkits. If the wording of the documentation was not clear enough, that's bad, but it's too late, you can't break it now. Now for more constructive discussion: * would it work if GtkSpinButtons (and maybe GtkScale) forced page_size to be 0 in the constructors and in ..._set_adjustment? That's what I proposed. If it's != 0, force it to 0 and issue a warning. Spin controls have no concept of data set so there is no such thing as a page and therefore there's no use for limiting the offset to a certain subrange of (min, max). It's a two-three line change for GTK and was already worked around in libglade (patch posted earlier in this thread). That seems like a reasonable proposal, assuming that most of the breakage is in spin buttons. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
On Mon, Sep 22, 2008 at 6:46 PM, Matthias Clasen [EMAIL PROTECTED] wrote: On Mon, Sep 22, 2008 at 12:41 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote: That's what I proposed. If it's != 0, force it to 0 and issue a warning. Spin controls have no concept of data set so there is no such thing as a page and therefore there's no use for limiting the offset to a certain subrange of (min, max). It's a two-three line change for GTK and was already worked around in libglade (patch posted earlier in this thread). That seems like a reasonable proposal, assuming that most of the breakage is in spin buttons. From what I've learned from glade3, it only sets the values for GtkAspectFrame and GtkSpinButton. The only affected widget seems to GtkSpinButton (that's why I decided to leave aspect frame out of my patch posted earlier). Are there any examples of broken aspect frame behavior? Are there more widgets that got the adjustments from glade2? I didn't have the time to review glade2 code yet. In any case, gtk+ seems right the correct place to ignore the values as there were reports of broken examples that created widgets directly (thus libglade workarounds provide limited coverage). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
On Fri, 2008-09-19 at 19:57 +0200, BJörn Lindqvist wrote: 2008/9/18 Sebastien Bacher [EMAIL PROTECTED]: * GtkAdjustment now enforces that values are restricted to the range [lower, upper - page_size]. This has always been the documented behaviour, and the recommended practice is to set page_size to 0 when using adjustments for simple scalar values, like in a slider or spin button. read this bit above again... This is not true. See #307963. From the gtk 2.12 documentation for GtkAdjustment: The page size of the adjustment. Note that the page-size is irrelevant and should be set to zero if the adjustment is used for a simple scalar value, e.g. in a GtkSpinButton. ... and the documentation. both are telling you that you should set the page_size to 0 for SpinButtons or sliders. the documentation for GtkAdjustment already says that the accepted value range is [lower, upper - page_size]. the enforcing apparently breaks broken application accessing the GtkAdjustment data structure - something gtk+ cannot prevent. Definitely it is a break. No opinion on if the new behavior is better or not. now tell me: what difference do you see between the documentation and the enforcing of the documentation that you consider a break? ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Le vendredi 19 septembre 2008, à 09:17 -0400, Matthias Clasen a écrit : I don't see any way around discussing this with the GTK+ team before taking any decisions. I was hoping this would be discussed on gtk-devel-list and that a decision would have been taken there :/ If you think this is a blocker for 2.24, then having it reverted on September 23 should still be good for a Gnome release on September 24. Hrm, well, that's definitely late for smoketesting... Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Le vendredi 19 septembre 2008, à 00:36 +0200, Vincent Untz a écrit : Le jeudi 18 septembre 2008, à 21:53 +0200, Kjartan Maraas a écrit : [EMAIL PROTECTED] share]$ find . -name *.ui | xargs grep page_size You should look for glade files too, I guess. I've run this on my jhbuild of GNOME 2.23.92: [EMAIL PROTECTED] /gnome/usr/share/find . -name *.glade | xargs grep 'property name=adjustment' /tmp/adjustments [EMAIL PROTECTED] /gnome/usr/share/grep -v '0 0 \\/prop' /tmp/adjustments | wc -l 164 [EMAIL PROTECTED] /gnome/usr/share/grep -v '0 0 \\/prop' /tmp/adjustments | cut -f 1 -d ':' | sort -u | wc -l 67 [EMAIL PROTECTED] /gnome/usr/share/grep -v '0 0 \\/prop' /tmp/adjustments | cut -f 1 -d ':' | sort -u ./anjuta/glade/anjuta-build-basic-autotools-plugin.glade ./anjuta/glade/anjuta-cvs-plugin.glade ./anjuta/glade/anjuta-document-manager.glade ./anjuta/glade/anjuta-editor-sourceview.glade ./anjuta/glade/anjuta-language-cpp-java.glade ./anjuta/glade/anjuta-message-manager-plugin.glade ./anjuta/glade/anjuta-search.glade ./anjuta/glade/patch-plugin.glade ./dasher/dasher.compose.glade ./dasher/dasher.direct.glade ./dasher/dasher.gameWIP.glade ./dasher/dashermaemo.preferences.glade ./dasher/dasher.preferences.glade ./dasher/dasher.traditional.glade ./deskbar-applet/prefs-dialog.glade ./empathy/empathy-account-widget-aim.glade ./empathy/empathy-account-widget-groupwise.glade ./empathy/empathy-account-widget-icq.glade ./empathy/empathy-account-widget-jabber.glade ./empathy/empathy-account-widget-msn.glade ./empathy/empathy-account-widget-sip.glade ./empathy/empathy-account-widget-yahoo.glade ./eog/eog-multiple-save-as-dialog.glade ./eog/eog-preferences-dialog.glade ./epiphany/glade/prefs-dialog.glade ./evolution/2.24/glade/alarm-dialog.glade ./evolution/2.24/glade/alarm-notify.glade ./evolution/2.24/glade/cal-prefs-dialog.glade ./evolution/2.24/glade/e-contact-print.glade ./evolution/2.24/glade/e-itip-control.glade ./evolution/2.24/glade/e-send-options.glade ./evolution/2.24/glade/event-page.glade ./evolution/2.24/glade/filter.glade ./evolution/2.24/glade/goto-dialog.glade ./evolution/2.24/glade/ldap-config.glade ./evolution/2.24/glade/mail-config.glade ./evolution/2.24/glade/recurrence-page.glade ./evolution/2.24/glade/task-details-page.glade ./file-roller/glade/batch-add-files.glade ./file-roller/glade/new.glade ./gcalctool/gcalctool.glade ./glchess/new_game.glade ./gnome-control-center/glade/appearance.glade ./gnome-control-center/glade/gnome-keyboard-properties.glade ./gnome-control-center/glade/gnome-mouse-properties.glade ./gnome-control-center/glade/gnome-network-preferences.glade ./gnome-control-center/glade/gnome-window-properties.glade ./gnome-nettool/dialogs/gnome-nettool.glade ./gnome-panel/glade/clock.glade ./gnome-panel/glade/fish.glade ./gnome-panel/glade/panel-properties-dialog.glade ./gnome-panel/glade/workspace-switcher.glade ./gnome-power-manager/gpm-prefs.glade ./gnome-screensaver/gnome-screensaver-preferences.glade ./gnome-sudoku/print_games.glade ./gnome-sudoku/puzzle_generator.glade ./gtkhtml-3.14/gtkhtml-editor.glade ./hamster-applet/add_custom_fact.glade ./mousetweaks/pointer-capture-applet.glade ./orca/glade/orca-setup.glade ./seahorse/glade/seahorse-add-subkey.glade ./seahorse/glade/seahorse-pgp-generate.glade ./seahorse/glade/seahorse-ssh-generate.glade ./seahorse-plugins/glade/seahorse-prefs.glade ./sound-juicer/sound-juicer.glade ./vino/vino-preferences.glade ./zenity/zenity.glade Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Le jeudi 18 septembre 2008, à 22:25 -0400, Matthias Clasen a écrit : On Thu, Sep 18, 2008 at 4:36 AM, Sebastien Bacher [EMAIL PROTECTED] wrote: Would it be possible to reconsider this change? That's somewhat a compatibility breakage and will create issues in lot of softwares. If the change is right it would be nice to let a cycle for applications to be updated to the new behaviour before using it, there is thousand of GTK applications around and reviewing those for incorrect adjustement usages is going to take a while. I've put this on the agenda for the next gtk team meeting on Sept 23. Note that discussing this on Sept 23 means the decision will be too late for GNOME 2.24.0. If this is a major issue, we should either reach consensus that GTK+ should revert this ASAP or decide to fix all our .glade/.ui files now. The latter won't help with applications we don't maintain, though. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Le vendredi 19 septembre 2008, à 10:36 +0200, Vincent Untz a écrit : Le vendredi 19 septembre 2008, à 00:36 +0200, Vincent Untz a écrit : Le jeudi 18 septembre 2008, à 21:53 +0200, Kjartan Maraas a écrit : [EMAIL PROTECTED] share]$ find . -name *.ui | xargs grep page_size You should look for glade files too, I guess. I've run this on my jhbuild of GNOME 2.23.92: Bah, should have checked my result :-) Note that it doesn't mean all those files have a bug, but they need to be checked. Trying again: [EMAIL PROTECTED] /gnome/usr/share/find . -name *.glade | xargs grep 'property name=adjustment' /tmp/adjustments [EMAIL PROTECTED] /gnome/usr/share/grep -v ' 0/prop' /tmp/adjustments | wc -l 124 [EMAIL PROTECTED] /gnome/releases/usr/share/grep -v ' 0/prop' /tmp/adjustments | cut -f 1 -d ':' | sort -u | wc -l 57 [EMAIL PROTECTED] /gnome/releases/usr/share/grep -v ' 0/prop' /tmp/adjustments | cut -f 1 -d ':' | sort -u ./anjuta/glade/anjuta-build-basic-autotools-plugin.glade ./anjuta/glade/anjuta-cvs-plugin.glade ./anjuta/glade/anjuta-document-manager.glade ./anjuta/glade/anjuta-editor-sourceview.glade ./anjuta/glade/anjuta-language-cpp-java.glade ./anjuta/glade/anjuta-message-manager-plugin.glade ./anjuta/glade/anjuta-search.glade ./dasher/dasher.compose.glade ./dasher/dasher.direct.glade ./dasher/dasher.gameWIP.glade ./dasher/dasher.traditional.glade ./deskbar-applet/prefs-dialog.glade ./empathy/empathy-account-widget-aim.glade ./empathy/empathy-account-widget-groupwise.glade ./empathy/empathy-account-widget-icq.glade ./empathy/empathy-account-widget-jabber.glade ./empathy/empathy-account-widget-msn.glade ./empathy/empathy-account-widget-sip.glade ./empathy/empathy-account-widget-yahoo.glade ./eog/eog-multiple-save-as-dialog.glade ./eog/eog-preferences-dialog.glade ./epiphany/glade/prefs-dialog.glade ./evolution/2.24/glade/alarm-dialog.glade ./evolution/2.24/glade/alarm-notify.glade ./evolution/2.24/glade/cal-prefs-dialog.glade ./evolution/2.24/glade/e-contact-print.glade ./evolution/2.24/glade/e-itip-control.glade ./evolution/2.24/glade/e-send-options.glade ./evolution/2.24/glade/event-page.glade ./evolution/2.24/glade/filter.glade ./evolution/2.24/glade/goto-dialog.glade ./evolution/2.24/glade/ldap-config.glade ./evolution/2.24/glade/mail-config.glade ./evolution/2.24/glade/recurrence-page.glade ./evolution/2.24/glade/task-details-page.glade ./file-roller/glade/batch-add-files.glade ./file-roller/glade/new.glade ./gcalctool/gcalctool.glade ./glchess/new_game.glade ./gnome-control-center/glade/appearance.glade ./gnome-control-center/glade/gnome-keyboard-properties.glade ./gnome-control-center/glade/gnome-network-preferences.glade ./gnome-nettool/dialogs/gnome-nettool.glade ./gnome-panel/glade/clock.glade ./gnome-panel/glade/panel-properties-dialog.glade ./gnome-panel/glade/workspace-switcher.glade ./gnome-sudoku/print_games.glade ./gnome-sudoku/puzzle_generator.glade ./gtkhtml-3.14/gtkhtml-editor.glade ./hamster-applet/add_custom_fact.glade ./mousetweaks/pointer-capture-applet.glade ./orca/glade/orca-setup.glade ./seahorse/glade/seahorse-add-subkey.glade ./seahorse/glade/seahorse-pgp-generate.glade ./seahorse/glade/seahorse-ssh-generate.glade ./seahorse-plugins/glade/seahorse-prefs.glade ./vino/vino-preferences.glade Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
On Fri, Sep 19, 2008 at 10:39 AM, Vincent Untz [EMAIL PROTECTED] wrote: If this is a major issue, we should either reach consensus that GTK+ should revert this ASAP or decide to fix all our .glade/.ui files now. The latter won't help with applications we don't maintain, though. Fixing seems like a better idea, these apps were already broken in the first place (exploiting a bug in GTK against the documentation) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
fr., 19.09.2008 kl. 00.36 +0200, skrev Vincent Untz: Le jeudi 18 septembre 2008, à 21:53 +0200, Kjartan Maraas a écrit : [EMAIL PROTECTED] share]$ find . -name *.ui | xargs grep page_size You should look for glade files too, I guess. None of the glade files in /usr/share on my machine has a page_size attribute. Am I missing something? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Patryk Zawadzki wrote: On Fri, Sep 19, 2008 at 10:39 AM, Vincent Untz [EMAIL PROTECTED] wrote: If this is a major issue, we should either reach consensus that GTK+ should revert this ASAP or decide to fix all our .glade/.ui files now. The latter won't help with applications we don't maintain, though. Fixing seems like a better idea, these apps were already broken in the first place (exploiting a bug in GTK against the documentation) What about delaying the GtkAdjustment change to GTK+ 3.0, where ABI compatibility is broken anyway? Seems better than throwing it into one of the last 2.x releases if it causes so many problems. Regards, Denis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
On Fri, Sep 19, 2008 at 4:39 AM, Vincent Untz [EMAIL PROTECTED] wrote: Le jeudi 18 septembre 2008, à 22:25 -0400, Matthias Clasen a écrit : On Thu, Sep 18, 2008 at 4:36 AM, Sebastien Bacher [EMAIL PROTECTED] wrote: Would it be possible to reconsider this change? That's somewhat a compatibility breakage and will create issues in lot of softwares. If the change is right it would be nice to let a cycle for applications to be updated to the new behaviour before using it, there is thousand of GTK applications around and reviewing those for incorrect adjustement usages is going to take a while. I've put this on the agenda for the next gtk team meeting on Sept 23. Note that discussing this on Sept 23 means the decision will be too late for GNOME 2.24.0. If this is a major issue, we should either reach consensus that GTK+ should revert this ASAP or decide to fix all our .glade/.ui files now. The latter won't help with applications we don't maintain, though. I don't see any way around discussing this with the GTK+ team before taking any decisions. If you think this is a blocker for 2.24, then having it reverted on September 23 should still be good for a Gnome release on September 24. Ultimatively, it comes down to the question if 'blocker' makes any sense if strict adherence to the schedule is the overarching concern. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Vincent Untz wrote: Le vendredi 19 septembre 2008, à 00:36 +0200, Vincent Untz a écrit : Le jeudi 18 septembre 2008, à 21:53 +0200, Kjartan Maraas a écrit : [EMAIL PROTECTED] share]$ find . -name *.ui | xargs grep page_size You should look for glade files too, I guess. I've run this on my jhbuild of GNOME 2.23.92: [EMAIL PROTECTED] /gnome/usr/share/find . -name *.glade | xargs grep 'property name=adjustment' /tmp/adjustments [EMAIL PROTECTED] /gnome/usr/share/grep -v '0 0 \\/prop' /tmp/adjustments | wc -l 164 [EMAIL PROTECTED] /gnome/usr/share/grep -v '0 0 \\/prop' /tmp/adjustments | cut -f 1 -d ':' | sort -u | wc -l 67 [EMAIL PROTECTED] /gnome/usr/share/grep -v '0 0 \\/prop' /tmp/adjustments | cut -f 1 -d ':' | sort -u ./anjuta/glade/anjuta-build-basic-autotools-plugin.glade ./anjuta/glade/anjuta-cvs-plugin.glade ./anjuta/glade/anjuta-document-manager.glade ./anjuta/glade/anjuta-editor-sourceview.glade ./anjuta/glade/anjuta-language-cpp-java.glade ./anjuta/glade/anjuta-message-manager-plugin.glade ./anjuta/glade/anjuta-search.glade ./anjuta/glade/patch-plugin.glade ./dasher/dasher.compose.glade ./dasher/dasher.direct.glade ./dasher/dasher.gameWIP.glade ./dasher/dashermaemo.preferences.glade ./dasher/dasher.preferences.glade ./dasher/dasher.traditional.glade ./deskbar-applet/prefs-dialog.glade ./empathy/empathy-account-widget-aim.glade ./empathy/empathy-account-widget-groupwise.glade ./empathy/empathy-account-widget-icq.glade ./empathy/empathy-account-widget-jabber.glade ./empathy/empathy-account-widget-msn.glade ./empathy/empathy-account-widget-sip.glade ./empathy/empathy-account-widget-yahoo.glade ./eog/eog-multiple-save-as-dialog.glade ./eog/eog-preferences-dialog.glade ./epiphany/glade/prefs-dialog.glade ./evolution/2.24/glade/alarm-dialog.glade ./evolution/2.24/glade/alarm-notify.glade ./evolution/2.24/glade/cal-prefs-dialog.glade ./evolution/2.24/glade/e-contact-print.glade ./evolution/2.24/glade/e-itip-control.glade ./evolution/2.24/glade/e-send-options.glade ./evolution/2.24/glade/event-page.glade ./evolution/2.24/glade/filter.glade ./evolution/2.24/glade/goto-dialog.glade ./evolution/2.24/glade/ldap-config.glade ./evolution/2.24/glade/mail-config.glade ./evolution/2.24/glade/recurrence-page.glade ./evolution/2.24/glade/task-details-page.glade ./file-roller/glade/batch-add-files.glade ./file-roller/glade/new.glade ./gcalctool/gcalctool.glade ./glchess/new_game.glade ./gnome-control-center/glade/appearance.glade ./gnome-control-center/glade/gnome-keyboard-properties.glade ./gnome-control-center/glade/gnome-mouse-properties.glade ./gnome-control-center/glade/gnome-network-preferences.glade ./gnome-control-center/glade/gnome-window-properties.glade ./gnome-nettool/dialogs/gnome-nettool.glade ./gnome-panel/glade/clock.glade ./gnome-panel/glade/fish.glade ./gnome-panel/glade/panel-properties-dialog.glade ./gnome-panel/glade/workspace-switcher.glade ./gnome-power-manager/gpm-prefs.glade ./gnome-screensaver/gnome-screensaver-preferences.glade ./gnome-sudoku/print_games.glade ./gnome-sudoku/puzzle_generator.glade ./gtkhtml-3.14/gtkhtml-editor.glade ./hamster-applet/add_custom_fact.glade ./mousetweaks/pointer-capture-applet.glade ./orca/glade/orca-setup.glade ./seahorse/glade/seahorse-add-subkey.glade ./seahorse/glade/seahorse-pgp-generate.glade ./seahorse/glade/seahorse-ssh-generate.glade ./seahorse-plugins/glade/seahorse-prefs.glade ./sound-juicer/sound-juicer.glade ./vino/vino-preferences.glade ./zenity/zenity.glade Vincent Did I miss something that said that this issue only applies if you're using glade? What about projects that don't use glade and set the page_size attribute in code? -- jonner ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
On Fri, Sep 19, 2008 at 10:04 AM, Jonathon Jongsma [EMAIL PROTECTED] wrote: Did I miss something that said that this issue only applies if you're using glade? What about projects that don't use glade and set the page_size attribute in code? Nobody said that it only affects glade-using projects. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Matthias Clasen wrote: On Fri, Sep 19, 2008 at 10:04 AM, Jonathon Jongsma [EMAIL PROTECTED] wrote: Did I miss something that said that this issue only applies if you're using glade? What about projects that don't use glade and set the page_size attribute in code? Nobody said that it only affects glade-using projects. OK, I was just curious why people were only searching in .ui and .glade files to see which projects were affected... -- jonner ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
2008/9/18 Sebastien Bacher [EMAIL PROTECTED]: * GtkAdjustment now enforces that values are restricted to the range [lower, upper - page_size]. This has always been the documented behaviour, and the recommended practice is to set page_size to 0 when using adjustments for simple scalar values, like in a slider or spin button. This is not true. See #307963. From the gtk 2.12 documentation for GtkAdjustment: The page size of the adjustment. Note that the page-size is irrelevant and should be set to zero if the adjustment is used for a simple scalar value, e.g. in a GtkSpinButton. Definitely it is a break. No opinion on if the new behavior is better or not. -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GTK adjustement changes create incompatible behaviour between versions?
Hello, The new GTK 2.14 changed the way GtkAdjustements are working: * GtkAdjustment now enforces that values are restricted to the range [lower, upper - page_size]. This has always been the documented behaviour, and the recommended practice is to set page_size to 0 when using adjustments for simple scalar values, like in a slider or spin button. That's the GTK readme stating that the new behaviour is documented but the GTK API example use non null values in its example and lot of applications seem to be in this case too. That creates a collection of bugs, http://bugzilla.gnome.org/show_bug.cgi?id=551740 has a small discussion on the topic, basically the gtk_spin_buttons limits are broken in lot of applications (some example are on the bug, gnome-panel has similar issues too). That also means that applications need source code changes to be adapted to the new GTK behaviour. Would it be possible to reconsider this change? That's somewhat a compatibility breakage and will create issues in lot of softwares. If the change is right it would be nice to let a cycle for applications to be updated to the new behaviour before using it, there is thousand of GTK applications around and reviewing those for incorrect adjustement usages is going to take a while. I'm copying the desktop-devel-list too because GNOME 2.24 is due next week and it's likely that several GNOME desktop applications have not been updated for those changes Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GTK adjustement changes create incompatible behaviour between versions?
Hello, The new GTK 2.14 changed the way GtkAdjustements are working: * GtkAdjustment now enforces that values are restricted to the range [lower, upper - page_size]. This has always been the documented behaviour, and the recommended practice is to set page_size to 0 when using adjustments for simple scalar values, like in a slider or spin button. That's the GTK readme stating that the new behaviour is documented but the GTK API example use non null values in its example and lot of applications seem to be in this case too. That creates a collection of bugs, http://bugzilla.gnome.org/show_bug.cgi?id=551740 has a small discussion on the topic, basically the gtk_spin_buttons limits are broken in lot of applications (some example are on the bug, gnome-panel has similar issues too). That also means that applications need source code changes to be adapted to the new GTK behaviour. Would it be possible to reconsider this change? That's somewhat a compatibility breakage and will create issues in lot of softwares. If the change is right it would be nice to let a cycle for applications to be updated to the new behaviour before using it, there is thousand of GTK applications around and reviewing those for incorrect adjustement usages is going to take a while. I'm copying the desktop-devel-list too because GNOME 2.24 is due next week and it's likely that several GNOME desktop applications have not been updated for those changes Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
to., 18.09.2008 kl. 10.36 +0200, skrev Sebastien Bacher: Hello, The new GTK 2.14 changed the way GtkAdjustements are working: * GtkAdjustment now enforces that values are restricted to the range [lower, upper - page_size]. This has always been the documented behaviour, and the recommended practice is to set page_size to 0 when using adjustments for simple scalar values, like in a slider or spin button. That's the GTK readme stating that the new behaviour is documented but the GTK API example use non null values in its example and lot of applications seem to be in this case too. That creates a collection of bugs, http://bugzilla.gnome.org/show_bug.cgi?id=551740 has a small discussion on the topic, basically the gtk_spin_buttons limits are broken in lot of applications (some example are on the bug, gnome-panel has similar issues too). That also means that applications need source code changes to be adapted to the new GTK behaviour. Would it be possible to reconsider this change? That's somewhat a compatibility breakage and will create issues in lot of softwares. If the change is right it would be nice to let a cycle for applications to be updated to the new behaviour before using it, there is thousand of GTK applications around and reviewing those for incorrect adjustement usages is going to take a while. Here's the list from my fedora rawhide install: [EMAIL PROTECTED] share]$ find . -name *.ui | xargs grep page_size ./totem/mozilla-viewer.ui:property name=page_size0/property ./gnome-terminal/profile-preferences.ui:property name=page_size0/property ./gnome-terminal/profile-preferences.ui:property name=page_size0/property ./gnome-applets/builder/mini-commander.ui:property name=page_size10/property ./gnome-applets/builder/stickynotes.ui:property name=page_size100/property ./gnome-applets/builder/stickynotes.ui:property name=page_size100/property ./gedit-2/ui/gedit-print-preferences.ui:property name=page_size10/property ./gedit-2/ui/gedit-preferences-dialog.ui:property name=page_size10/property ./gedit-2/ui/gedit-preferences-dialog.ui:property name=page_size8/property ./gedit-2/ui/gedit-preferences-dialog.ui:property name=page_size10/property ./gedit-2/plugins/sort/sort.ui:property name=page_size10/property And from my jhbuild install I get these in addition: ./gnome-system-tools/ui/time.ui:property name=page_size10/property ./gnome-system-tools/ui/time.ui:property name=page_size10/property ./gnome-system-tools/ui/time.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-applets/builder/battstat_applet.ui:property name=page_size5/property So for our own release this affects at least three modules it seems. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Le jeudi 18 septembre 2008, à 21:53 +0200, Kjartan Maraas a écrit : [EMAIL PROTECTED] share]$ find . -name *.ui | xargs grep page_size You should look for glade files too, I guess. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
On Thu, Sep 18, 2008 at 4:36 AM, Sebastien Bacher [EMAIL PROTECTED] wrote: Would it be possible to reconsider this change? That's somewhat a compatibility breakage and will create issues in lot of softwares. If the change is right it would be nice to let a cycle for applications to be updated to the new behaviour before using it, there is thousand of GTK applications around and reviewing those for incorrect adjustement usages is going to take a while. I've put this on the agenda for the next gtk team meeting on Sept 23. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
