On Sun, 14 Feb 1999, David Faure wrote: [....] >> >Does this mean that a foreign application can either embed only a >> >special selection of the available views or via kfmgui all-in-one? So >> >kfmgui is somehow another layer between the views and the KfmMainWindow? >> >Then my favorite would also be solution 2. >> >> Exactly! > >That's a very good thing, then. We want other apps to be able to embed >either one view or all of them... Let's hope we'll succeed in making konqueror a collection of nice components :-) >> KfmGui as layer would contain all the panner-stuff you're currently discussing >> about and some general menus. (did I forgot anything?) We might create a KfmView interface for each possible kfm view. Then we might create four view interfaces, derived from the KfmView interface (speaking in IDL) : (just a quick-one-minute draft) interface KfmGui: KOM::Base { (see below for further details) } interface KfmView : OpenParts::Part, KfmGui { void openURL( in string url ); string url(); What else can be here? } interface IconView : KfmView { view specific stuff } interface TreeView : KfmView { view specific stuff } interface HTMLView : KfmView { view specific stuff } //a view for part plugins, with one speciality: On activation it doesn't make //use of KfmGui to create *bars but instead really activate it's part interface PluginView : KfmView { setPart( in OpenParts::Part part ); OpenParts::Part part(); what else can be here? } And then there's (the current) KfmGui, renamed to KfmMainView to avoid name conflicts with the already defined interface: interface KfmMainView : OpenParts::Part, KfmGui { (...all the current stuff...) addView( in KfmView view ); //this is for the kmultipanner/qsplitter-guys ;) KfmView view(); plus some other stuff } >> But this brings me to another point: What could possible view-related menus >> contain? What for example could be html-view related menu entries? >> >> Putting it in other words: >> How should the menus for >> a) kfmgui >> b) the specific views >> look like? > >a) : everything in the current konqueror (plus some items in the Options >menu that were in kfm II), except b) below :) > >b) : The current View menu, with "Split window" removed, of course. >It's the only menu that contain View-specific stuff (view mode, html mode, >show dot files, ...) > >The problem is that if you embed a kfmview in another app, you might want >to be able to access the menuitems currently found in most other menus (File, >Edit, Bookmark). I don't remember how it works for KOffice. How are the >file / edit / help / ... menus merged ? >Does the app shows the menus of the embedded app only ? Yes, there's no merging for the menus. But for our menu-merging-whatever problem I've got a piece of an idea (I did not finishing thinking about it, so it's just a quit draft. Maybe it even doesn't work... ) : We might create an special KfmGui interface which every kfm view and kfmgui _has_ to inherit from, too. This interface is responsible for creating all general menus (and the konqueror toolbars, too) and might in addition provide a pure virtual function which gets called upon creation for the menus. This function has to be implemented in every kfm-view and should create only the (or only one?) view specific menu(s) . The point is that a kfm-view doesn't map the createMenuBar event but instead this event is eaten (and used :) ) by our KfmGui interface, which then builds all the general menus and then gives the kfmview (or KfmMainView) a chance to build it's specific menus. Another point is the focus of "embedded" views in case we use KfmMainView..... Hm... I see that there's a lot more to think of. Actually I'm running out of time for further thoughts about it (for today), but I hope I can finish my thoughts tomorrow :-) . This is just a short draft kicked out of my brain's door into the world of flame emails ;-)) Ciao, Simon (...dreaming of the future's konqueror 8) -- Simon Hausmann - Tronical^Colorfast - - IRCNet #colorfast we have joy, we have fun, we have linux on our sun