[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: On splitters behaviour on resize...
From:       "Friedrich W. H. Kossebau" <Friedrich.W.H () Kossebau ! de>
Date:       2001-03-01 19:10:34
[Download RAW message or body]

Hi!

I'm glad you are responsing. I was about to think my massive mailing is
annoying... :)

> > What do you think if splitters could be set by users directly how to
> > behave when the splitted widget is resized?
> > If they have two child widgets there are three possibilities:
> > 1. keep relation
> > 2. only resize left (upper)
> > 3. only resize right (lower)
> >
> > A little symbol on the splitter would show both the status and enable
> > new setting. So one could prevent to have to add to each widget a
> > setting whether it is resizeable or not while delivering the same time a
> > visualization.
> 
> Unless I'm totally confused (always a distinct possibility) you are
> talking about panes within a window. Panes can be different views of the
> same underlying data (as when you use the black handle to split a Word
> document) or they can have independant contents (like Netscape's
> Messenger window).

KSplitter was the name of the klib's widget, so I thought the name is
splitter. Sorry. No, I refer to the splitting bar, not the panes (I
addressed child widgets). Not the handling bar of a plugged widget
(===========OX) but the splitting bar which can be used to adjust which
pane gets how much space of the full window (======== in KDE,
---------#- in Motif ).

> I'm usually in favour of giving the user fine control of the UI, but in
> this case I don't see that adding Yet Another Option to control window
> resizing behaviour is going to enhance the UI. And adding a visible
> status symbol on the splitter will just clutter the screen.
> 
> Resizing from the LOWER RIGHT toward the TOP LEFT:
> 
> aaaaaaaaaaaaaaaa           aaaaaaaaaa......
> aaaaaaaaaaaaaaaa           aaaaaaaaaa......
> bbbbcccccccccccc   ---->   bbbbcccccc......
> bbbbcccccccccccc           bbbbcccccc......
> bbbbcccccccccccc           bbbbcccccc......
> bbbbcccccccccccc           ................
> bbbbcccccccccccc           ................
> (16x7)                     (10x5)
> 
> Resizing from the TOP LEFT toward the LOWER RIGHT:
> 
> aaaaaaaaaaaaaaaa           ................
> aaaaaaaaaaaaaaaa           ................
> bbbbcccccccccccc   ---->   .....aaaaaaaaaaa
> bbbbcccccccccccc           .....bcccccccccc
> bbbbcccccccccccc           .....bcccccccccc
> bbbbcccccccccccc           .....bcccccccccc
> bbbbcccccccccccc           .....bcccccccccc
> (16x7)                     (10x5)

Where did you notice this behaviour? It would be very intuitive but in
reality all apps behave as if you were doing a resize from lower right
to top left and moving that much what you resized.
 
> Notice that in the second example, both the "a" and "b" panes were in
> danger of disappearing all together. Once you hit a minimum size for a
> pane, it stops shrinking and you start shrinking the next pane instead.
> 
> Except in this extreme case, resizing the panes independently has one
> big advantage over keeping the ratio constant: the displayed widgets and
> data in each pane are moved the least. If you keep the ratio the same,
> every time the user resizes the window, every pane is affected, which
> means that every pane needs to be redrawn, and all widgets move. This
> makes for big screen redraws and data that won't sit still.

But keeping the ratio is the default of each splitted view: Look at my
favorite annoying example (of course only for this thing :) : Have the
directory view on the left and do a resize of the whole konqueror
window. Just a minute before did you adjust the width of the dir view
and now... *##</

That is where I got my idea from: Having an option (direct accessible on
the splitter and showing actual setting) to 'fix' the dir view. So a
short resize to have more space on the screen wouldn't redo my dir view
adjustment. 

As there are a lot of other apps whose window is composed of some panes
it might be very useful to have ksplitter with this feature.

> Resizing from the LOWER RIGHT toward the TOP LEFT, keeping panes in the
> same ratio:
> (bad design, in my opinion)
> 
> aaaaaaaaaaaaaaaa           aaaaaaaaaa.....
> aaaaaaaaaaaaaaaa           bbbccccccc.....
> bbbbcccccccccccc   ---->   bbbccccccc.....
> bbbbcccccccccccc           bbbccccccc.....
> bbbbcccccccccccc           bbbccccccc.....
> bbbbcccccccccccc           ...............
> bbbbcccccccccccc           ...............
> (16x7)                     (10x5)
> 
> Notice that in the resize only method, the user is only suprised by
> jumping content if he tries to shrink a pane beyond the minimum size.
> But in the constant ratio method, this happens all the time.

Yes, but imagine a konqueror with a norton commander profile: The user
thinks both panes to be of equivalent importance so both should be
resized the same.

So there are examples for the fitting of both behaviours. That is why I
think the user should simply be enabled to decide what suits him best by
having this little switch.

Friedrich

[prev in list] [next in list] [prev in thread] [next in thread]