GNOME Bugzilla – Bug 104979
control center sets toolbar key to both_horiz
Last modified: 2004-12-22 21:47:04 UTC
I've got the gnome toolbar settings set to "Text beside icons". Epiphany doesn't do this however. Also, epiphany's toolbar no longer has a drag handle (which i've also set in gnome).
Reassigning to EggMenu
Marco: Are you sure this is really a libegg problem? I just tried changing the toolbar settings through the control-center while having yelp & epiphany both running (both use the libegg toolbar afaik). Epiphany & yelp both correct update their toolbars if i select "Icons only". If i select "Text beside icons" though, yelp correctly updates, but Epiphany changes instead to "Text below icons". Seems like a problem with how epiphany handles the toolbars (or uses old libegg code).
Yelp apparently use gtk_toolbar, at least head. I'm using test-merge in libegg and that behaves like epiphany.
*** Bug 108097 has been marked as a duplicate of this bug. ***
*** Bug 110711 has been marked as a duplicate of this bug. ***
reassigning to new toolbar component
[CC-ing Jonathan and moving to control-center] The problem here is that the control center sets the key to "both_horiz". It works if you set it to "both-horiz". I am attaching the trivial patch to gnome control center. However it's possible that this is really a glib bug ("glib should allow underscores when it parses enum values"), but I haven't looked into that.
Created attachment 16024 [details] [review] s/both_horiz/both-horiz/
*** Bug 108952 has been marked as a duplicate of this bug. ***
Fixed the capplet on both branches.
This is not a very good fix: * all gnome applications expect "both_horiz", we can't just change it without expecting to break stuff. * stuff does break :), due to a bug in libbonoboui applications can crash when an unknown toolbar style is specified in the gconf key. Better patch coming up...
Created attachment 16374 [details] [review] Better fix
I thought GTK+ canonicalized param strings to accept both '-' and '_'. Timj did it for languages using GTK+ where that makes more sense: eg. (signal-connect tree-view "row-collapsed") makes a lot more sense than (signal-connect tree-view "row_collapsed") in a lisp-like language. It's possible that style properties aren't canonicalized in this fashion, but I think they should be to be consistent, if nothing else.
*** Bug 112729 has been marked as a duplicate of this bug. ***
Marking critical, since this crashes things (like bug 113182)
*** Bug 113182 has been marked as a duplicate of this bug. ***
*** Bug 113106 has been marked as a duplicate of this bug. ***
I'm not that sure supporting horiz placement without priority make sense. Most toolbars would go out of screen. I guess it's matter to decide if priority text is good from an usability point of view and then fix gtk to support priority or fix control center removing the horizontal thing.
I think there is a misconception by soeron that the usability team is completely against prioirity text. If you look at the mailing list archives that he mentions, what took place is that seth was considering prioirity as a default over tradition icons+text (icon above the text). However further discussion led to the decission that icons+text as a default is better than prioirity text. We did not say prioirity text is plain bad and shouldn't be used at all. In fact in the case of text on the right not using prioirity text makes this toolbar layout sort of pointless.
*** Bug 118094 has been marked as a duplicate of this bug. ***
Fixed.
*** Bug 146216 has been marked as a duplicate of this bug. ***
*** Bug 145691 has been marked as a duplicate of this bug. ***
*** Bug 146238 has been marked as a duplicate of this bug. ***