Re: GtkOrientable and GtkBox

["Freddie Unpenstein" <fredderic excite com>]

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!
	Click Here For More Information