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

List:       kfm-devel
Subject:    Re: konqueror components (was Re: konqueror issues)
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-02-16 19:15:06
[Download RAW message or body]

On Tue, 16 Feb 1999, David Faure wrote:
>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 FULLY AGREE!

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

I AGREE AGREE AGREE AGREE! :-)

So let's see what we can get out of these interfaces (I left out the KfmGui
stuff, I'll write about it later) :

(I like drawings a lot, too, but IDL also looks nice :-)

(again: just a quick draft of what Konqueror _might_ look like)

const string eventOpenURL = "Konqueror/View/OpenURL";
typedef string typeOpenURL;

interface KonqView : OpenParts::Part
{
   //this is perhaps the _magic_ method
   //we could make it emit simply an event "openURL" and this event
   //can be filtered by KOMPlugins and has to be mapped by
   //every view interface which inherits KonqView
   void openURL( in string url );
   string url();

   + all the stuff David mentioned in one of the previous mails

  //what do you think?
  signal void started( in string url );
  signal void completed();
  signal void canceled();
}

interface KfmView : KonqView
{
  //KfmView mapps the openURL event to the openDirectory method, ok?

  void openDirectory( in string url );
}

struct UDSAtom
{
  string m_str;
  long m_long;
  unsigned long m_uds;
}

typedef sequence<UDSAtom> UDSEntry;

interface IconTreeViewItem
{
  string url();

  boolean isMarked();
  void mark( boolean flag );

  UDSEntry udsEntry();

  boolean acceptsDrops( in StrList formats ); 
  //StrList is defined in openparts_ui.idl

  //more stuff.... I'm too lazy now for this ;-) I just want you to get
  //an impression of what this all might become
}

interface IconViewItem : IconTreeViewItem
{
  ...
}

interface TreeViewItem : IconTreeViewItem
{
 ...
}

typedef sequence<IconViewItem> IconViewItemList;

interface IconView : KfmView
{
  void selectedItems( out IconViewItemList list );

  void updateDirectory();
}

interface TreeView : KfmView
{
  ...looooots of more stuff...
}

interface HTMLView : KonqView
{
  void openURL( in string url, boolean reload, in long xoffset, in long yoffset,
                        in string postData );

  boolean isFrameSet();

  ..more_and_more...
}

//do we still want this all-in-one-standalone-konqueror part?
//(see below for further discussion about this)
interface KonquerorMainView : OpenParts::Part
{
  long addView( in KonqView view );   //returns id
  KonqView activeView();
  KonqView view( in long id );
  void removeView( in long id );

  setViewPosition( in long id, ...position stuff here );
  position_enum_or_whatever viewPosition( in long id );
}

I think these are the basic Konqueror (now talking about the killer-app as one
thing) components, stuff like OutlookView is perhaps better "part" of KOutlook
(KMail or whatever) and might be made usable via a smart plugin interface which
looks for apps on startup which support KonqView's or so... :-)

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

You're absolutely right.

BTW, KonqyView is nice......ah, no, it's KonqView :-)

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

I guess there was probably a misunderstanding anywhere, but: I LIKE YOUR
PROPOSAL A LOT and it fullfills all my "requests" of independency ;-)

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

I wonder what the exact reason for my current headache is, either _this_
problem/part of the discussion or the alcohol from last night's carnival party,
most probably both ;-)

s/KfmGui/KonqGui/;

=> I think KonqView should inherit from KonqGui because this way _all_
Konqueror Views have a consistent GUI !

But the question is imho:

(in order to use the new "naming convention" :
s/KfmMainWindow/KonquerorMainWindow/;
)

Should we use KonquerorMainWindow as big shell which contains KonqViews and for
example contains all the qplitter-stuff? (notice that in this case there'd be no
more an all-in-one embeddable konqueror part, just like the _current_ KfmGui !)
In this specific case the implementation should be quite easy (as far as I
thought about it) and my headache would be gone totally ;-)

Or do we still want to have an all-in-one-big Konqueror Part which is
embeddable?
(in this case we would be in the situation to do some (bad?) hacks with KonqGui
in order to solve the above mentioned problems with menu-merging, the part
focus and stuff.)
I actually don't think it's impossible, but I expect it to be perhaps a lot of
work.

(I myself am actually not quite sure what I personally do like best.... ;-|
OTOH I don't want to "drop" the all-in-one part but OTOH the
KonquerorMainWindow stuff is perhaps a cleaner solution in regard to the
OpenParts design in general (very IMHO) ). => other opinions please :)

Byebye,
 Simon (which is now really tired -> writing this mail was very strenuous for
       my brain :)


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