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

List:       kde-i18n
Subject:    Re: konqueror components (was Re: konqueror issues)
From:       David Faure <David.Faure () insa-lyon ! fr>
Date:       1999-02-16 16:04:20
[Download RAW message or body]

Ok, I did my drawings, and here is my proposition about konqueror design :

Part I : reflexions

It seems obvious that IconView, TreeView, and HTMLView need to inherit from 
a common parent, which we would call KfmView, for the moment.
Either this parent is an interface or a real class with some code (and this 
was the main difference between my suggestion (KfmViewContents) and Simon's).

You said "views [would be] completely independend objects which inherit
from an KfmView interface to provide a common kind of API to access a view."

If they are completely independent, they would implement the KfmView
interface each with its own way. Then the current code in KfmView needs to
be moved somewhere else...

What is this code ?
In short, openURL, openDirectory, slotURL, stop, popupMenu handling, and focus
handling.

The important point is whether future views implement this code too (and
then it's part of the View interface) or whether the code is specific to a
file manager.
I think it would make sense to apply most of those methods to any View,
even a mail view or an image view.
Of course, it would be implemented another way (for a mail reading,
openDirectory lists the mails in a mail 'folder' (i.e. a file)

But they are implemented the same way for the two view modes that implement
file manager functionality.

So the solution I see is :


Part II - Proposal

First, name the general interface for a View "KonqView".
I'm not playing on words, I need "KfmView" later.

Then I would create a class that implements KonqView for File Manager purposes :
This would be "KfmView" (fm = file manager, right ?)
It would implement the code of the previously mentionned methods, and is
inherited by the two kinds of file-manager view.
The HTML view would implement it differently, and so would other future
views (mail, ...)


(a drawing, I like drawings - don't look at this with a font with serifs !)

           KonqView   - the IDL interface
               |
          ---------------------------------------------------------
          |                     |            |                    |
        KfmView              HTMLView     "OutlookLike"View      ...
          |
      -----------------------
      |           |         |
     IconView  TreeView    ... 
(more if we extend the file manager views - we dropped text, details, and
 tree with directories only from kfm II...)


> No, that was a really misleading waste of namespace by me ;)
> I mean the IDL KfmView interface (not the current KfmView class) as common
> parent interface for all possible view types.
Agreed. Let's name if KonqView, it has nothing to do with a File Manager.

> In contrary to this I thought of views as even more separate components, not of
> a KfmView (like the _current_ class) containing ViewContent objects and
> displaying them (well, the name isn't that bad :) but instead of views as
> completely independend objects which inherit from an KfmView interface to
> provide a common kind of API to access a view.
They can't be completely independent if you don't to implement the same
thing twice in TreeView and IconView.

> (this way it'd be possible for apps to create their own kfm views and "add"
> them to konqueror (here as KfmMainView) . For example KMail might provide a
> kmail-kfm-view to process mails "inside" konqueror when browsing the web)
> In addition I think we might add a fourth (fifth?) part kfm view which does
> nothing else than embedding other apps parts (for apps not wanting to "use" a
> common kfmview parent interface) .
All this remains true, as I agree with the general IDL interface for a view.


> >> interface KfmView : OpenParts::Part, KfmGui
> >> {
> >>   void openURL( in string url );
> >>   string url();
> >> 
> >>   What else can be here?
> >> }
I'm still not sure, however about whether KonqView should inherit from
KfmGui. KfmGui implements the menus, but you're right, we want menus in
KfmView too... (in case it's embedded in another app). How to handle this
gracefully ? No idea for the moment.
In the above, I was only thinking of the internal view functionality. The
menu handling depends mainly on the way openparts allows us to deal with
it, and you (Simon) know a lot more than me about this.

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