Re: [gtk-list] Re: Panes behavior (a bug?)

Jonathan Belson wrote:
> On 02-Mar-98 Owen Taylor wrote:
> >
> >Jonathan Belson <> writes:
> >
> >> On 02-Mar-98 Kenneth Albanowski wrote:
> >> >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
> >
> >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.
> On the Amiga, both MUI and ClassAct allowed you to resize a panel at any place
> along the border but neither changed the cursor when over the 'drag zone'.  It
> would be a good idea, though.

Is it possible to let the user choose how the separator bar shall be

I would like most of the X-applications that I use to be a bit less
"fluffy", for
example the separator line could be thinner if there where no "drag
button" (like
Win 95/NT4).

> >> 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.
> Can't say I agree here 8^)  For example, imagine an ftp tool with two directory
> would expect them to remain the same size if you resized the
> window to eg. see a long filename in its entirety.
> If I was using a multi-panelled application I would start by arranging the panel
> sizes to suit my purposes, and it would be offputting to have to re-adjust them
> every time I changed the window size...
> >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.
> Again, I think it would be more intuitive to keep the window the way
> the user arranged it.  Adding the expand argument would be a reasonable
> solution though.

But inconsistent, why not make it a user settable choice?

> >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
> Motif did bug me a bit when I switched to using X, especially the file
> requesters which are guaranteed to make the file list too narrow 8^/
> >the default in any case. (Other people may disagree ...  what do
> >Win95, the Macintosh, etc do? (if they have paned windows))
> I can't think of any paned apps on the Mac, I'm reasonably sure Win95 uses
> ratios (the GTK behaviour struck me as unusual as soon as I saw it).

Just switched display to find out that NT4 does:

If you enlarge the window it will expand the pan at the lower/right

If you decrease the size of the window, it will start to minimize the
pane in the lower/right side untill it dissapears (to reapear when size
is encreased again), then it will take on the next pane and so on...

> What do you other folks think?
> C-YA
> Jon


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]