[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-17 15:10:21
[Download RAW message or body]

On Tue, 16 Feb 1999, David Faure wrote:
>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).

Ok, you're right!

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

Well, I think making elements of Konqueror (in this case of Kfm) public
available via the IDL interface has the advantage that Konqueror is no more a
closed application but an really open "system" => One can "control" Konqueror
"remotely" . This might for example be useful for any kind of plugin
applications for Konqueror. Or just think of Torben's CORBA-Bindings for python
and kpython -> Users (!!) will be able to write scripts for Konqueror (if I
understood everything correct)

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

Oh, well, you're right. This class would be either KonquerorMainWindow or
KonquerorMainView (imho) .

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

Nothing, but Konqy sounds soooooo cuuuute (...for a killer-monster app)
;-))

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

yes yes yes! :)

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

The last sentence is quite exactly what I'm thinking of :-)
(assuming that you mean s/KfmGui/KonqGui/ , or? )

I'm thinking of KonqGui as a class/interface which provides the general
Konqueror GUI and which gives the "assigned" (most probably derived) view a
"chance" to sort of provide the view specific view menu.

Now if a KonqView inherits from KonqGui the general GUI will always be the
same, only the view menu will be "made" by the specific view.

But in case a KonqView has to kind of share it's KonqGui with other views (this
would be true for an all-in-one Konqueror part embedding several KonqViews)
we'd need only one single instance of KonqGui doing all the *bar handling,
except of course for the view menu.
And I think we can accomplish this by:

a) having a variable called m_vGui (or similar, doesn't matter) which
references the Gui object. Per default this will be a reference to itself if
the view runs as "standalone" part.

b) adding a call like void setGui( in KonqGui gui ) to KonqView.
A call to this method is necessary if the view has to "share" a Gui.

This way a KonqMainView (which also inherits from KonqGui) would call this
method of every emedded KonqView to make sure only one single GUI is used.

(there might be some additional management code necessary, but this should be
trivial I think)

It might be also possible not to let KonqView and KonqMainView inherit from
KongGui directly, but instead let them allocate a separate object instance and
share this instance.
Perhaps this is better...

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

I agree.

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

Now I'm really confused (sorry) .
Make KfmGui a part?


>> 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 didn't get any comment from Torben. I'm afraid he's not subscribed to
kfm-devel.

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

Well, my thoughts about the technical part aren't completely finished, but I
think it is be possible (if Torben would agree with some modifications on the
focus handling and therefore on some small design changes) .
I will ask him as soon as my thoughts are finished.

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