GtkOrientable and GtkBox
I was experimenting with using GtkOrientable today and came across what might be an oversight when using it with GtkBox'like objects. I wanted to turn a hbox into a vbox, which is fine. However the buttons in the box are then clearly in the reverse order to the one that makes sense. This can be hacked around by swapping PACK_START and PACK_END in the child properties, but it doesn't work if another item is then added to the box. I was considering the usefulness of a gtk_box_set_reverse_order() that reverses the meaning of PACK_START and PACK_END. There are kludge ways of implementing this, but it seems like it would be the most useful built into GtkBox. Thoughts? --davyd -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable and GtkBox
Hi, On Wed, 2009-06-03 at 14:25 +0800, Davyd Madeley wrote: I was experimenting with using GtkOrientable today and came across what might be an oversight when using it with GtkBox'like objects. I wanted to turn a hbox into a vbox, which is fine. However the buttons in the box are then clearly in the reverse order to the one that makes sense. What order are they? What order would you suggest makes more sense? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable and GtkBox
On Wed, 2009-06-03 at 10:08 +0200, Sven Neumann wrote: Hi, On Wed, 2009-06-03 at 14:25 +0800, Davyd Madeley wrote: I was experimenting with using GtkOrientable today and came across what might be an oversight when using it with GtkBox'like objects. I wanted to turn a hbox into a vbox, which is fine. However the buttons in the box are then clearly in the reverse order to the one that makes sense. What order are they? What order would you suggest makes more sense? This would be a usage-specific thing. They're in the order they were packed. When you swap the orientation of the vbox, they're still in the order they were packed, but that order might be backwards from the order you desire (i.e. if you were going to build the vbox from scratch). E.g., you might have: [1] [2] [3] Which orients to become [1] [2] [3] But for whatever reason, what you desired was: [3] [2] [1] -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable and GtkBox
Am Wed, 03 Jun 2009 16:18:17 +0800 schrieb Davyd Madeley da...@madeley.id.au: On Wed, 2009-06-03 at 10:08 +0200, Sven Neumann wrote: Hi, On Wed, 2009-06-03 at 14:25 +0800, Davyd Madeley wrote: I was experimenting with using GtkOrientable today and came across what might be an oversight when using it with GtkBox'like objects. I wanted to turn a hbox into a vbox, which is fine. However the buttons in the box are then clearly in the reverse order to the one that makes sense. What order are they? What order would you suggest makes more sense? This would be a usage-specific thing. They're in the order they were packed. When you swap the orientation of the vbox, they're still in the order they were packed, but that order might be backwards from the order you desire (i.e. if you were going to build the vbox from scratch). E.g., you might have: [1] [2] [3] Which orients to become [1] [2] [3] But for whatever reason, what you desired was: [3] [2] [1] Hey David, how is this related to GtkOrientable at all? This was always how a vertical box worked, ever since GtkVBox was there. There is nothing new with it. I'm afraid I don't see how Gtk could help you out, if what you need really is a specific packing. Anything but the current way is pretty much random and up to the application. Yours, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable and GtkBox
On Wed, 2009-06-03 at 11:55 +0200, Christian Dywan wrote: how is this related to GtkOrientable at all? This was always how a vertical box worked, ever since GtkVBox was there. There is nothing new with it. I'm afraid I don't see how Gtk could help you out, if what you need really is a specific packing. Anything but the current way is pretty much random and up to the application. It's not really related to GtkOrientable per se, but it's specifically that when you change the runtime orientation you might also wish to reverse the packing order (I guess think about wishing to do a -90 degree rotation rather than a +90 degree rotation). Previously because you couldn't change the orientation, this was never something that came up. Does this clear up what I mean? --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable and GtkBox
Hi, On Wed, 2009-06-03 at 19:03 +0800, Davyd Madeley wrote: It's not really related to GtkOrientable per se, but it's specifically that when you change the runtime orientation you might also wish to reverse the packing order (I guess think about wishing to do a -90 degree rotation rather than a +90 degree rotation). Previously because you couldn't change the orientation, this was never something that came up. Does this clear up what I mean? Sure. But it would probably help to come up with a use case for this. I can not think of any good use case for changing the box orientation at run-time. And without such a use case, it becomes even harder to imagine that one would also want to reverse the packing order. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable and GtkBox
On Wed, Jun 3, 2009 at 7:18 AM, Davyd Madeley da...@madeley.id.au wrote: [...] In general though, GtkOrientable already exists. People are bound to use it. An example use case of this would be a custom toolbar that could be placed optionally on top or on the side of the workspace where the tool ordering is relevant, but thats not really the point right, aren't we more after making sure the use cases we haven't thought of yet are still valid ? ;-) I think a more interesting question is, what are we going to do with GtkVBox and GtkHBox, just keep them around for api stability ? Have them subclass GtkBox and override the orientation property to mark it as G_PARAM_READABLE only ? If we were to add a GtkBox:reverse-order property, would it still play fair in GtkBox subclasses ? hmmm I think so. Another worry is that pack start/pack end properties can already be confusing, will adding a reverse-order property make things more or less confusing to the user ? Just some thoughts, personally I think if start/end pack properties dont cut it then its probably worth just a little switch in GtkBox (sounds like more fun than manually repopulating boxes at runtime). Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable and GtkBox
From: Tristan Van Berkom, Date: 04/06/2009 00:13, Wrote: In general though, GtkOrientable already exists. People are bound to use it. An example use case of this would be a custom toolbar that could be placed optionally on top or on the side of the workspace where the tool ordering is relevant, but thats not really the point right, aren't we more after making sure the use cases we haven't thought of yet are still valid ? ;-) I have had a use case... Wasn't critical, just a two-pane window, and wanted to allow the two halves to be swapped. Since the thing was loaded from a glade file, it was a pain to do it manually, and I ended up just ditching the idea in favour or more useful functionality. A more significant case, is where I wanted to be able to rotate three widgets relative to each other though 90 degree increments. The end two were toolbar's, the middle one was the main set of controls, with separators between them all. Again, though it would have been handy thing to be able to do, it really wasn't worth the effort of implementing it. Another spot where it could be useful, is in toolbars. I could imagine grabbing the handle of a floating toolbar, dragging it to the other end, and having all the buttons reverse their order. Might be appreciated by right-to-left reading users... (By the way, is floating toolbars and menus actually useful yet...? There really needs to be a handle box which allows multiple toobars/menus to be attached to all four sides of a central widget...) I think a more interesting question is, what are we going to do with GtkVBox and GtkHBox, just keep them around for api stability ? Have them subclass GtkBox and override the orientation property to mark it as G_PARAM_READABLE only ? Is that really neccessary...? They could simply be used to specify the default orientation... With it having to be specified explicitly in the base Box class, perhaps? Old apps that don't know about the re-orientation, shouldn't be using it. But some of them may still make sense even if they don't know about it, if it can be asserted through styles, for example. Another worry is that pack start/pack end properties can already be confusing, will adding a reverse-order property make things more or less confusing to the user ? It's just defining an end and a direction... start and end still fit. Just need to describe them a little better, perhaps... This facility would allow allow for 90 degree rotation helper functions that do a orient-and-reverse combo. Fredderic LSAT Learn more about study prep, LSAT info and tips. Free info! http://tagline.excite.com/fc/FgElN1g1t3cOLKPdbTCLUznx4AU4tBJPehIUAIZh3oDIjuu6pEAa3vWGZKg/___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable and GtkBox
Hi, On Wed, 2009-06-03 at 13:32 -0400, Freddie Unpenstein wrote: From: Tristan Van Berkom, Date: 04/06/2009 00:13, Wrote: In general though, GtkOrientable already exists. People are bound to use it. An example use case of this would be a custom toolbar that could be placed optionally on top or on the side of the workspace where the tool ordering is relevant, but thats not really the point right, aren't we more after making sure the use cases we haven't thought of yet are still valid ? ;-) I have had a use case... Wasn't critical, just a two-pane window, and wanted to allow the two halves to be swapped. Since the thing was loaded from a glade file, it was a pain to do it manually, and I ended up just ditching the idea in favour or more useful functionality. what's so painful about: GList *list = gtk_container_get_children (GTK_CONTAINER (box)); gint pos = g_list_length (list) - 1; for (; list; list = list-next, pos--) gtk_box_reorder_child (GTK_BOX (box), list-data, pos); I haven't tried this, but unless I am mistaken this should reverse the order of children in a box. Seems easy enough to do and avoids the need to introduce yet another special case in the GtkBox code. Perhaps if this solution is not obvious enough, this should be turned into a utility function gtk_box_reverse_children_order() ? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable and GtkBox
On Wed, Jun 3, 2009 at 1:56 PM, Sven Neumann s...@gimp.org wrote: [...] I haven't tried this, but unless I am mistaken this should reverse the order of children in a box. Seems easy enough to do and avoids the need to introduce yet another special case in the GtkBox code. Perhaps if this solution is not obvious enough, this should be turned into a utility function gtk_box_reverse_children_order() ? Good point I over looked this api no need to ref, unparent, repack children, unref. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
glib uses wrong prefix for base-2 units
Hello, g_format_size_for_display uses the wrong prefixes for units that are counted in power of two. The SI defines following prefixes: k = 1000 M = 1000 k G = 1000 M ... Please use the IEC standard for binary prefixes: Ki = 1024 Mi = 1024 Ki Gi = 1024 Mi ... More information can be found here: http://physics.nist.gov/cuu/Units/binary.html http://en.wikipedia.org/wiki/Binary_prefix I have appended a patch for it. Here are some reasons why you should apply this patch: * It is the correct usage of the standards. * It would avoid ambiguity and consumer confusion: http://en.wikipedia.org/wiki/Binary_prefix#Consumer_confusion * The users want it. E.g. look at brainstorm: http://brainstorm.ubuntu.com/idea/4114/ http://brainstorm.ubuntu.com/idea/17839/ * The Linux kernel uses it (man units). Cheers, Benjamin diff -pruN glib2.0-2.21.1.orig/glib/gfileutils.c glib2.0-2.21.1/glib/gfileutils.c --- glib2.0-2.21.1.orig/glib/gfileutils.c 2009-06-03 01:04:20.0 +0200 +++ glib2.0-2.21.1/glib/gfileutils.c 2009-06-03 23:04:41.0 +0200 @@ -1714,11 +1714,11 @@ g_build_filename (const gchar *first_ele * @size: a size in bytes. * * Formats a size (for example the size of a file) into a human readable string. - * Sizes are rounded to the nearest size prefix (KB, MB, GB) and are displayed - * rounded to the nearest tenth. E.g. the file size 3292528 bytes will be - * converted into the string 3.1 MB. + * Sizes are rounded to the nearest size prefix (KiB, MiB, GiB) and are + * displayed rounded to the nearest tenth. E.g. the file size 3292528 bytes + * will be converted into the string 3.1 MiB. * - * The prefix units base is 1024 (i.e. 1 KB is 1024 bytes). + * The prefix units base is 1024 (i.e. 1 KiB is 1024 bytes). * * This string should be freed with g_free() when not needed any longer. * @@ -1739,17 +1739,17 @@ g_format_size_for_display (goffset size) if (size (goffset) MEGABYTE_FACTOR) { displayed_size = (gdouble) size / KILOBYTE_FACTOR; - return g_strdup_printf (_(%.1f KB), displayed_size); + return g_strdup_printf (_(%.1f KiB), displayed_size); } else if (size (goffset) GIGABYTE_FACTOR) { displayed_size = (gdouble) size / MEGABYTE_FACTOR; - return g_strdup_printf (_(%.1f MB), displayed_size); + return g_strdup_printf (_(%.1f MiB), displayed_size); } else { displayed_size = (gdouble) size / GIGABYTE_FACTOR; - return g_strdup_printf (_(%.1f GB), displayed_size); + return g_strdup_printf (_(%.1f GiB), displayed_size); } } } signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib uses wrong prefix for base-2 units
2009/6/3 Benjamin Drung benjamin.dr...@gmail.com: Hello, g_format_size_for_display uses the wrong prefixes for units that are counted in power of two. You may want to check the colour of the previous bike shed here http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00237.html Rui ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib uses wrong prefix for base-2 units
Benjamin Drung wrote: Hello, g_format_size_for_display uses the wrong prefixes for units that are counted in power of two. The SI defines following prefixes: k = 1000 M = 1000 k G = 1000 M ... Please use the IEC standard for binary prefixes: Ki = 1024 Mi = 1024 Ki Gi = 1024 Mi ... Oh god, let the flames begin... * It is the correct usage of the standards. True, but just because there is a standard, it doesn't mean it's a good standard. * It would avoid ambiguity and consumer confusion: http://en.wikipedia.org/wiki/Binary_prefix#Consumer_confusion Arguably, using KiB etc. in the user interface could confuse the user just as much. * The users want it. E.g. look at brainstorm: http://brainstorm.ubuntu.com/idea/4114/ http://brainstorm.ubuntu.com/idea/17839/ You mean: some vocal users of a single Linux distro want it. * The Linux kernel uses it (man units). No, the Linux man-pages project, which just happens to be hosted on kernel.org, uses it. I'm not completely against this kind of change (aside from the fact that I think kibi, mebi, and gibi sound retarded), but why change now? There are previous discussions about this: http://bugzilla.gnome.org/show_bug.cgi?id=301838 http://mail.gnome.org/archives/gnome-i18n/2007-May/msg00109.html ... that resulted in favor of leaving the prefixes as they are. What has changed in the meantime (these two discussions are 4 and 2 years old, respectively) that warrants revisiting this? Has there been new rampant widespread adoption? -brian P.S. As an aside, one could also argue to dispense with the use of the powers-of-two interpretation in user interfaces entirely. If Seagate/WD/etc. sells you a 500GB hard drive (500 billion bytes), wouldn't you expect to see 500GB in your file manager as the full capacity (well, minus filesystem overhead)? A non-technical user wouldn't expect to see 476, regardless of whether or not it's followed by GB or GiB. Aside from the (mostly irrelevant, slight) speed efficiency of doing division by 1024 via bit shifts rather than division by 1000 by actual division, what use does the powers-of-two interpretation have today? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib uses wrong prefix for base-2 units
Am Mittwoch, den 03.06.2009, 23:53 +0100 schrieb Rui Tiago Cação Matos: 2009/6/3 Benjamin Drung benjamin.dr...@gmail.com: Hello, g_format_size_for_display uses the wrong prefixes for units that are counted in power of two. You may want to check the colour of the previous bike shed here http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00237.html I do not want to discuss if we should use base 10 or base 2. I only want to discuss to use the correct label for base 2. glib should should label 2^20 with MiB instead of MB (like Linux, GNU Core Utilities, GParted, GNOME Network, Pidgin, Deluge already do)! Cheers, Benjamin signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib uses wrong prefix for base-2 units
On Wed, 03 Jun 2009 16:07:37 -0700 Brian J. Tarricone bj...@cornell.edu wrote: * It would avoid ambiguity and consumer confusion: http://en.wikipedia.org/wiki/Binary_prefix#Consumer_confusion Arguably, using KiB etc. in the user interface could confuse the user just as much. I make the same argument here as I made last time: I'd rather the idiots presume I can't spell, then the experts presume I can't count. In other words, pandering to the uninformed is no way to educate them and fix the situation. Yes; we messed up 30 years ago and said k when we meant Ki. Oops. Sorry about that. Lets not do it wrong for another 30, please? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable and GtkBox
On Wed, 2009-06-03 at 19:56 +0200, Sven Neumann wrote: what's so painful about: GList *list = gtk_container_get_children (GTK_CONTAINER (box)); gint pos = g_list_length (list) - 1; for (; list; list = list-next, pos--) gtk_box_reorder_child (GTK_BOX (box), list-data, pos); I haven't tried this, but unless I am mistaken this should reverse the order of children in a box. Seems easy enough to do and avoids the need to introduce yet another special case in the GtkBox code. Perhaps if this solution is not obvious enough, this should be turned into a utility function gtk_box_reverse_children_order() ? For the GtkBox case, this assumes that you're not going to be making any calls to pack_start() or pack_end() in the future. Otherwise you end up with the button ordering that is not independent of your orientation. -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib uses wrong prefix for base-2 units
2009/6/3 Benjamin Drung benjamin.dr...@gmail.com: Am Mittwoch, den 03.06.2009, 23:53 +0100 schrieb Rui Tiago Cação Matos: 2009/6/3 Benjamin Drung benjamin.dr...@gmail.com: Hello, g_format_size_for_display uses the wrong prefixes for units that are counted in power of two. You may want to check the colour of the previous bike shed here http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00237.html I do not want to discuss if we should use base 10 or base 2. I only want to discuss to use the correct label for base 2. glib should should label 2^20 with MiB instead of MB (like Linux, GNU Core Utilities, GParted, GNOME Network, Pidgin, Deluge already do)! No, you just want to have the same bikeshed argument that you've had over on the Ubuntu list here on GNOME's list. We've had these arguments made. We've had the discussion here twice. We've had it three times on Ubuntu's lists in the past two years I've been involved. Anyone want to chime in from Fedora's or SuSE's community and say how many times they've had it there? -A. Walton Cheers, Benjamin ___ 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: libsexy and project ridley
On Tue, Jun 2, 2009 at 12:39 PM, Javi javierjc1...@gmail.com wrote: If you agree, I can update the project Ridley page with the new changes. Feel free to add a section about libsexy to the project Ridley page. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ merges
As a data point, I've also preferred to go with cherry-picking from master so far. It just seems closer to the way I'm working with our branches. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable and GtkBox
From: Davyd Madeley, Date: 04/06/2009 10:59, Wrote: I haven't tried this, but unless I am mistaken this should reverse the order of children in a box. Seems easy enough to do and avoids the need to introduce yet another special case in the GtkBox code. Perhaps if this solution is not obvious enough, this should be turned into a utility function gtk_box_reverse_children_order() ? For the GtkBox case, this assumes that you're not going to be making any calls to pack_start() or pack_end() in the future. Otherwise you end up with the button ordering that is not independent of your orientation. I think gtk_box_reverse_children_order() might be a good helper to have, I've personally thus far been moderately afraid to delve into the inner structure like that. Though I think now after seeing that snippet, it does look pretty straight forward. Still, I would count it as non-obvious, though, on the grounds that if there is the question of people not understanding pack_start() and pack_end() properly, then there's definitely people who don't understand how these packing methods interact with the list of widgets in the box. But I think GTK+ needs more model-view separation, not less. If an application puts stuff into a box, it's kinda handy if it comes back out in a predictable fashion. Having to remember and compensate for the Especially if it wants to rearrange the boxes contents, without having to iterate through the box looking for the item it wants to move. (Imagine, for example, if it were possible that a style change could cause the boxes contents to be reversed part way through that gtk_box_reverse_children_order() call... I'm pretty certain that can't happen, but I think it's an apt analogy.) Fredderic Hit it out of the park with a new bat. Click now! Bats http://tagline.excite.com/fc/FgElN1g3ri4MRUqgf2duKtUVR9QTdqC4pfLYZBg1ef9D4fkNnmOSwvhbH36/___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list