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

List:       kde-i18n
Subject:    Re: KMultiPanner
From:       David Faure <faure () kde ! org>
Date:       1999-03-25 13:35:46
[Download RAW message or body]

On Tue, Mar 23, 1999 at 11:54:07AM +0100, Matthias Welk wrote:
> On Mon, 22 Mar 1999, David Faure wrote:
> >After fighting some more with QSplitter, I have another thought about KMultiPanner...
> >;)
> >
> >> Known problems:
> >> - rubber band of nested splitters is not drawn
> >My English is very bad. What's rubber band ?
> >
> 
> I took the word from the Troll's. I think it's the line that will be drawn if
> you move the splitter-handle.

Ah ok ! That's what I pointed out in my first reaction to KMultiPanner.
Any chance to fix that ?

> >> - children can only be added to a splitter at first or at last (this is a
> >> limitation imposed by the qt-api)
> >I wanted to ask you : is there any way to remove this limitation ?
> 
> Look at the new version of KMultiPanner at:
> 
> http://www.fokus.gmd.de/research/cc/cats/employees/matthias.welk/private/

Ok, I will, as soon as I find time for it.

> I have made an ugly little hack to get the new widget at the right position.
> All children of a splitter are stored in a list. If I add a new widget, then it
> will be inserted at the right position. After this I go through the list and
> call moveToFirst().
> Yes I know, it's very ugly, but I could not find any other solution.

Oh, KMultiPanner uses QSplitter ? In this case, I don't see the point
in using KMultiPanner... It will have the same bugs and shortcomings as
QSplitter...
(except for inserting widgets at any position, but you say it's a hack)
As we don't want the very complicated user interface that you realised was
necessary for using all features of KMultiPanner, and if KMultiPanner uses 
QSplitter, I still have to be convinced ! :)

> <Dreaming on>
> How about a splitter that let's you add new children completely free via a
> "ghost child" like the toolbar? It docks automatically at possible positions if
> you move it with the mouse.
> <Dreaming off>

That would solve the problem of 8 menu entries for adding, I completely agree.
I like the idea, but I see some problems in the way the user would use it : 
a toolbar is already present, you just move it. How would you move a child
if it doesn't exist yet ? A "add" menu item, that would add the child at
the bottomright position, and then you move it ? Why not...
But given the number of views one will have, I find all this really
complicated for nothing...

OTOH, I have no idea how difficult it is to implement the 'dream' above.

-- 
David FAURE
david.faure@insa-lyon.fr, faure@kde.org
http://www.insa-lyon.fr/People/AEDI/dfaure/index.html 
KDE, Making The Future of Computing Available Today

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