[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-23 18:54:40
[Download RAW message or body]

On Mon, 22 Feb 1999, David Faure wrote:
>On Sat, Feb 20, 1999 at 10:24:57PM +0100, Simon Hausmann wrote:
>> Hi,
>> 
>> I finished writing a draft of the new Konqueror interfaces and I tried to
>> explain some things in regard to the a-common-gui-for-Konqueror problem.
>> 
>> Please let me know what you think of it, what you think is perhaps missing or
>> what is actually wrong (it can be easily possible that I forgot something or
>> there's a fundamental error in my thoughts).
>
>I don't understand the difference you make between GUI and MainWindow.
>As I understand it, in a konqueror process (application), there can be
>several windows. Calling it MainWindow is just a sight of the mind. BTW,
>koffice calls MainWindow every window, even if you have several windows in
>e.g. kword. So a GUI (in kfm) is a MainWindow (in konqueror). I would
>remove any instance of the word and the concept of GUI. In KDE, everything
>is a GUI :)

I'm sorry, but you're wrong:
If you embedd KPresenter in KSpread for example you actually do _not_
use/embedd/whatever anything MainWindow related from KPresenter but instead you
embedd a KPresenter View of a KPresenter Document. KPresenter's Mainwindow is
not used in any way (only if you start KPresenter standalone, then KPresenter's
MainWindow becomes the shell).
The Mainwindow's task as a shell is to  
 a) manage the *bars (better: host the *bar-managers)  
 b) know about the active part  
 c) know about the parts captions
 d) handle some stuff in regard to activation/deactivation of parts
 e) provide _some_ standard GUI elements for this application (as standalone
     app) 
 f) share some of these with the current active part (file/help menu)

And from the technical point this also leads to the fact that you can not embedd
an OpenParts MainWindow (or a derived KOffice MainWindow if you want) , because
the MainWindow interface simply does _not_ inherit from OpenParts::Part.

>Why not make it the following ?
>
>  interface MainWindow : OpenParts::MainWindow

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

>  interface Application : OpenParts::Application
>  {
>    MainWindow createKonquerorWindow();
This is "duplicated" as createMainWindow() in OpenParts::Application.

>Hum, I think I'm wrong here - you speak about the GUI interface quite a lot 
>in your INTERNALS document. So the concept might be needed, but I miss its
>definition, probably missing a better name for it.
>
>As I see it, there are
>* views inside a MainWindow inside the konqueror application, 
Yes.

>* views inside another MainWindow, inside another application. 
No. (see above)

>Where does the concept of GUI comes into this ?

The OpenParts concept of a GUI is like this:
(now assuming Torben would agree to my part-child/part-parent thing)

The Mainwindow as shell provides a basic skeleton of standard GUI elements (you
know this from KOffice) .
Every part which is _not_ a child part can create additional GUI elements (via
the two eventCreateMenuBar/eventCreateToolBar events which are sent indirectly
by the Mainwindow) . (and theoretically a part could also create persistent
toolbars)
Plain child parts instead loose quite all possibility to provide an own GUI,
instead the parent part gets notified (by an event) when the child part gets the
focus (becomes the active part) . Then for example the parent part could tell
the child part to create GUI "stuff" by letting the child access the parent's
GUI controls via their defined interfaces.
In case of Konqueror this is event more tricky: The notify event is filtered by
the Konqueror GUI implementation (assuming we'd use my IDL draft)

>Thanks for your lights :)

Need more? =)

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]