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

List:       kde-i18n
Subject:    Re: konqy views again (Re: copy/move strategy and the reincarnation of
From:       Matthias Welk <welk () fokus ! gmd ! de>
Date:       1999-04-07 8:45:42
[Download RAW message or body]

On Wed, 07 Apr 1999, Michael Reiher wrote:
>David Faure wrote:
>> 
>> On Tue, Apr 06, 1999 at 02:36:49AM +0200, Michael Reiher wrote:
>> > David Faure wrote:
>> > >
>> > > On Mon, Apr 05, 1999 at 08:33:09PM +0200, Michael Reiher wrote:
>> > > > David Faure wrote:
>> > > > >
>> > > > > > > * N-level nesting, each view being a possible splitter - then the UI is the
>> > > > > > > one above - I think that's what I wanted to do from the beginning, but
>> > > > > > > someone said it would be too complicated to go from a vertically-splitted
>> > > > > > > set of views to an horizontally-splitted one...
>> > > > > > This would be the best, I think(see above). But I somehow don't get why
>> > > > > > you(or who ever said this) want to go from a vertically splitted set of
>> > > > > > views to a horizontally splitted one??
>> > > > >
>> > > > > "who ever" ????? _you_ said this !
>> > > > Ooooooops:}} Right, now as you say it I remember... Well, internally I
>> > > > already rejected that wish, because it would be too complicated.:-) And
>> > > > if we have a clear strategy how we handle view splitting, the user will
>> > > > get used to it, and not miss it(I hope).
>> > > > I consider the discussion we had(below) as a little brain storming. And
>> > > > I often tend to make everything as complicated as possible:) So I think
>> > > > we should forget about that thing. Makes everything easier.
>> > >
>> > > ok.
>> > > If I understand well, this means :
>> > > no for N-level nesting, but we still have to find something else than the
>> > > current implementation...
>> > Well, no:-) I'm for N-level nesting but without the vertical <->
>> > horizontal changing thing.
>> 
>> Michael, this solution makes it very complicated to have, for instance, 3
>> views side by side.
>I still don't see the problem. Maybe I got wrong what you meant with
>N-level nesting? %-|
>What I mean is the following: 
>Initially the MainView contains a single view. If the user selects
>"Split ..." The view is replaced by a splitter containing two new views.
>(Either the "old" view is reparented before and then inserted as the
>first child of the new splitter or it is deleted and replaced by two new
>ones with the same URL, but that doesn't matter in fact). If he later
>splits one of the childs again, the same procedure: replaced the view
>with a splitter containig two new views. This will result in a binary 
>QSplitter tree. 
>And that way deletion of views should be quite easy, as well. A splitter
>always contains only two views/child splitters. So if you want to remove
>a view just delete it, reparent the remaining view/splitter to the
>parent(this is either another splitter or the MainView) and delete their
>splitter.
>> As you pointed out, 3 views would mean a main splitter with one view
>> splitted, and the user can't know why. This doesn't even take advantage of
>?? The user won't see a difference between one QSplitter with three
>childs and the QSplitter with another splitter nested as a child. In
>case the nested
>splitter has the same direction as the parent, you will in both 
>cases have a row/column with three views.
>
>> the fact that the current QSplitter allows more than two children.
>But nobody forces us to use that feature.
>> 
>> At least we have to find a solution where 3 views side by side are, in
>> terms of widget, 3 views in the SAME splitter.
>Why, do they have to be in the SAME splitter?? 
>

If they are not in the same splitter, then resizing the widget in the
top-splitter resizes both widgets in the nested splitter. That's propably not
what the user expects if their are 3 widgets side by side, but I think your
suggestion is the best solution ;-)

>I would go and implement that thing, if nobody objects.
>
>Michael
>(who is really happy to be back at his development machine:)))
>
>> 
>> --
>> 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
>
>---
>Michael Reiher  
>     Student at Dresden University of Technology
>          Department of Computer Science
>               email: michael.reiher@gmx.de

Greetings, Matthias.
--
---------------------------------------------------------------
From: Matthias Welk                   voice: +49-30-3463-7272
      GMD Fokus                       fax  : +49-30-3463-8272
      Kaiserin-Augusta-Allee 31       email: welk@fokus.gmd.de
      10589 Berlin
----------------------------------------------------------------

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