Warning, /frameworks/kparts/COMMENTS is written in an unsupported language. File is not indexed.

 2) provide some way to save/restore the positions of the menu/toolbar(s)
    when changing the active part ( I remember Reggie asking for that :)
 
 (David) Sounds good. I might have a look at that next.
 Comment : the menubar is cleared, not destroyed, so it seems we don't have
 to do anything for it (it remains where it is). We still need to save
 the BarPosition of the toolbars, though (see comment in
 KTMainWindowGUIBuilder::createContainer).
 (David) : With Torben's idea of inheriting KTMW, the problem of accessing
 the BarPosition of the toolbars is solved. Nice :-)
 
 (David) Not sure we want to save whether the statusbar is shown/hidden.
 
 (Simon) Another thought: Perhaps we should store the geometry information of
         the containers of the KPartHost in the KPart itself?
         (something like KPart-Session Management ;-)
 (David) Sounds strange (the child taking care of its host's containers...)
 In SM, it's the host (the WM) that stores the position of its children (the
 windows) :-)
 One possible problem (I'm not sure) : are the toolbars shared between the host
 and the part, or are there only toolbars for one and toolbars for the others ?
 In the first case, there's a problem because the toolbar will remain when
 switching part, so shouldn't get moved back when switching back.
 In fact we only want to store the position of the toolbars that fully "belong"
 to the part, right (i.e. that only contain items from the part) ?
 In this case, yes, that could be saved in the part.
 
 --------------
 
 4) Perhaps a part wants to know if it got activated, so we might want to
    re-introduce that PartActivateEvent from kdelibs/kparts.
    Question: Shall this event be sent when the GUI of the part is activated
    or shall it be sent when the part "really" got activated (via KPartManager)?
 
 (David) Any example of usage ?
 I think what it wants is "really" activated, no ?
 
 (Simon) Konqueror for example wants to know when it gets activated, in order to access the KPartHost
         and query for the container objects (*bars) .
         Hmmmmmm, that sounds like two possible events. A PartActivateEvent and a GUIActivateEvent...
         What do you think?
 
 (David) 1 - I don't see the difference between "the gui of the part gets activated" and "the part
 gets activated", in this simple model (no Document/View). The Part gets activated when you can see
 its items in the menus/toolbars, there is no "in between" IMO ?
         2 - Remind me what konq does with the *bars when a part gets activated ?
 I couldn't find anything with a quick grep in the sources...
 I'm still looking for an example when it's useful :)
 
 (Simon) I think that's the whole idea of making KPartManager independent from
         the guibuilder. Perhaps some apps wants to embed stuff without showing
         the parts a full-fledged gui (remember the part-children thingy in the
         old OpenParts? ;-) ) . Konqueror is one example. However I think
         KOffice could benefit from this, too, for the inplace editing
         (where the part is active, in terms of the KOffice document/view model,
         but still has a different gui or even none at all) .
 
 (David) : I start to see :-)
 But what I don't see is how does KPart know whether it's activated
 simply or activated with its GUI... i.e. how does it know the way
 it is embedded (with or without GUI items). Hmmm..
 
 
 (Simon) Konqueror (2) : When a parts get activated (this is "detected" via
         KonqViewManager) , then in general the actions of the view get plugged
         into the menus and the main toolbar (which is acccessed via
         Shell::viewToolBar() (hmmm, I'm looking forward to the new KParts :-)
 (David) Ah yes we don't have that in "example" currently. Dynamic actions.
     So you would add an event (or signal) to KPart for that ? Sounds ok to me.
 
 (Simon) That means that the (old) KParts doesn't know anything about the
         embedding in Konqueror.
 (David) Didn't get that ?!? :-)
 
 --------------
 
         BrowserView inheriting KReadOnlyPart is the way to go, IMHO.
 
         The question if Konqueror itself should be a KPart is difficult.
         All the BrowserViews are embeddable already, so it's "questionable"
         if it makes sense to have the embeddable Konqueror shell (KonqMainView) .
 
 (David) indeed.
 
         OTOH that shell makes these views "interact", makes them switch. So if
         someone wants to embed a browse-all-stuff widget, then embedding Konqueror
         would probably be cool, as the mainview handles all the stuff like determining
         the correct mimetype, loading the view, receiving and sending openUrl requests, etc.
         Something like a shoot-and-forget for embedding ;-) (embed-and-forget ;)
         Loading and saving in that case would mean save/load the view profile.
 
 (David) Hmmm... somebody wanting to embed a full konqy ? Component technology allows
 you to avoid duplicate code by embedding a component that does what you want. Like kdevelop
 embeds a kedit component. Which app would want to embed a huge component containing
 a file maneger + a web browser + a generic viewer + ... ? I think this is not a component,
 but an application. Views are components...
 
 (Simon) Yes, that is true.
         What about this: We don't make Konqueror's Mainview a KPart, but still
         use the XMLGUI and the pluginaction stuff. (because these two things
         are importan and very nice IMHO). (I don't want to miss the action
         stuff in Konqueror, neither you I guess :-)
 
 (David) Sure, actions rock. But KTMainWindowGUIBuilder exists for that exact
 reason, no? The mainview would be a KTMainWindow, so its GUI is described in
 XML and with actions.
 
 
 ------------
 (David) This lib offers :
 KReadOnlyPart for viewers
 KReadWritePart for editors
 KPart for a generic part (?)
 
 We could easily port BrowserView to inherit KReadOnlyPart, and call it
 KBrowserPart.
 Proposed changes :
 - The action stuff gets ported, of course (structs disappear)
 - started/completed/canceled already exist -> removed
 - setStatusBarText() -> see below, wondering about status bar
 - setLocationBarURL() -> removed - konqueror will set it from url()
     [ is that correct ? ]
 
 (Simon) I think we still need it. When a view gets a redirection signal, then
         it wants to change the displayed URL.
 (David) Ah right (I think support for redirection is missing from konqueror on
 the whole, at other places).
 
 - openUrlRequest and createNewWindow remain.
 
 (Simon) <sidenote> We will want to add a serviceType argument to openUrlRequest.
         At least we need it to get rid of these changeViewMode() hacks in
         konq_htmlview/konq_iconview :P
 (David) ok
 
 - popupMenu remains ?
 
 (Simon) What about putting that popupMenu into an extension interface,
         contained in libkonq? IMHO the popupMenu is very libkonq specific.
 (David) Depends how we want to handle the popupmenu in KonqHTMLView, for
 instance.
 At the moment it's missing, and it will be a problem when that view is moved to
 kdelibs : no more libkonq for it. But anyway I agree : the part should
 generally take care of its own menu (I'm thinking of KNotePadPart for instance)
 Perhaps this would remain in KBrowserPart though (we need it in konqueror).
 
 ----
 
 On second thought : why should we make KReadOnlyPart different from
 KBrowserPart ?
 Any "viewer" should be embeddable in konqueror. The additional signals we
 currently have in BrowserView could be simply added to KReadOnlyPart, and
 it doesn't make it more complex (kedit can simply not care about the loading
 progress, the popupMenu signal, ...)
 In fact the loading progress should even be emitted by KReadOnlyPart
 itself (it handles the kiojob), for the simple cases. Of course
 konqueror views will reimplement openUrl and send the signals themselves.
 The main problem I see is that BrowserView is asynchronous
 and KReadOnlyPart is .. a bit of both (asynchronous for remote URLs,
 synchronous in openFile()). But for konqy, openFile() means nothing
 and never gets called (because openUrl is reimplemented).
 For the history stuff, we can provide the default implementation
 in KReadOnlyPart (just like we did in BrowserView).
 About the "offset stuff" - well it even makes sense in kedit
 so the host can ask for going to a particular line when opening the
 file (hyper cool !). Anyway, for parts which have nothing to do with
 offsets, this gets simply ignored.
 
 In short, we can take advantage of the fact that we have a lib now,
 as opposed to an interface alone (BrowserView), and provide default
 implementations (when possible, for example the history stuff)
 which make every "viewer"-type part a part useable in konqueror
 - but also in koffice, and whereever.
 
 This would reduce the number of "type of parts" and make it simpler
 to embed anything into anything. OTOH, it makes KReadOnlyPart a bit more
 difficult to understand.
 
 What do you think ? Did I overlook something ?
 
 (Simon) I don't think there's a problem with the async stuff
         (BrowserView/KReadOnlyPart) . Mosfet's KGhostView browserview or
         his dviview are both 100% like KReadOnlyPart (yes, they launch KIOJob::copy()
         and copy the file to some local temp) . It works :-) and noone complains :-))
         -> I see no problem with that :-)
 (David) Sure - but does that answer the question : KReadOnlyPart==KBrowserPart ?
     Now that I think of it, it's probably not a good idea - there are many
     things that BrowserPart has in addition, finally. I'm still not sure. I
     like making it simple, but this might be an over-simplification.
 
 ------------
 
 (Simon) About KXMLGUIBuilder<->non-KTMW builder: One possible case coming to my mind are dialogs. If you want to
 embed a small "part-applet" ;) (perhaps as embedded preview part for some open-foo-dialog?) , then a non-KTMW
 builder might be useful (and might have containers) .
 I don't see any problem in having a separate (abstract) interface for the GUI builder. We gain flexibility
 IMHO, and taking into account that this KParts stuff should probably be something highly finalized for
 KDE 2.0, its worth having as much flexibility as possible (while keeping it easy to use by providing the
 easy-to-use KTMW implementation) , IMHO.
 
 (David) Excellent idea !! A part in a dialog :-) Don't think you can have that in Windows :-))
 But .. how can you have containers (menubars, toolbars, ...) in a dialog ? Or were you thinking of
 another kind of container ?
 
 (Simon) Containers in a dialog? See kfd :-))
         (altho kfd uses ktmw AFAIK ;)
 (David)  ... because there is no support for toolbars in a dialog.
     I still think you can't have containers in a QDialog :-)
 
 (Simon) Another possible thing is perhaps kpropsdlg. IMHO it'd be cool if
         it would be very easy and simple to add new props pages for certain
         mimetypes dynamically via shlibs.
 (David) Sounds good but not very useful. :-)
 
 ---------------
 
 (Torben) I did not follow the latest discussions due to a lack of time. However, I made some
          small remarks on stuff I did not understand (yet?).
 
 (Torben) KReadWritePart and KReadOnlyPart use the three signals canceled, started, completed in
          two different contexts. One can not see wether a KReadWritePart started loading or
          started saving. I would like to introduce
          a) three new signals for KReadWritePart
          b) A parameter to the signals telling wether this is a read or write operation.
          Basically I am in favor for a small API -> b)
          And b) is source compatible to the current solution!
 (David)  ok
 
 (Torben) In example.cpp addPart is called twice and each time the active part is changed. Would not it be
          more clever to add parts and activate one later instead of activating the last one inserted ?
 (David) no no, example.cpp doesn't even know when the active part changes.
 Did you try running the example ? It features a part that is dynamically
 embedded and de-embedded, the notepadpart. That's why there is an addPart()
 call - to add the new part when the user asks for it. Not when the active part
 changes.
 
 (Torben) You guys are busting QDOM. You can NOT assign an element of document A to an element of document B.
          That means: There is no way to mix two documents. What you are doing is asking for trouble.
          The ownerDocument() function will not work as one might expect after the assignment: The element
          of B assigned to A will still claim to be a child of B :-(
          And there are few chances that this may change in the Qt implementation in the next few weeks.
 (to myself) I tro to fix that in QDom ....
 
 <weis> Hi
 <dfaure> Hi !
 <weis> dfaure: Just looked into new kparts
 <dfaure> ah ?
 <weis> dfaure: You have a major problem: One can NOT mix QDomElements of different documents!
 <dfaure> weis: why ?
 <weis> dfaure: Because the ownerDocument wont change as one might expect.
 <dfaure> weis: not sure I have the full picture (Simon did that part). What should we do instead ?
 <weis> dfaure: Either I manage to hack QDom (very hard) or ..... dont know currently ....
 <dfaure> the problem is .. memory management, right ?
 <weis> dfaure: I just checked in my CVS irc stuff :-)
 <dfaure> ok :-)
 <weis> dfaure: Can you have a look at kparts/COMMENTS ?
 --
 <dfaure> weis: you should have come before. coolo is talking about re-writing libkio.
 <dfaure> well in fact he started the rewrite
  dfaure having a look
 <weis> dfaure: Unfortunately I am not paid for KDE but for Qt hacking :-( So I fear I have no time for kio anyway.
 <dfaure> weis: I know that, but perhaps a little discussion would help him with the new design :)
 <weis> dfaure: So you are not convinced by his design ?
 <weis> dfaure: It is about this daemon that forks and loads ioslaves as libs, or ?
 <dfaure> yes, this looks fine
 <dfaure> but then what about filters, and especially the problem is the API
 <dfaure> each slave currently implements stuff like recurse copying
 <dfaure> and we would perfer that in a single location, obviously :-)
 <weis> dfaure: Thta is true!
 <weis> dfaure: The new design would mean: We write an abstract interface for basic IO stuff.
 <dfaure> yup
 <weis> dfaure: Basically every slave would have to implement usual UNIX IO functions.
 <weis> dfaure: Does coolo want to do it that way ?
 <dfaure> unix io ?
 <dfaure> like read, write, open ?
 <weis> dfaure: unix io: open/read/write/opendir ...
 <dfaure> that would be great IMHO
 <dfaure> I think he didn't realize that - the fact that moving the code to a central place involves switching to a lowlevel unix-like aPI for the slaves
 <weis> dfaure: If I have  a nested URL: Are we going to start two processes to get the URL from the net or one (with Coolos approach)
 <weis> dfaure: Currently it is two processes. One for file and one for tar, for example.
 <dfaure> weis: we're not sure. would one be ok ? (like opening the two libs and connecting signals and slots..)
 --
 <dfaure> weis : > I think this KPartsMainWindow should inherit KTMainWindow directly
 <dfaure> weis: I thought the whole idea was NOT to inherit KTM
 <dfaure> so that one could use anything as a KTM child
 <weis> dfaure: But this KTMainWindowGUIBuilder is already KTMainWindow dependenat. So why not derive ?
 <dfaure> well we're back to the shell, then...
 <weis> dfaure: Of course. Excuse me!
 <dfaure> > Why should one want to access the parents containers?
 <dfaure> know the View and Edit menus in konqueror ?
 <dfaure> They are view dependant ...
 <dfaure> and dynamically added into the menu
 <dfaure> although ... we could use XML instead
 <dfaure> can't remember why we don't
 <weis> dfaure: Using XML seems to be the clean approach IMHO.
 <dfaure> yes ... damn can't remember the reason
 <dfaure> lazyness perhaps
 <dfaure> :-)
 <weis> dfaure: What about me hacking a KPartsMainWindow that resembles the old shell pattern. Since it is useful in many cases and easy to understand/use ?
 <dfaure> yes, I guess it's ok to have a KTM child. The difference with the old shell is that the gui building is separate from it, right ?
 <dfaure> in fact, do people already inherit KTM, usually ?
 <dfaure> hmm ... they would simply inherit KPartMainWindow instead.
 <weis> dfaure: Exactly.
 <dfaure> so .... what was the problem with the shell ?
 <weis> dfaure: The problem was ..... aehmmm .....
 <weis> .... there was some problem .....
 <dfaure> :-))))))
 <weis> dfaure: What about mergeXML? Can it move ? .... still thinking about shell ....
 --
 <weis> dfaure: I know again! It may happen that the shell uses a widget which in turn uses a component. So the shell does not now that KParts are involved at all!
 <weis> s/now/know/
 <dfaure> ah - and then the widget would NOT use KPartsMainWindow, right ?
 <weis> dfaure: Yep!
 <dfaure> ok
 --
 <weis> dfaure: Another problem are nested KPartManagers. Imagine Widget W1 has some Parts P1 ... Pn. Part Pn has in turn a widget W2 that uses Parts P1_2...Pm_2. Then W1 and W2 would feature a KPartManager ....
 <weis> dfaure: The general problem is: A widget may use parts internally but the one who uses the widget does (and should) not know that.
 <dfaure> yes - I guess we need to try that,
 <dfaure> I'm not sure what's needed for that to work
 <weis> dfaure: Currently I am almost shure it wont work.
 <weis> dfaure: We must ashure that there is only ONE GUIBuilder per main window. That is one thing to do.
 <dfaure> ah yes
 <weis> dfaure: If window W1 becomes active (focus) it may activate its KPartManager. If W2 becomes active its KPartManager may do something.
 <weis> dfaure: Ooooops, I think I am on the wrong track perhaps.....
 <weis> dfaure: I started dealing with kparts like I do with widgets. If a kpart is just a widget that you can load at runtime, then it wont do gui merging anyway. So may above example seems to be very theoretically, perhaps ....
 <dfaure> yes, if you have two KPartManager you have a problem anyway (if the parts have a GUI)
 <dfaure> you want only ONE part active at a time ... one gui .
 <dfaure> so you can't have one part active in each kpartmanager, unless the whole partmanager can be deactivated.
 <weis> dfaure: Correct.
 <weis> dfaure: BUTTTH: Imagine you embed a browser widget. Would you expect that it suddenly plays around in your MenuBar and ToolBars? No, or ? It should only do so if you ask for it.
 <dfaure> well I think _yes_ you would expect its actions to become available to the user, no ?
 <weis> dfaure: Imagine you write a report generator that shows database queries using the browser view. Would you as a programmer want to have menu entries like "OpenURL" and "History" in your report generator? I would not.
 <dfaure> hmmm ... then it's the HTML widget you're using, not the part...
 <dfaure> when kdevelop embeds kwrite, it wants the actions from kwrite...
 <dfaure> open file, save file, ...
 <weis> dfaure: Well,. why not load a HTML widget at runtime as a part ...
 <dfaure> sure, why not :-)
 <dfaure> I suppose the answer is, as always : configurable.
 <dfaure> as you said.
 <weis> dfaure: Yep!
 <weis> dfaure: But that luckily voids my above example. If W1 wants that parts of W2 change the GUI then it has to tell W2 about the GUIBuilder. If W1 does not want that, then it does not tell W2 and no GUI merging will be done.
 <dfaure> yup
 <weis> dfaure: This way we stay with one KPartManager and GUIBuilder and W1 is responsible of propagating it  to W2 :-) Problem solved :-)
 
 --------------------------
 
 David wondering about Status Bar
 --------------------------------
 Should the statusbar be a *bar like toolbar/menubar, handled by the XML GUI building
 (soon "KPartsMainWindow"), and shown/hidden depending on the
 active part, OR a global statusbar, always shown or hidden, and
 made available to the parts, through KPartManager or KPartsMainWindow ?
 
 Currently it's the first one, but since we removed access to the toplevel
 containers, ...
 Visually, I think I prefer the statusbar not to show/hide when the active
 part changes. But for consistency with toolbars perhaps it should ? Dunno.
 
 (Simon) IMHO the statusbar should behave like toolbars. A part may "have" (allocate) a statusbar
         or just leave out the <StatusBar/> tag. The question IMHO is: How can the part access the
         statusbar?
         Hmmmmmmmm, I think we should solve this by making use of the xmlgui concept:
         (example)
         <StatusBar>
           <Action name="progressaction"/>
           <Label><text>Blah</text></Label>
         <StatusBar/>
         I think that would solve the problem, and it's what we currently support/implemented.
         What do you think?
        (update) ahh, grmbl, it won't help much ;-) , as it makes KStatusBar::message() impossible..
         hmmmmmmm
         *thinking*
         I vote for keeping the currently implemented way (as described above) . Perhaps we should add
         sth. like KPartManager::statusBarMessage() ? (as that message concept of kstatusbar is really
         different to the container concept (which kstatusbar supports aswell...) .
 
 Torben brainstorming about Nested Parts
 ---------------------------------------
 
 (In the following text I mix the words "components" and "parts". In addition I assume that
  KPartManager and KPartHost become one class. )
 
 
 Imagine a very complex situation like this:
 
 KOfficeMainWindow (a kparts aware shell)
  |
  |- KWordView/Part (a koffice component)
     |
     |- KSpreadView/Part (a koffice component)
        |
        |- KReportGeneratorView/Part (a koffice component)
           |
           |- KHTMLBrowserView/Part (something like konqui, this is a kpart)
 
 Imagine all are added to one KPartManager.
 Now the user clicks on the report generator and gets the
 usual GUI merging.
 
 Now imagine the user pressed directly on the Browser that is used
 by the report generator just to display some HTML. We would get GUI
 merging so that the menus of the browser appear.
 But that is a mistake! How the report is made visible is an implementation
 detail of the report generator. And it is in turn an implementation detail of KWord
 that is allows KSpread to play around in the menu/toolbars if activated.
 
 What we learn from that is the following:
 Observation 1) Whether a part - that is the child of some other part - may do GUI merging or
                not is determined by the parent part.
 
 
 Another example: We use a widget Kalender which uses KSpread to display a table.
                  The KSpreadPart is turned into ReadOnly mode.
 
 KalenderMainWindow (this is NOT a parts enabled main window)
  |
  |-KalenderWidget (this is NOT a part)
    |
    |-KSpreadView (this is a part)
 
 Here KSpreadView is used like a usual widget. That means it does not get added to some KPartManager
 and sees no KGUIBilder or stuff like that. "KalenderMainWindow" constructs the GUI itself.
 
 Observation 2) It should be possible to use a part just like a usual widget. So it must work without
                a KGUIBuilder and without being added to some KPartManager.
 
 ** (David) : I'll try that now.
 
 Lets extend the example: KalenderWidget shows a very nice kalender. That means it puts images
 inside of KSpread by using KImage.
 
 KalenderMainWindow (this is NOT a parts enabled main window)
  |
  |-KalenderWidget (this is NOT a part)
    |
    |-KSpreadView (this is a part)
      |
      |- KImage (this is a part)
      |
      |- KImage (this is a part)
 
 Somehow KSpread must handle its children. It wants to know which one is active for example.
 Usually KSpread would use KPartManager but it did not get one from its shell/parent.
 
 Observation 3) If a KPart is not added to some KPartManager then it creates its own KPartManager where
                it insertes itself and its children (if there are any children).
 
 That has an impact on Observation 2 - since the KPart will create its own KPartManager, so we rewrite it like this:
 
 Observation 2b) It should be possible to use a part just like a usual widget. So it must work without a KGUIBuilder.
 
 This is no problem, since the Part never directly talks to the GUIBuilder anyway.
 
 
 Now imagine someone made a KOffice component out of KalenderWidget and embeds it in KWord:
 
 KOfficeMainWindow (a kparts aware shell)
  |
  |- KWordView/Part (a koffice component)
     |
     |-KalenderWidget (this is NOT a part)
       |
       |-KSpreadView (this is a part)
         |
         |- KImage (this is a part)
         |
         |- KImage (this is a part)
 
 Do we want GUI merging with KSpread now? No, since the use of KSpread in KalenderWidget is
 an implementation detail. In this case we get two KPartManagers. One belongs to the
 KofficeMainWindow and is connected to the GUI Builder while the other one belongs to
 KSpread and is NOT connected to some GUI builder. This will work magically if we obeye
 observation 2b + 3.
 
 Observation 4) There may be multiple KPartManagers in one toplevel window, but only one is
                associated with a GUIBuilder. That means the managers are not really nested. They
                dont know about each others.
 
 
 Lets take another look at our first example:
 
 KOfficeMainWindow (a kparts aware shell)
  |
  |- KWordView/Part (a koffice component)
     |
     |- KSpreadView/Part (a koffice component)
        |
        |- KReportGeneratorView/Part (a koffice component)
           |
           |- KHTMLBrowserView/Part (something like konqui, this is a kpart)
 
 The report generator does not want GUI merging of its HTML browser. But it wants to offer an action
 called "HTMLSettings" to allow choosing the default font of the HTML Widget. Obviously this action
 is offered by the HTMLBrowserView. So instead of reimplementing this action, the report generator
 may propagate actions of the html browser. Its KPart::action() method just calls the browsers
 action() function if queried for an action named "HTMLSettings".
 
 Observation 5) In addition to turning GUI building on or off for components one may do partial gui merging.
                That means actions of some child component are propagated by the parent component.
 
 Observation5 does not cause additional code in libkparts. It just shows a possible usage and the flexibility of the
 action concept.
 
 
 Something else comes to my mind: We can safely reintroduce the shell pattern. The KPartManager/KHostPart is
 split of the shell and that is a MUST.
 But it does not make sense to create a KTMainWindow and then a KTMainWindowGUIBuilder to manage menubar/toolbars/statusbar.
 Imagine an application that uses KTMainWindow. Either the application programmer knows that he wants to embed
 some components and that they should use GUI merging => He can use KPartsMainWindow from the start.
 Or the application programmer does not want that any component that it uses directly or indirectly merges in
 its GUI. In this case he uses KTMainWindow and does not expect someone to override this decision by installing
 a KTMainWindowGUIBuilder.
 
 Imagine someone is writing a time scheduler which uses a KalenderWidget Version 1.0:
 
 SchedulerMainWindow ( a KTMainWindow )
  |
  |- SchedulerCanvas
     |
     |- KalenderWidget (which uses NO parts currently).
 
 Here no GUI merging happens. Now someone improves KalenderWidget in Version 2.0 to use
 KSpread internally (once again: This is an implementation detail):
 
 SchedulerMainWindow ( a KTMainWindow )
  |
  |- SchedulerCanvas
     |
     |- KalenderWidget (which USES parts now).
         |
         |- KSpreadView/Part
 
 When clicking on KSpread: Do you want GUI merging now? No! The GUI of the scheduler should stay
 the same. Just the implementation of the KalenderWidget changed.
 
 Observation 6) The application programmer determines wether he wants GUI merging or not. That means it is his
                decision to choose KTMainWindow or a GUI merging enabled KTMainWindow. And that in turn means that we can merge
                KTMainWindow and KTMainWindowGUIBuilder in one class called KPartsMainWindow.
                KPartsMainWindow will feature its special implementation of KPartManager (with KPartHost already merged with KPartManager).
 
 If some component wants to offer all of its functionality even in the case that nobody allowed it to do
 GUI merging then the component can still put all of its actions in a QPopupMenu instead of the menubar.
 
 
 Conclusion:
 I think with this model we can have an object tree that mixes usual widgets and components in any order
 and we always get it right. But it is late and I may get things wrong :-)
 In addition my approach reduces the amount of classes and the complexity of the API (at least I hope so).
 
 Lets put the four most important things together:
 
 Point 1) The application developer decides wether his app (->toplevel window) features GUI merging or not.
 Point 2) A part decides wether it allows its child parts to do GUI merging.
 Point 3) If one part in the big object tree is not allowed to do GUI merging (that means it is not registered
          at the KPartMainWindows KPartManager, but on some additional KPartManager) then none of its direct or
          indirect child parts can ever do GUI merging.
 Point 4) Wether some custom widget uses parts internally or not is an implementation detail and not visible to
          the user of this custom widget.
 
 
 (David) : I obviously agree with all this. This is a very nice derivation of
 the few ideas we had on irc - making GUI merging configurable, at both ends in
 fact, plus all the issues associated with nesting.
 
 (Simon) /me too :-)
 
 (David) Torben : perhaps you could also comment on the KReadOnlyPart ==? KBrowserPart issue ?
 Look for "second thought" in this file. Trying to decide between
 each read-only part can be embedded in konqueror and only those who implement
 KBrowserPart can be embedded in konqueror... I realize in the first case even
 ReadWrite parts would be embeddable since they inherit readonly part... A minor
 issue compared to what's above though.
 
 (Torben) When I draw my university education out of the had (and my master thesis :-)) then
          I think your problem can not be solved by deriving from some class but by doing
          delegation.
          It works like this:
          We have KReadOnlyPart (short KROP) and KonqyViewerExtension (short KVE). KVE is just
          a child of KROP that you can query with the QObject::child method.
          Views which are konquy aware feature their own implementation of KVE and konquy is
          happy :-)
          If a KROP does not feature a KVE then Konqui installs a default KVE that just ignores
          offsets etc.
          I think the little difficulty is to implement the default KVE, but it should be possible.
          With this solution we get both: Konquy can embed all KROPs and some KROPs can be Konquy
          aware and we do not bloat the KROP interface.
 
 (Torben) About the fact that konqy can embed a KReadWritePart (short KRWP):
          This is IMHO not a konqy problem but a KRWP design bug. KRWP overloads
          KROP and changes the semantics (editing is possible). By default KRWP should
          go into ReadOnly mode. Only if one calls rwpart->setEditable( TRUE ) it should
          offer editing of the data. It may still happen that some KRWPs dont obeye the
          "editable" flag, but that is a bug inside of the KRWP.
 
 (Simon) I definitely agree with all this :-)
 
          KROP -- (this is what konqueror embeds)
            |
            (child qobj) KonqyViewExtension (konqy specific stuff)
                         |
                         (current browserview extension objects)
                         ...
 
         Can we go for this? :-)