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

List:       kde-i18n
Subject:    Re: draft+thoughts
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-02-25 18:32:46
[Download RAW message or body]

On Thu, 25 Feb 1999, David Faure wrote:
[...]
>> As I mentioned above: This way we'd loose our MainView as embeddable all-in-one
>> Konqueror part and replace it with an not-embeddable OpenParts MainWindow of
>> Konqueror (from the users point of view there's actually not difference, but
>> IMHO we still might want this all-in-one thing, right?)
>Yes, but then it's the GUI we want to embed, right ?
>How do we do it if it inherits from Kom::Base only (it's not a part, is it
>?)

I think we want to embedd the view. But this plain view, as is, wouldn't have
any GUI elements. Well, of course it _could_ have these by mapping the
eventCreate{Menu/Tool}Bar events, but we don't want that. Instead we create (or
use the mainview's one, depending on the way we use a view) a new GUI
implementation (most likely we use the Konqueror GUI, but theoretically it
would be possible for an app to provide it's own GUI for the Konqueror View) .
This GUI object first needs a part where it can "filter" out the two
eventCreate*Bar events (well, in fact it does not really filter them out via an
event filter but instead of the part itself, the GUI registers to the
*barmanagers of the mainwindow which actually send the eventCreate*Bar events).
And in addition a view has kind of GUI clients, the views. These views get
two events (see konqueror.idl) if they either get the focus as child part (of a
mainview) or if the GUI part gets the focus (then the eventCreate*Bar events
are sent to our GUI object ) . In the last case only the current active view of
course receives the two GUI/View related events to create their view specific
GUI elements.

>> >* views inside another MainWindow, inside another application. 
>> No. (see above)
>I meant, for instance, a KPresenter View inside the MainWindow of kspread.
>(kspread being the 'application' as well).

Ah, oh, I'm sorry, it seems I misunderstood you. (and sorry if my statements
sounded angry or so, it was not my intention to offend you in any way. Please
forgive me :)

>But you're right, we need another 'layer' if we want to embed a whole
>konqueror GUI (= several views).

Yes, that's right.
I'll try to make a little drawing of how I think of these layers in regard to
the parts (this is only the mainwindow/parts hierarchy, not in view of the
Konqueror's GUI stuff) :
oooops, I spent about 15 minutes to draw this in kmail.... without success :(
But I attached it (after I did it with another editor) .

Comment to this drawing:
a) the konqueror view does not really have to be embedded at the level of the
mainwindow. In fact it doesn't matter _where_ it gets embedded, one will always
use an OPFrame to do this, so for example the konqueror main view might be
embedded in a part as well (this is the way KOffice does it, except
KoShell) .

b) The htmlview and the treeview are child parts of the konqueror main view
(this is important) . And as often explained: On activation of these parts
the part will get the focus and the parent (=in this case the mainview) will be
notified about this via an event. In our case this event will be filtered by
the Konqueror GUI implementation which tell the view(=part) to build it's
view specific GUI stuff.

This is my idea of the layers.
Or did I miss anything, David?

>Something else : you didn't make a common parent for IconView and TreeView
>(both relate to file management and have a lot in common) 

Yes, that's a good idea.
What common stuff did you think of for example?

>Is it possible to have a common parent in C++ and not in the IDL interface 
>?
Yes, that's no problem.

And in fact I did this for all views: All Konqueror Views (on c++ level)
inherit from a class called KonqBaseView (not visible as IDL interface)
which contains some common code. 

(oooopps, I perhaps didn't tell you: I already started to work on the basic
skeleton code. If anyone has any objections against the current design
following David's proposal number one and my IDL draft please 
>> SPEAK UP NOW << :) 
Otherwise I will put the not-really-doing-anything-yet code in CVS ASAP so that
everybody can help creating the new konqueror. 
Is this ok?
)

>If not, the IDL needs to be modified I think. 
*agree*
I already did some other modifications, too.


Byebye,
 Simon

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

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



["bad_drawing.txt" (text/english)]


 the "hosting" mainwindow
/-------------------------------------------\
|                                           |
| /----------\   /------------------------\ |
| | any part |   | yap (yet another part) | |
| \----------/   \------------------------/ |
|                                           |
| /---------------------------\             |
| | our konqueror mainview    |             |
| |                           |             |
| | /----------\ /----------\ |             |
| | | htmlview | | treeview | |             |
| | \----------/ \----------/ |             |
| |                           |             |
| \---------------------------/             |
|                                           |
\-------------------------------------------/

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