[prev in list] [next in list] [prev in thread] [next in thread]
List: kfm-devel
Subject: Konqueror and views (Re: kdebase/konqueror)
From: David Faure <David.Faure () insa-lyon ! fr>
Date: 1999-02-14 0:51:53
[Download RAW message or body]
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...)
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...
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... :)
------------
| | |
| | |
|-----|----|
| | |
| | |
------------ (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...
> > 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...
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.
> > > > 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)
> > > > 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 !)
> 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...
> Anyway we should plan that very carefully, in order to make konqueror as
> open and as easy to use as possible.
Sure, that's the point of the current discussion...
--
____________________________________________________________________
| |
| David FAURE |
| E-mail : David.Faure@insa-lyon.fr, faure@kde.org |
| http://www.insa-lyon.fr/People/AEDI/dfaure/index.html |
|____________________________________________________________________|
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic