Re: Panes behavior (a bug?)

[Owen Taylor <owt1 cornell edu>]

Jonathan Belson <jon@dookie.demon.co.uk> writes:

> On 02-Mar-98 Kenneth Albanowski wrote:
> >On Sun, 1 Mar 1998, Andy Tai wrote:
> >
> >> 
> >> The Panes behavior in gtk may be a bit odd.   Try testgtk, start the Panes 
> >> window, expand the window, drag one of the handles toward the right or
> >bottom
> >> then make the window small so the handle is now hidden.  I don't know if
> >this
> >> behavior is right or not, but it seems reasonable to have the handle always
> >in
> >> the visible area of the window.  This may be a bug, or is this the intended
> >> behavior?

Having the handle disappear off-screen is definitely a bug.

> >This reminds me of something else: is there any particular reason the pane
> >can't be resized by clicking anywhere on the separator bar? I realize the
> >"handle" is a useful focus, but the rest of the separator is essentially
> >wasted space, and it is physically easier to hit a long bar then a small
> >square with the mouse. 

There is no real real UI reason why it couldn't do that. (Except for,
as Patrice said, emulating Motif) From an implementors point of view
it makes things somewhat more complicated, especially in terms of
displaying a different cursor when the user can click to drag. I'll
put it  as a tentative item on the TODO list.
 
> Just to stick my oar in, shouldn't the panes also resize themselves when you
> resize the window?  To me it would make more sense if they kept the
> same ratio...

I'm not sure if I agree. When the needs to make a change, it is 
typically because one or the other pane is too small. If the top/left
pane is to small, the natural thing to do is to move the separator.
If the bottom/right pane, is too small, I think it may be more natural
to make the window bigger.

But in some cases, depending on the contents of the two panes,
it might make sense to use the ratio behavior, or even put all
the newly created space into Pane 1.

So, what I've been thinking of doing is adding an "expand" variable
for each pane, like the Box widgets. 

(For backwards compatibility, this would be set in a separate call,
and/or by creating new 

 gtk_paned_pack1 (paned, widget, expand);

to replace:

 gtk_paned_add1 (paned, widget))

There is some question of whether the excess should be given to
both widgets equally (which is what Boxes do) or in proportion
to the existing ratio. 


Finally, maybe making this application-settable isn't that great of an
idea. The worst problem is when the user expects something different
than what happens. Since I use Acroread and Netscape quite a bit, I
tend to expect the Motif behavior, so my inclination is to keep that
the default in any case. (Other people may disagree ...  what do
Win95, the Macintosh, etc do? (if they have paned windows))

Regards,
                                        Owen