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

List:       kde-i18n
Subject:    Re: konqygui
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-02-17 18:25:41
[Download RAW message or body]

On Wed, 17 Feb 1999, David Faure wrote:
>On Wed, Feb 17, 1999 at 12:25:37PM +0100, Simon Hausmann wrote:
>> Hi,
>> 
>> I think it might be perhaps good to give a more detailed description about the
>> gui problem in regard to the "componentification of konqueror" thread. This
>> might help everyone to
>>  a) understand the real problem
>>  b) and it might help to bring up new ideas (hopefully :)
>> 
>> I will now assume that everyone agrees with David's proposal/drawing and
>> therefore also agrees that KonqViews should be embeddable parts (in general) .
>> 
>> <introduction_about_how_parts_"behave">
>(...)
>> </introduction_about_how_parts_"behave">
>
>Thanks for the explanations.
>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 ;-)

>> Now our problem is, independend whether we want an all-in-one embeddable
>> konqueror part or not:
>> We will be in the situation that our embedded KonqViews (not matter
>> whether they're embedded in a mainwindow or just in an all-in-one part) will be
>> activated/deactivated by the user pretty often (just imagine how often you
>> switch between htmlview and iconview once in a session) .
>Yup, and it's not only when switching between view modes, it also when switching
>>from left view to right view, which happens even more often when you have
>two views !

Exactly.

>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) .

>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?)

>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?)

>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?
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 :-)

>What do you think ?

I'm sorry, but I still have problems understanding everything :-}
Maybe you can give an example of how the "object-inheritance-tree" and
"visible-views-object-tree" would look like in a concrete practical situation?

>Of course, this doesn't solve the problem whether KfmGui is a part too -
>but then I think it could be, if you implement the menu-merging solution.

I'm not quite sure how to bring the KfmGui-as-gui-class into this proposal.
*help*
:-)

Ciao,
 Simon

--
Simon Hausmann - Tronical^Colorfast - <tronical@gmx.net> - IRCNet #colorfast

we have joy, we have fun, we have linux on our sun

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