[prev in list] [next in list] [prev in thread] [next in thread]
List: kfm-devel
Subject: Re: Konqueror and views (Re: kdebase/konqueror)
From: Michael Reiher <michael.reiher () gmx ! de>
Date: 1999-02-14 14:52:17
[Download RAW message or body]
David Faure wrote:
>
> Ok, from what has been said, we have only two solutions :
>
> * Create a KMultiPanner widget
> * Nest KPanners or QSplitters
>
> (btw, it seems that the main difference between KPanner and QSplitter is
> the look & feel : KPanner has a whole big line to split both children,
> whereas QSplitter has a thin line with a box on it. I prefer KPanner, like
> in current kfm...)
That depends on the GUI style. In motif style you have a motif like
splitter
(.i.e thin line with a box) and in windows style you have a splitter
that looks like the KPanner one. I would prefer QSplitter. Itīs IMHO
bteer to use QT widgets if QT offers them. This way we are also better
prepareded for QT 2.0.
>
> About the first solution, the main question is : what user interface do you (everyone)
> suggest ?
> I don't like "add view", for instance, because one has no idea where the
> new view is going to go. We have to elaborate something clear :)
> Once we agree on the functionalities of it, I could try to wrap up something...
Well, when I think it over split horizontally/vertically should be ok.
> Remember we want to be able to do something like :
> ------------
> | | |
> |-----| |
> | | |
> | |----|
> | | |
> ------------
> One of the problems I see is that in order to go to the next drawing,
> you have to align the horizontal lines first... Otherwise, the vertical
> separator can't be moved. And aligning two lines is not easy... :)
We could have a snaping zone there. Like windows snapping at the desktop
borders or other windows when you move them.
> ------------
> | | |
> | | |
> |-----|----|
> | | |
> | | |
> ------------ (figure 1)
>
> Some answers about the second solution below :
>
> On Sat, Feb 13, 1999 at 05:32:49PM +0100, Michael Reiher wrote:
> > David Faure wrote:
> > >
> > > > > On any view that is inside a KNewPanner, calling unsplit will replace the
> > > > > KPanner with a simple view, i.e. removing a view.
> > > > And there start the problems. How do we make it the it does what the
> > > > user expects? Which part of a panner sould be removed? If you have three
> > > > view side by side.
> > > >
> > > > |-----============|
> > > > | | | |
> > > > | | | |
> > > > | 1/1 | 2/1 | 2/2 |
> > > > | | | |
> > > > | | | |
> > > > |-----============|
> > > >
> > > > And the user wants to get rid of the middle one. But how should he know
> > > > which two views belong to one panner i.e. which view gets the freed
> > > > space?
> He would click on the middle one, select 'Remove view', which does an
> unsplit, and whatever view gets the free space, he can move it...
Ok!
>
> > > This is why I wanted to try it. I think there must a tiny visual difference
> > > between the above and the case 1/1 1/2 2/2.
> > But as those splitter are very thin that difference will be hard to
> > recognize.
> Yes, but it wouldn't really matter, in fact...
??? I donīt know what you mean. Do you mean a visual difference is not
neccessary?
>
> The only difficult case (for the developer) is when trying to remove the
> left one. Because then the toplevel panner has to become the right one.
>
> > > Anyway, to go the above drawn situation, the user last splitted the right
> > > view. So unsplit in 2/1 will revert to 1/1 2/2. I think it's not too hard
> > > for the user to understand that unsplit will revert the latest split :)
> > > (Thanks for the drawings, they make things clearer)
> > I guess it could be useful to save those structures with session
> > management:) So what if the user wants to unsplit several weeks later? I
> > think it is not good to rely on any structure. Everything should be
> > obvious and intuitive to the user. He must be able to just use it
> > without having much to think about it. Thatīs why I donīt like using
> > splitter hirarchies. Or at least we should hide them from the user but
> > that will be hard to implement.
> Not sure about this. "Split the current view" seems an intuitive approach
> to me.
>
> > > > Hmm..probably the best would be to remove the active view and then
> > > > devide the free space to the remaining views. Another thing is that if
> > > > the user wants to get an special result he has to pay attention in which
> > > > order he does the splitts. Or what if he has the following:
> > > >
> > > > ------------ ------------
> > > > | | | | |
> > > > | | |-----| |
> > > > |----------| and wants to get something like | | |
> > > > | | | |----|
> > > > | | | | |
> > > > ------------ ------------
> > >
> > > Unsplit, split horizontally, then split vertically in each window
> > No, just the other way round:). But thatīs not the point. If I imagine
> > to be Joe user (itīs very hard, I can tell you:) I would expect the
> > following: Just devide the upper and the lower part(whatīs possible
> > anyeay). Than we have 4 quarters.(I presume that the two new splitters
> > are in one line. There could help a snaping zone. But that are details)
> > Now I want not only to be able to move the vertical splitters(I mean the
> > two new) but also I want to be able to move the left and the right part
> > of the horizontal splitter separate. Besides I could imagine that many
> > people might use a quartered view.
> As I said above, you won't be able to move vertical splitters AND
> horizontal splitters at the same time. In the right drawing above, you
> simply _can't_ move the vertical splitter.
In that case thatīs true of course. See the following drawing:
(maybe we should join the graphics team:)
---------
| | |
| | |
|--+----|
| | |
| | |
---------
(Only) In these cases the user should be able to move *each* of of the 4
splitter bars.
>
> > > > > This way, the user can do really whatever he wants, splitting horizontally
> > > > > or vertically, resizing everywhere, up to an infinite number of views.
> > > > > The problem is that this requires a binary tree to store the views, not a
> > > > > list as I implemented it yesterday...
> > > > What I want to say is that all this is possible with binary trees but
> > > > will become quite tricky the more views you have and the more they are
> > > > nested in other views.
> [it was from the developer point of view]
> Well, everything in a binary tree is recursive. So it isn't more
> complicated when the tree is bigger. There are just so cases to think of
> (like the changing of toplevel panner, explained above)
Hmm, true.
>
> > > > > Another (simpler) solution would be a grid where every line can be moved,
> > > > > but it's more strict than the above : adjacent views must have the same
> > > > > height or width... (I should draw this to make it clearer) :)
> > > > Maybe we need to implement a special KMultiPanner class the doesnīt have
> > > > the limmitation of two parts. I fear anything else will end up in
> > > > limitations to the user.
> > > Where are the limitations in being to split any view in any direction ?
> > The problems come when you want to rearrange or remove views. Or see the
> > splitter problem above. Donīt assume only two or three views. There
> > might come up applications we donīt even think of, which need a more
> > complicated view structure.
> Yes, unless each view is either a view or a splitted view.
> The structure can become very complicated, this definition will remain true.
> With a self-defined widget, handling such cases will however become very
> complicated, I'm afraid, unless we manage to come up with something simple...
>
> > > ------------
> > > | | |
> > > |-----| |
> > > | | |
> > > | |----|
> > > | | |
> > > ------------
> > I imagine it like a table with several cells. Some of those cells ar
> > combined to larger cells. Further we have a list of splitterbars that
> > are connected with some cells. But to what cells a splitterbar is
> > connected may change dynamically depending on what the user does.
> So you see the above like a 6 cells grid ? I will be difficult to hide that
> >from the user, don't you think ? (moving from the above to figure 1) above
> means moving a lot of cells !)
Yes, 6 cells. The cell structure is only for the backend. Let me explain
how to reach figure 1.
------------
| 1 | 2 |
|--a--| |
| 3 b 4 |
| |-c--|
| 5 | 6 |
------------
At the beginning we have 6 cells(1-6) and 3 splitter(a-c). They could be
oranized in simple lists. The splitters are connected as follows:
(x/y means: take it as one)
a with 1 and 3/5
b with 1,3/5 and 2/4,6
c with 2/4 and 6
To get figure 1 move a and c so that they are in one line(they will snap
if the vertical distance between them becomes less then say 20 pixel)
------------
| 1 d 2 |
| | |
|--a--+--b-|
| | |
| 3 c 4 |
------------
We have 4 cells and 4 splitter now. Connections now:
a with 1 and 3
b with 2 and 4
c with 3 and 4
d with 1 and 2
Now move d. And weīll end up with the following:
------------
| 1 2d3 |
| | |
|--a-------|
| | |
| 4 c5 6 |
------------
Now there are again 6 cells and 3 splitters. Connections now:
a with 1/2,3 and 4,5/6
b with 1/2 and 3
c with 4 and 5/6
Know what I mean? All the operations should be relatively easy to
manage. Well, we might get some overhaed the more views we have. But I
think itīs no problem with a "normal" number of views. Also that
structure will be easy to save. So we can easily have different view
sets for file browsing, www browsing, and mail/news reader, an
integrated help system, what ever.
>
> > But be aware that is only a first idea. Iīm not even sure that it will
> > work like that.
> It would mean options like "merge cells" ? It's ok in a Winword array, but
> I'm afraid it doesn't mean anything for a file manager...
> Please elaborate on which user interface you imagine for it...
No "merge cells"! At least not for the user. For developers maybe.
Michael
--
Michael Reiher
Student at Dresden University of Technology
Department of Computer Science
email: michael.reiher@gmx.de
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic