TDE core libraries
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.


  1. 2) provide some way to save/restore the positions of the menu/toolbar(s)
  2. when changing the active part ( I remember Reggie asking for that :)
  3. (David) Sounds good. I might have a look at that next.
  4. Comment : the menubar is cleared, not destroyed, so it seems we don't have
  5. to do anything for it (it remains where it is). We still need to save
  6. the BarPosition of the toolbars, though (see comment in
  7. KTMainWindowGUIBuilder::createContainer).
  8. (David) : With Torben's idea of inheriting KTMW, the problem of accessing
  9. the BarPosition of the toolbars is solved. Nice :-)
  10. (David) Not sure we want to save whether the statusbar is shown/hidden.
  11. (Simon) Another thought: Perhaps we should store the geometry information of
  12. the containers of the KPartHost in the KPart itself?
  13. (something like KPart-Session Management ;-)
  14. (David) Sounds strange (the child taking care of its host's containers...)
  15. In SM, it's the host (the WM) that stores the position of its children (the
  16. windows) :-)
  17. One possible problem (I'm not sure) : are the toolbars shared between the host
  18. and the part, or are there only toolbars for one and toolbars for the others ?
  19. In the first case, there's a problem because the toolbar will remain when
  20. switching part, so shouldn't get moved back when switching back.
  21. In fact we only want to store the position of the toolbars that fully "belong"
  22. to the part, right (i.e. that only contain items from the part) ?
  23. In this case, yes, that could be saved in the part.
  24. --------------
  25. 4) Perhaps a part wants to know if it got activated, so we might want to
  26. re-introduce that PartActivateEvent from tdelibs/tdeparts.
  27. Question: Shall this event be sent when the GUI of the part is activated
  28. or shall it be sent when the part "really" got activated (via KPartManager)?
  29. (David) Any example of usage ?
  30. I think what it wants is "really" activated, no ?
  31. (Simon) Konqueror for example wants to know when it gets activated, in order to access the KPartHost
  32. and query for the container objects (*bars) .
  33. Hmmmmmm, that sounds like two possible events. A PartActivateEvent and a GUIActivateEvent...
  34. What do you think?
  35. (David) 1 - I don't see the difference between "the gui of the part gets activated" and "the part
  36. gets activated", in this simple model (no Document/View). The Part gets activated when you can see
  37. its items in the menus/toolbars, there is no "in between" IMO ?
  38. 2 - Remind me what konq does with the *bars when a part gets activated ?
  39. I couldn't find anything with a quick grep in the sources...
  40. I'm still looking for an example when it's useful :)
  41. (Simon) I think that's the whole idea of making KPartManager independent from
  42. the guibuilder. Perhaps some apps wants to embed stuff without showing
  43. the parts a full-fledged gui (remember the part-children thingy in the
  44. old OpenParts? ;-) ) . Konqueror is one example. However I think
  45. KOffice could benefit from this, too, for the inplace editing
  46. (where the part is active, in terms of the KOffice document/view model,
  47. but still has a different gui or even none at all) .
  48. (David) : I start to see :-)
  49. But what I don't see is how does KPart know whether it's activated
  50. simply or activated with its GUI... i.e. how does it know the way
  51. it is embedded (with or without GUI items). Hmmm..
  52. (Simon) Konqueror (2) : When a parts get activated (this is "detected" via
  53. KonqViewManager) , then in general the actions of the view get plugged
  54. into the menus and the main toolbar (which is acccessed via
  55. Shell::viewToolBar() (hmmm, I'm looking forward to the new KParts :-)
  56. (David) Ah yes we don't have that in "example" currently. Dynamic actions.
  57. So you would add an event (or signal) to KPart for that ? Sounds ok to me.
  58. (Simon) That means that the (old) KParts doesn't know anything about the
  59. embedding in Konqueror.
  60. (David) Didn't get that ?!? :-)
  61. --------------
  62. BrowserView inheriting KReadOnlyPart is the way to go, IMHO.
  63. The question if Konqueror itself should be a KPart is difficult.
  64. All the BrowserViews are embeddable already, so it's "questionable"
  65. if it makes sense to have the embeddable Konqueror shell (KonqMainView) .
  66. (David) indeed.
  67. OTOH that shell makes these views "interact", makes them switch. So if
  68. someone wants to embed a browse-all-stuff widget, then embedding Konqueror
  69. would probably be cool, as the mainview handles all the stuff like determining
  70. the correct mimetype, loading the view, receiving and sending openURL requests, etc.
  71. Something like a shoot-and-forget for embedding ;-) (embed-and-forget ;)
  72. Loading and saving in that case would mean save/load the view profile.
  73. (David) Hmmm... somebody wanting to embed a full konqy ? Component technology allows
  74. you to avoid duplicate code by embedding a component that does what you want. Like tdevelop
  75. embeds a kedit component. Which app would want to embed a huge component containing
  76. a file maneger + a web browser + a generic viewer + ... ? I think this is not a component,
  77. but an application. Views are components...
  78. (Simon) Yes, that is true.
  79. What about this: We don't make Konqueror's Mainview a KPart, but still
  80. use the XMLGUI and the pluginaction stuff. (because these two things
  81. are importan and very nice IMHO). (I don't want to miss the action
  82. stuff in Konqueror, neither you I guess :-)
  83. (David) Sure, actions rock. But KTMainWindowGUIBuilder exists for that exact
  84. reason, no? The mainview would be a KTMainWindow, so its GUI is described in
  85. XML and with actions.
  86. ------------
  87. (David) This lib offers :
  88. KReadOnlyPart for viewers
  89. KReadWritePart for editors
  90. KPart for a generic part (?)
  91. We could easily port BrowserView to inherit KReadOnlyPart, and call it
  92. KBrowserPart.
  93. Proposed changes :
  94. - The action stuff gets ported, of course (structs disappear)
  95. - started/completed/canceled already exist -> removed
  96. - setStatusBarText() -> see below, wondering about status bar
  97. - setLocationBarURL() -> removed - konqueror will set it from url()
  98. [ is that correct ? ]
  99. (Simon) I think we still need it. When a view gets a redirection signal, then
  100. it wants to change the displayed URL.
  101. (David) Ah right (I think support for redirection is missing from konqueror on
  102. the whole, at other places).
  103. - openURLRequest and createNewWindow remain.
  104. (Simon) <sidenote> We will want to add a serviceType argument to openURLRequest.
  105. At least we need it to get rid of these changeViewMode() hacks in
  106. konq_htmlview/konq_iconview :P
  107. (David) ok
  108. - popupMenu remains ?
  109. (Simon) What about putting that popupMenu into an extension interface,
  110. contained in libkonq? IMHO the popupMenu is very libkonq specific.
  111. (David) Depends how we want to handle the popupmenu in KonqHTMLView, for
  112. instance.
  113. At the moment it's missing, and it will be a problem when that view is moved to
  114. tdelibs : no more libkonq for it. But anyway I agree : the part should
  115. generally take care of its own menu (I'm thinking of KNotePadPart for instance)
  116. Perhaps this would remain in KBrowserPart though (we need it in konqueror).
  117. ----
  118. On second thought : why should we make KReadOnlyPart different from
  119. KBrowserPart ?
  120. Any "viewer" should be embeddable in konqueror. The additional signals we
  121. currently have in BrowserView could be simply added to KReadOnlyPart, and
  122. it doesn't make it more complex (kedit can simply not care about the loading
  123. progress, the popupMenu signal, ...)
  124. In fact the loading progress should even be emitted by KReadOnlyPart
  125. itself (it handles the kiojob), for the simple cases. Of course
  126. konqueror views will reimplement openURL and send the signals themselves.
  127. The main problem I see is that BrowserView is asynchronous
  128. and KReadOnlyPart is .. a bit of both (asynchronous for remote URLs,
  129. synchronous in openFile()). But for konqy, openFile() means nothing
  130. and never gets called (because openURL is reimplemented).
  131. For the history stuff, we can provide the default implementation
  132. in KReadOnlyPart (just like we did in BrowserView).
  133. About the "offset stuff" - well it even makes sense in kedit
  134. so the host can ask for going to a particular line when opening the
  135. file (hyper cool !). Anyway, for parts which have nothing to do with
  136. offsets, this gets simply ignored.
  137. In short, we can take advantage of the fact that we have a lib now,
  138. as opposed to an interface alone (BrowserView), and provide default
  139. implementations (when possible, for example the history stuff)
  140. which make every "viewer"-type part a part useable in konqueror
  141. - but also in koffice, and whereever.
  142. This would reduce the number of "type of parts" and make it simpler
  143. to embed anything into anything. OTOH, it makes KReadOnlyPart a bit more
  144. difficult to understand.
  145. What do you think ? Did I overlook something ?
  146. (Simon) I don't think there's a problem with the async stuff
  147. (BrowserView/KReadOnlyPart) . Mosfet's KGhostView browserview or
  148. his dviview are both 100% like KReadOnlyPart (yes, they launch TDEIOJob::copy()
  149. and copy the file to some local temp) . It works :-) and noone complains :-))
  150. -> I see no problem with that :-)
  151. (David) Sure - but does that answer the question : KReadOnlyPart==KBrowserPart ?
  152. Now that I think of it, it's probably not a good idea - there are many
  153. things that BrowserPart has in addition, finally. I'm still not sure. I
  154. like making it simple, but this might be an over-simplification.
  155. ------------
  156. (Simon) About KXMLGUIBuilder<->non-KTMW builder: One possible case coming to my mind are dialogs. If you want to
  157. embed a small "part-applet" ;) (perhaps as embedded preview part for some open-foo-dialog?) , then a non-KTMW
  158. builder might be useful (and might have containers) .
  159. I don't see any problem in having a separate (abstract) interface for the GUI builder. We gain flexibility
  160. IMHO, and taking into account that this KParts stuff should probably be something highly finalized for
  161. KDE 2.0, its worth having as much flexibility as possible (while keeping it easy to use by providing the
  162. easy-to-use KTMW implementation) , IMHO.
  163. (David) Excellent idea !! A part in a dialog :-) Don't think you can have that in Windows :-))
  164. But .. how can you have containers (menubars, toolbars, ...) in a dialog ? Or were you thinking of
  165. another kind of container ?
  166. (Simon) Containers in a dialog? See kfd :-))
  167. (altho kfd uses ktmw AFAIK ;)
  168. (David) ... because there is no support for toolbars in a dialog.
  169. I still think you can't have containers in a QDialog :-)
  170. (Simon) Another possible thing is perhaps kpropsdlg. IMHO it'd be cool if
  171. it would be very easy and simple to add new props pages for certain
  172. mimetypes dynamically via shlibs.
  173. (David) Sounds good but not very useful. :-)
  174. ---------------
  175. (Torben) I did not follow the latest discussions due to a lack of time. However, I made some
  176. small remarks on stuff I did not understand (yet?).
  177. (Torben) KReadWritePart and KReadOnlyPart use the three signals canceled, started, completed in
  178. two different contexts. One can not see wether a KReadWritePart started loading or
  179. started saving. I would like to introduce
  180. a) three new signals for KReadWritePart
  181. b) A parameter to the signals telling wether this is a read or write operation.
  182. Basically I am in favor for a small API -> b)
  183. And b) is source compatible to the current solution!
  184. (David) ok
  185. (Torben) In example.cpp addPart is called twice and each time the active part is changed. Would not it be
  186. more clever to add parts and activate one later instead of activating the last one inserted ?
  187. (David) no no, example.cpp doesn't even know when the active part changes.
  188. Did you try running the example ? It features a part that is dynamically
  189. embedded and de-embedded, the notepadpart. That's why there is an addPart()
  190. call - to add the new part when the user asks for it. Not when the active part
  191. changes.
  192. (Torben) You guys are busting QDOM. You can NOT assign an element of document A to an element of document B.
  193. That means: There is no way to mix two documents. What you are doing is asking for trouble.
  194. The ownerDocument() function will not work as one might expect after the assignment: The element
  195. of B assigned to A will still claim to be a child of B :-(
  196. And there are few chances that this may change in the Qt implementation in the next few weeks.
  197. (to myself) I tro to fix that in QDom ....
  198. <weis> Hi
  199. <dfaure> Hi !
  200. <weis> dfaure: Just looked into new tdeparts
  201. <dfaure> ah ?
  202. <weis> dfaure: You have a major problem: One can NOT mix QDomElements of different documents!
  203. <dfaure> weis: why ?
  204. <weis> dfaure: Because the ownerDocument wont change as one might expect.
  205. <dfaure> weis: not sure I have the full picture (Simon did that part). What should we do instead ?
  206. <weis> dfaure: Either I manage to hack QDom (very hard) or ..... dont know currently ....
  207. <dfaure> the problem is .. memory management, right ?
  208. <weis> dfaure: I just checked in my CVS irc stuff :-)
  209. <dfaure> ok :-)
  210. <weis> dfaure: Can you have a look at tdeparts/COMMENTS ?
  211. --
  212. <dfaure> weis: you should have come before. coolo is talking about re-writing libtdeio.
  213. <dfaure> well in fact he started the rewrite
  214. dfaure having a look
  215. <weis> dfaure: Unfortunately I am not paid for KDE but for Qt hacking :-( So I fear I have no time for tdeio anyway.
  216. <dfaure> weis: I know that, but perhaps a little discussion would help him with the new design :)
  217. <weis> dfaure: So you are not convinced by his design ?
  218. <weis> dfaure: It is about this daemon that forks and loads ioslaves as libs, or ?
  219. <dfaure> yes, this looks fine
  220. <dfaure> but then what about filters, and especially the problem is the API
  221. <dfaure> each slave currently implements stuff like recurse copying
  222. <dfaure> and we would perfer that in a single location, obviously :-)
  223. <weis> dfaure: Thta is true!
  224. <weis> dfaure: The new design would mean: We write an abstract interface for basic IO stuff.
  225. <dfaure> yup
  226. <weis> dfaure: Basically every slave would have to implement usual UNIX IO functions.
  227. <weis> dfaure: Does coolo want to do it that way ?
  228. <dfaure> unix io ?
  229. <dfaure> like read, write, open ?
  230. <weis> dfaure: unix io: open/read/write/opendir ...
  231. <dfaure> that would be great IMHO
  232. <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
  233. <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)
  234. <weis> dfaure: Currently it is two processes. One for file and one for tar, for example.
  235. <dfaure> weis: we're not sure. would one be ok ? (like opening the two libs and connecting signals and slots..)
  236. --
  237. <dfaure> weis : > I think this KPartsMainWindow should inherit KTMainWindow directly
  238. <dfaure> weis: I thought the whole idea was NOT to inherit KTM
  239. <dfaure> so that one could use anything as a KTM child
  240. <weis> dfaure: But this KTMainWindowGUIBuilder is already KTMainWindow dependenat. So why not derive ?
  241. <dfaure> well we're back to the shell, then...
  242. <weis> dfaure: Of course. Excuse me!
  243. <dfaure> > Why should one want to access the parents containers?
  244. <dfaure> know the View and Edit menus in konqueror ?
  245. <dfaure> They are view dependant ...
  246. <dfaure> and dynamically added into the menu
  247. <dfaure> although ... we could use XML instead
  248. <dfaure> can't remember why we don't
  249. <weis> dfaure: Using XML seems to be the clean approach IMHO.
  250. <dfaure> yes ... damn can't remember the reason
  251. <dfaure> lazyness perhaps
  252. <dfaure> :-)
  253. <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 ?
  254. <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 ?
  255. <dfaure> in fact, do people already inherit KTM, usually ?
  256. <dfaure> hmm ... they would simply inherit KPartMainWindow instead.
  257. <weis> dfaure: Exactly.
  258. <dfaure> so .... what was the problem with the shell ?
  259. <weis> dfaure: The problem was ..... aehmmm .....
  260. <weis> .... there was some problem .....
  261. <dfaure> :-))))))
  262. <weis> dfaure: What about mergeXML? Can it move ? .... still thinking about shell ....
  263. --
  264. <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!
  265. <weis> s/now/know/
  266. <dfaure> ah - and then the widget would NOT use KPartsMainWindow, right ?
  267. <weis> dfaure: Yep!
  268. <dfaure> ok
  269. --
  270. <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 ....
  271. <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.
  272. <dfaure> yes - I guess we need to try that,
  273. <dfaure> I'm not sure what's needed for that to work
  274. <weis> dfaure: Currently I am almost shure it wont work.
  275. <weis> dfaure: We must ashure that there is only ONE GUIBuilder per main window. That is one thing to do.
  276. <dfaure> ah yes
  277. <weis> dfaure: If window W1 becomes active (focus) it may activate its KPartManager. If W2 becomes active its KPartManager may do something.
  278. <weis> dfaure: Ooooops, I think I am on the wrong track perhaps.....
  279. <weis> dfaure: I started dealing with tdeparts 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 ....
  280. <dfaure> yes, if you have two KPartManager you have a problem anyway (if the parts have a GUI)
  281. <dfaure> you want only ONE part active at a time ... one gui .
  282. <dfaure> so you can't have one part active in each kpartmanager, unless the whole partmanager can be deactivated.
  283. <weis> dfaure: Correct.
  284. <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.
  285. <dfaure> well I think _yes_ you would expect its actions to become available to the user, no ?
  286. <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.
  287. <dfaure> hmmm ... then it's the HTML widget you're using, not the part...
  288. <dfaure> when tdevelop embeds kwrite, it wants the actions from kwrite...
  289. <dfaure> open file, save file, ...
  290. <weis> dfaure: Well,. why not load a HTML widget at runtime as a part ...
  291. <dfaure> sure, why not :-)
  292. <dfaure> I suppose the answer is, as always : configurable.
  293. <dfaure> as you said.
  294. <weis> dfaure: Yep!
  295. <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.
  296. <dfaure> yup
  297. <weis> dfaure: This way we stay with one KPartManager and GUIBuilder and W1 is responsible of propagating it to W2 :-) Problem solved :-)
  298. --------------------------
  299. David wondering about Status Bar
  300. --------------------------------
  301. Should the statusbar be a *bar like toolbar/menubar, handled by the XML GUI building
  302. (soon "KPartsMainWindow"), and shown/hidden depending on the
  303. active part, OR a global statusbar, always shown or hidden, and
  304. made available to the parts, through KPartManager or KPartsMainWindow ?
  305. Currently it's the first one, but since we removed access to the toplevel
  306. containers, ...
  307. Visually, I think I prefer the statusbar not to show/hide when the active
  308. part changes. But for consistency with toolbars perhaps it should ? Dunno.
  309. (Simon) IMHO the statusbar should behave like toolbars. A part may "have" (allocate) a statusbar
  310. or just leave out the <StatusBar/> tag. The question IMHO is: How can the part access the
  311. statusbar?
  312. Hmmmmmmmm, I think we should solve this by making use of the xmlgui concept:
  313. (example)
  314. <StatusBar>
  315. <Action name="progressaction"/>
  316. <Label><text>Blah</text></Label>
  317. <StatusBar/>
  318. I think that would solve the problem, and it's what we currently support/implemented.
  319. What do you think?
  320. (update) ahh, grmbl, it won't help much ;-) , as it makes KStatusBar::message() impossible..
  321. hmmmmmmm
  322. *thinking*
  323. I vote for keeping the currently implemented way (as described above) . Perhaps we should add
  324. sth. like KPartManager::statusBarMessage() ? (as that message concept of kstatusbar is really
  325. different to the container concept (which kstatusbar supports aswell...) .
  326. Torben brainstorming about Nested Parts
  327. ---------------------------------------
  328. (In the following text I mix the words "components" and "parts". In addition I assume that
  329. KPartManager and KPartHost become one class. )
  330. Imagine a very complex situation like this:
  331. KOfficeMainWindow (a tdeparts aware shell)
  332. |
  333. |- KWordView/Part (a koffice component)
  334. |
  335. |- KSpreadView/Part (a koffice component)
  336. |
  337. |- KReportGeneratorView/Part (a koffice component)
  338. |
  339. |- TDEHTMLBrowserView/Part (something like konqui, this is a kpart)
  340. Imagine all are added to one KPartManager.
  341. Now the user clicks on the report generator and gets the
  342. usual GUI merging.
  343. Now imagine the user pressed directly on the Browser that is used
  344. by the report generator just to display some HTML. We would get GUI
  345. merging so that the menus of the browser appear.
  346. But that is a mistake! How the report is made visible is an implementation
  347. detail of the report generator. And it is in turn an implementation detail of KWord
  348. that is allows KSpread to play around in the menu/toolbars if activated.
  349. What we learn from that is the following:
  350. Observation 1) Whether a part - that is the child of some other part - may do GUI merging or
  351. not is determined by the parent part.
  352. Another example: We use a widget Kalender which uses KSpread to display a table.
  353. The KSpreadPart is turned into ReadOnly mode.
  354. KalenderMainWindow (this is NOT a parts enabled main window)
  355. |
  356. |-KalenderWidget (this is NOT a part)
  357. |
  358. |-KSpreadView (this is a part)
  359. Here KSpreadView is used like a usual widget. That means it does not get added to some KPartManager
  360. and sees no KGUIBilder or stuff like that. "KalenderMainWindow" constructs the GUI itself.
  361. Observation 2) It should be possible to use a part just like a usual widget. So it must work without
  362. a KGUIBuilder and without being added to some KPartManager.
  363. ** (David) : I'll try that now.
  364. Lets extend the example: KalenderWidget shows a very nice kalender. That means it puts images
  365. inside of KSpread by using KImage.
  366. KalenderMainWindow (this is NOT a parts enabled main window)
  367. |
  368. |-KalenderWidget (this is NOT a part)
  369. |
  370. |-KSpreadView (this is a part)
  371. |
  372. |- KImage (this is a part)
  373. |
  374. |- KImage (this is a part)
  375. Somehow KSpread must handle its children. It wants to know which one is active for example.
  376. Usually KSpread would use KPartManager but it did not get one from its shell/parent.
  377. Observation 3) If a KPart is not added to some KPartManager then it creates its own KPartManager where
  378. it insertes itself and its children (if there are any children).
  379. That has an impact on Observation 2 - since the KPart will create its own KPartManager, so we rewrite it like this:
  380. Observation 2b) It should be possible to use a part just like a usual widget. So it must work without a KGUIBuilder.
  381. This is no problem, since the Part never directly talks to the GUIBuilder anyway.
  382. Now imagine someone made a KOffice component out of KalenderWidget and embeds it in KWord:
  383. KOfficeMainWindow (a tdeparts aware shell)
  384. |
  385. |- KWordView/Part (a koffice component)
  386. |
  387. |-KalenderWidget (this is NOT a part)
  388. |
  389. |-KSpreadView (this is a part)
  390. |
  391. |- KImage (this is a part)
  392. |
  393. |- KImage (this is a part)
  394. Do we want GUI merging with KSpread now? No, since the use of KSpread in KalenderWidget is
  395. an implementation detail. In this case we get two KPartManagers. One belongs to the
  396. KofficeMainWindow and is connected to the GUI Builder while the other one belongs to
  397. KSpread and is NOT connected to some GUI builder. This will work magically if we obeye
  398. observation 2b + 3.
  399. Observation 4) There may be multiple KPartManagers in one toplevel window, but only one is
  400. associated with a GUIBuilder. That means the managers are not really nested. They
  401. dont know about each others.
  402. Lets take another look at our first example:
  403. KOfficeMainWindow (a tdeparts aware shell)
  404. |
  405. |- KWordView/Part (a koffice component)
  406. |
  407. |- KSpreadView/Part (a koffice component)
  408. |
  409. |- KReportGeneratorView/Part (a koffice component)
  410. |
  411. |- TDEHTMLBrowserView/Part (something like konqui, this is a kpart)
  412. The report generator does not want GUI merging of its HTML browser. But it wants to offer an action
  413. called "HTMLSettings" to allow choosing the default font of the HTML Widget. Obviously this action
  414. is offered by the HTMLBrowserView. So instead of reimplementing this action, the report generator
  415. may propagate actions of the html browser. Its KPart::action() method just calls the browsers
  416. action() function if queried for an action named "HTMLSettings".
  417. Observation 5) In addition to turning GUI building on or off for components one may do partial gui merging.
  418. That means actions of some child component are propagated by the parent component.
  419. Observation5 does not cause additional code in libtdeparts. It just shows a possible usage and the flexibility of the
  420. action concept.
  421. Something else comes to my mind: We can safely reintroduce the shell pattern. The KPartManager/KHostPart is
  422. split of the shell and that is a MUST.
  423. But it does not make sense to create a KTMainWindow and then a KTMainWindowGUIBuilder to manage menubar/toolbars/statusbar.
  424. Imagine an application that uses KTMainWindow. Either the application programmer knows that he wants to embed
  425. some components and that they should use GUI merging => He can use KPartsMainWindow from the start.
  426. Or the application programmer does not want that any component that it uses directly or indirectly merges in
  427. its GUI. In this case he uses KTMainWindow and does not expect someone to override this decision by installing
  428. a KTMainWindowGUIBuilder.
  429. Imagine someone is writing a time scheduler which uses a KalenderWidget Version 1.0:
  430. SchedulerMainWindow ( a KTMainWindow )
  431. |
  432. |- SchedulerCanvas
  433. |
  434. |- KalenderWidget (which uses NO parts currently).
  435. Here no GUI merging happens. Now someone improves KalenderWidget in Version 2.0 to use
  436. KSpread internally (once again: This is an implementation detail):
  437. SchedulerMainWindow ( a KTMainWindow )
  438. |
  439. |- SchedulerCanvas
  440. |
  441. |- KalenderWidget (which USES parts now).
  442. |
  443. |- KSpreadView/Part
  444. When clicking on KSpread: Do you want GUI merging now? No! The GUI of the scheduler should stay
  445. the same. Just the implementation of the KalenderWidget changed.
  446. Observation 6) The application programmer determines wether he wants GUI merging or not. That means it is his
  447. decision to choose KTMainWindow or a GUI merging enabled KTMainWindow. And that in turn means that we can merge
  448. KTMainWindow and KTMainWindowGUIBuilder in one class called KPartsMainWindow.
  449. KPartsMainWindow will feature its special implementation of KPartManager (with KPartHost already merged with KPartManager).
  450. If some component wants to offer all of its functionality even in the case that nobody allowed it to do
  451. GUI merging then the component can still put all of its actions in a QPopupMenu instead of the menubar.
  452. Conclusion:
  453. I think with this model we can have an object tree that mixes usual widgets and components in any order
  454. and we always get it right. But it is late and I may get things wrong :-)
  455. In addition my approach reduces the amount of classes and the complexity of the API (at least I hope so).
  456. Lets put the four most important things together:
  457. Point 1) The application developer decides wether his app (->toplevel window) features GUI merging or not.
  458. Point 2) A part decides wether it allows its child parts to do GUI merging.
  459. Point 3) If one part in the big object tree is not allowed to do GUI merging (that means it is not registered
  460. at the KPartMainWindows KPartManager, but on some additional KPartManager) then none of its direct or
  461. indirect child parts can ever do GUI merging.
  462. Point 4) Wether some custom widget uses parts internally or not is an implementation detail and not visible to
  463. the user of this custom widget.
  464. (David) : I obviously agree with all this. This is a very nice derivation of
  465. the few ideas we had on irc - making GUI merging configurable, at both ends in
  466. fact, plus all the issues associated with nesting.
  467. (Simon) /me too :-)
  468. (David) Torben : perhaps you could also comment on the KReadOnlyPart ==? KBrowserPart issue ?
  469. Look for "second thought" in this file. Trying to decide between
  470. each read-only part can be embedded in konqueror and only those who implement
  471. KBrowserPart can be embedded in konqueror... I realize in the first case even
  472. ReadWrite parts would be embeddable since they inherit readonly part... A minor
  473. issue compared to what's above though.
  474. (Torben) When I draw my university education out of the had (and my master thesis :-)) then
  475. I think your problem can not be solved by deriving from some class but by doing
  476. delegation.
  477. It works like this:
  478. We have KReadOnlyPart (short KROP) and KonqyViewerExtension (short KVE). KVE is just
  479. a child of KROP that you can query with the QObject::child method.
  480. Views which are konquy aware feature their own implementation of KVE and konquy is
  481. happy :-)
  482. If a KROP does not feature a KVE then Konqui installs a default KVE that just ignores
  483. offsets etc.
  484. I think the little difficulty is to implement the default KVE, but it should be possible.
  485. With this solution we get both: Konquy can embed all KROPs and some KROPs can be Konquy
  486. aware and we do not bloat the KROP interface.
  487. (Torben) About the fact that konqy can embed a KReadWritePart (short KRWP):
  488. This is IMHO not a konqy problem but a KRWP design bug. KRWP overloads
  489. KROP and changes the semantics (editing is possible). By default KRWP should
  490. go into ReadOnly mode. Only if one calls rwpart->setEditable( TRUE ) it should
  491. offer editing of the data. It may still happen that some KRWPs dont obeye the
  492. "editable" flag, but that is a bug inside of the KRWP.
  493. (Simon) I definitely agree with all this :-)
  494. KROP -- (this is what konqueror embeds)
  495. |
  496. (child qobj) KonqyViewExtension (konqy specific stuff)
  497. |
  498. (current browserview extension objects)
  499. ...
  500. Can we go for this? :-)