Please remember that in some languages, the menu names will be about twice their current width. Do you really want the document window forced to be that wide?
Currently the menu takes about 25% of my screen horizontally, so we definitely have some room to grow. Besides, we'll also have much more stuff in the secondary toolbar that will also stretch the window horizontally (although of course we must be very thrifty with space there and add important things closer to the left side)
Forgetting for the moment what the standard widgets can currently do, what do you think the best way to deal with uncomfortably wide menus is?
I don't think it's an issue at this time. Inkscape will have big menus inevitably, since it's a complex application. Gimp now has 10 menus; it simply cuts the menubar when window is resized small - I don't like that, I'd prefer the menus to be reflown in 2 or more lines (does GTK support that?)
_________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=dept/features&pgmarket=en-ca&RU=http%3a%2f...
On Wed, 2003-12-24 at 17:34, bulia byak wrote:
Forgetting for the moment what the standard widgets can currently do, what do you think the best way to deal with uncomfortably wide menus is?
I don't think it's an issue at this time. Inkscape will have big menus inevitably, since it's a complex application. Gimp now has 10 menus; it simply cuts the menubar when window is resized small - I don't like that, I'd prefer the menus to be reflown in 2 or more lines (does GTK support that?)
Gtk doesn't really support either behavior, actually. I suspect what the GIMP does is force its menubar to request 0 width in size_request.
Doing a flow-based layout in Gtk is actually sort of an interesting problem because of the way Gtk layout works.
In Gtk, a container invokes each child's size_request to determine how much space each of them want (a GtkRequisition). Then it performs its layout algorithm, and notifies each child (via size_allocate) of the position and dimensions (GtkAllocation) it has given that child.
Of course, containers themselves are also children, so they report the size they used to lay out their children to their parents when their own size_request is invoked.
Now, here's the problem: a container doing vertical flow needs to know the width its parent is prepared to give it _before_ it can respond meaningfully to size_request, but Gtk provides no facility for the parent to provide that information.
The problem is probably not insoluable, but I can't think of any easy solutions offhand.
-mental
participants (2)
-
bulia byak -
MenTaLguY