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

List:       kfm-devel
Subject:    Re: draft+thoughts
From:       David Faure <David.Faure () insa-lyon ! fr>
Date:       1999-02-25 23:45:40
[Download RAW message or body]

On Thu, Feb 25, 1999 at 07:32:46PM +0100, Simon Hausmann wrote:
> 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.
Ok. I think I got it.

It will be easier to understand when you commit it, anyway :)

> >> >* 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 :)
No offense at all !! You didn't sound angry :)

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

(your drawing, which looks fine in my xemacs :) )

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

Ah, that's what the MainView is. Ok, I got it.

> This is my idea of the layers.
> Or did I miss anything, David?
Nothing. I'm just a bit slow to understand :)

> >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?
I had another look. ok, there is currently a lot of duplicated code between 
kfmfinder.* (i.e. the TreeView) and kiconcontainer.* + kfmicons.*
(including the list of functions that I pasted in a previous post, in fact
the View Properties stuff) but ... (see below)

> 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. 
.. if a KonqBaseView exists, it could store the View Properties stuff, so
it's fine. No need for the common parent I talked about.
Well, I think so.

Hum, for instance, showDotFiles means nothing for a HTML view ...
So either we had a common parent for icon and tree views, which will have
this showDotFiles stuff, _or_ we just have all the functions for any view,
but changing showdotfiles for a HTML view will do nothing, of course.

> (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?
This is great ! Not simply "ok" !


David,
.. looking forward to the new konqueror.

(But take your time - the basics have to be set, it's difficult to
coordinate changes otherwise)

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