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

List:       kfm-devel
Subject:    PartChild(Mode)
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-02-18 15:13:52
[Download RAW message or body]

Hi

(I'm not sure if you read the discussion on kfm-devel about the new Konqueror
design, so I'll try to describe the problem as short as possible)

The general idea is to make Konqueror a big set of components. One kind of these
components (the perhaps most important ones) are Konqueror Views, views which
are used to display _anything_ . This can be for example ("included" in
konqueror) an icon view, a tree view or a html view.
The point is, that we want these views (the base interface will be called
KonqView) to be full-featured parts, meaning on the one hand they should be
embeddable and useable by every application and on the other hand they should be
content of something we call KonqMainView, a kind of shell for Konqueror.
Now the other thing is that this KonqMainView should be an part as well.
This should make it possible for an app to either use one of the view kinds
"directly" as embeddable component as well as just "using" (and also embedding)
a complete Konqueror "shell" .
This also means that we're not planning to make real use of a KonqMainWindow
(inheriting from an OpenParts MainWindow) .

I'll try to come to the real problem by giving two example situations:

(1) Imagine an application which wants to _use_ and embedd an icon view from
Konqueror. If such an embedded view (=part) gets activated it should create
(provide) the standard konqueror gui plus view specific menu items in the view
menu.

(2) Think of KoShell which wants to embedd a "complete" Konqueror. In regard
to the new Konqueror design KoShell wants to embedd (and perhaps
also "use" it via it's interface) KonqMainView then. This KonqMainView displays
all it's views as embedded parts (this would make it possible for example to
embedd a KMail-View, too, if KMail would support an interface derived from
KonqView (which is the base Konqueror view interface)) . Now when KonqMainView
gets activated it should (obviously) create the standard Konqueror gui again.
What now happens is that the user frequently switches between the embedded
Konqueror views. And this would usually create a lot of focus switches and
menu-/tool-/statusbar rebuilds (because the mainwindow got notified about
the focus switch) which is (obviously) not what we want. Instead we want (in
this case) the standard Konqueror gui always to be visible (as long as
KonqMainView is active from the users point of view) , only some entries in the
view menu should change when switching views inside KonqMainView. As you might
have already guessed this idea/design is in conflict with the fact that the
embedded views are parts as well.

What I now would like to see in OpenParts would a kind of part child mode for
parts:
When a part child gets active, the mainwindow it's registered to does _not_ get
notificed about this (and therefore there will be usually no *bar rebuilds) but
instead the part parent gets notified.
I think this would be a solution and the rest of the problem in regard to a
common Konqueror gui for all embedded views is not related to openparts itself.

My question to you is now quite simple:
Are there any objections against such a part child/part parent thing ?


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