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

List:       kde-i18n
Subject:    Re: konqygui
From:       David Faure <David.Faure () insa-lyon ! fr>
Date:       1999-02-17 21:15:36
[Download RAW message or body]

On Wed, Feb 17, 1999 at 07:25:41PM +0100, Simon Hausmann wrote:
> >It really looks like this is good only for koffice documents (well, the
> >views of those documents), not for konqueror normal (html & filemanager) views.
> 
> *agree*
> That's why I'm thinking about a sub-kind-of-gui-hidden-focus mode for parts
> in general :-)
> (name it the don't-let-the-big-evil-mainwindow-know-that-the-active-part-
> changed mode ;-)

I'm not sure I fully understand the sub-kind-of-gui-hidden-focus.

I understand the goal of it ("don't let the ...") but not how it would work.

> >I have an idea, following to my remark above : there are two completely
> >different things we want to do :
> >* use several 'normal' views, often : the HTML and filemanager views
> >* use, sometimes, another app. embedded in konqueror, for reading mail, ...
> 
> Hm, for the second thing I thought of implementing another KonqPartView which
> inherits from KonqView ("using" your previous design proposal, not the one
> below) and implements this functionality (should be trivial, especially in
> regard to our focus-gui-stuff problem) .

And would a KonqPartView contain one directory, or several of them ?


Let's try to make this clear.

In a big konqueror window, we want

       (A)          (B)
---------------  ----------
|      |      |  |        |
|      |      |  |        |
|      |      |  |        |
---------------  |        |
|      |      |  |        |
|      |      |  |        |
|      |      |  |        |
---------------  ----------

(A) : a view with 4 directories

(B) : a outlook-like view        (I'm changing my mind, I'm afraid. A HTML
                                        view could be such a view too)


In my first proposal, the above would be 5 views, of different kinds. And
this would involve lots of menu-switching.

In my proposal below, the above would be 2 views (renamed as KonqPart) : a 
KonqPartImpl on the left, another kind of part on the right (any kind of
part in fact)
(A) would be composed of 4 views, which could be IconView, TreeView, ...

What do we want ?
5 views, all kinds of view being equal
or 2 views, in order to switch the menus only when switching from (A) to
(B).

> >Why not do a KonqView, only one, that can contain several ... hum...
> >"sub-views", those being either HTML, Icons, ...
> >And kfmgui will be able to embed other views, i.e. from other apps.
> >
> >Let's go for another drawing, I'll let you do the IDL.  :)
> >
> >I had yet another namespace problem, so I will name the IDL interface for a 
> >"view" (previously "KonqView") as "KonqPart".
> >
> >
> >             KonqPart   - the IDL interface
> >               |
> >          -------------------------------------------
> >          |                    |                    |
> >        KonqPartImpl      "OutlookLike"View        ...
> >       
> >
> >KonqPartImpl the implementation of KonqPart as done in konqueror (I'm very
> >bad at finding names). (Do we really need two names here ?)
> >The holding of KonqParts in KonqGui could be done just like a koffice app,
> >then. Some sort of MDI. Because when using konqueror as a file manager /
> >web browser, it would be always in the same window.
> >
> >A KonqPartImpl holds several KonqViews, arranged in a KMultiPanner or whatever widget.
> 
> And how does KonqGui hold the KonqParts? (KMultiPanner&friends, too?)

No, rather the usual way for a koffice window.
Normal mdi... Although this would be confusing.
Other solution : allow only one "big view" (A or B above) at a time.
When reading mail, you need 3 views - no room for 3 other views browsing
files...

> >This enables to keep the same Part (in terms of IDL / openparts), while
> >browsing, and therefore reduces flicker a lot.
> 
> Uhm, why does it reduce flicker? I thought KonqViews are still embeddable parts,
> right? (or does the drawing below not show that KfmView, HTMLView inherit from
> an abtract interface/class named KonqView?)

KonqView would not be a part, just a bit of the KonqPartImpl, which is the part.
See ? If you want to embed 4 views, create a KonqPartImpl with 4 views ; if 
you want to embed 1 view, create a KonqPartImpl with 1 view.

> >The different kinds of KonqView would be organised this way :
> >
> >                  KonqView
> >                     |
> >          ------------------------
> >          |                      |
> >         KfmView              HTMLView     
> >          |
> >      -----------------------
> >      |           |         |
> >     IconView  TreeView    ... 
> 
> What's the reason for "separating" KfmView, HTMLView and "OutlookLike"View ?
> If I understood all this right "OutlookLike"View inherits from KonqPart, the
> other two views inherit from KonqView (which I see as completely separate
> interface/class, right?) , but why?

I have been wrong about HTML. Let's make it simpler : the above tree would be

        KonqView
          |
      -----------------------
     |           |         |
     IconView  TreeView    ... 

> IMHO all three views should do the job as viewer/browser of "something" , no
> matter whether they're part of a Konqueror Shell or anything else, or?
> That's why I currently like the previous propsal a lot. But I'm looking
> forward for more good arguments to convince me to this way :-)

This proposal states "a part (an embeddable one) can be composed of several 
views (not embeddable alone)".

What do you think ?

-- 
 ____________________________________________________________________
|                                                                    |
|  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]