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

List:       kfm-devel
Subject:    Re: konqueror components (was Re: konqueror issues)
From:       David Faure <David.Faure () insa-lyon ! fr>
Date:       1999-02-16 21:33:38
[Download RAW message or body]

On Tue, Feb 16, 1999 at 08:15:06PM +0100, Simon Hausmann wrote:

(ok for all the rest - settled unless there are objections)

> interface KfmView : KonqView
> {
>   //KfmView mapps the openURL event to the openDirectory method, ok?
Not always. openURL might want to open a file, to exec a program...
I think this is why there is currently a KfmRun and a KRun classes. (Look at
KfmView::openURL current implementation).

>   void openDirectory( in string url );
> }

> struct UDSAtom
> {
>   string m_str;
>   long m_long;
>   unsigned long m_uds;
> }
> 
> typedef sequence<UDSAtom> UDSEntry;

This is already defined in libkio headers, isn't it ?
Oh you mean defining them in the IDL...

Well, only if necessary.

The *Item classes are internals of the related Views aren't they ?
Why define them in the IDL ?

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


> //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 );
> }

We need such a class, of course. Whether it's a part or not, ...

We have to take a decision as the user... A embeddable _view_ will be
useful for opening files (ex: KFileDialog), for browsing a directory, ...
A embeddable GUI with several views would allow to copy and move files from 
within any other app. Well, this may be cool, but I think it's less
important.
Which means, if we can do it technically, let's do it - but if it can't be
done, it's not a big deal.

> BTW, KonqyView is nice......ah, no, it's KonqView :-)
How much did Stephan give you ?       :))
(Explanation : he promote "konqy" on kde-cvs, to avoid gender problems...)

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

> => I think KonqView should inherit from KonqGui because this way _all_
> Konqueror Views have a consistent GUI !
I don't see the relation ... Most menus _apply_ to the current View, but
only one menu (View) is different depending on the current 'kind of'
view. (Well, not all of it - in its current form)
This menu could be implemented by the View itself, but all the rest should
be left in KfmGui...
(To see what I'm talking about, look at the current kfm : lots of items get 
disabled in the View menu, when switching from HTML mode to FileManager
mode. In fact the View menu could be created by the View itself, with only
its elements - more modular but a bit more confusing for the user...
Of course the view mode switching can't be in it - it hardcodes the list of 
the other modes of view...

> 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 ;-)
As I said above, I think "let's go for this first and see"... We will
always be able to turn KfmGui into a part when we want, won't we ?
The sad result is that we have to convert KfmGui back to what it was some
week ago !! :))

> 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.)
Did you get Torben's comment on this ? There was none on this list.
I'm not yet master of this technology, I can't help in such things.

> I actually don't think it's impossible, but I expect it to be perhaps a lot of
> work.
So the real question is : do you think we can manage to do all the rest
(the *View, ...) and decide after 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]