TDE personal information management applications
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.

Thoughts 17KB

  1. * Note: Lines starting with a d are my comments - Daniel
  2. * Note: Lines starting with a # are my comments - Cornelius
  3. * Note: Lines starting with a "z" are my comments - Zack :)
  4. * Note: Lines starting with a "s" are my comments - Simon
  5. * Note: Lines starting with a "Don:" are my comments - Don
  6. * Note: Lines starting with a "g" are my comments - Guenter
  7. * Note: Lines starting with a "m" are my comments - Matthias Kretz
  8. * Note: Lines starting with a "MiB:" are my comments - Michael
  9. * Note: Lines starting with a "h" are my comments - Holger
  10. Misc:
  11. =====
  12. Configuration Merge
  13. -------------------
  14. d Idea: The KOffice way of life: Offer a method that adds a given wiget of a
  15. d predefined type as page in a KDialogBase or offer a pointer to a KDialogBase
  16. d -> requires a Kontact part or an external lib per part
  17. m I believe this is a more general problem. Please take a look at
  18. m tdegraphics/kview/kpreferences{dialog,module}.{h,cpp}. I'd like to generalize
  19. m these classes and include them into tdelibs (the same configuration merge is
  20. m being done in Kate, Noatun, Kopete, KView and probably more).
  21. # The problem is even more generic. We also have to merge about boxes, tips of
  22. # the day and maybe more.
  23. Merged Foldertree View
  24. ----------------------
  25. d Idea: Let the part send a description of their folders and reaction to calls
  26. d as XML, similar to XMLGUI
  27. # Is a folder tree really the right tool to represent events, todos or
  28. # contacts?
  29. MiB: On the one hand, Notes can be hierarchic, so a folder tree would be the
  30. MiB: nearest solution...
  31. z I think so. Applications could send the root of their tree to
  32. z Kontact so that the interface looks like
  33. - Mail
  34. | \
  35. | - Local Folders
  36. | \
  37. | Inbox
  38. | |
  39. | Thrash
  40. | |
  41. | Sent
  42. - Notes
  43. | \
  44. | Notes 1
  45. | |
  46. | Notes 2
  47. |
  48. - Events
  49. \
  50. Event 1
  51. |
  52. Event 2
  53. z which is not that bad. The question would be how to render the tree
  54. z on the Kontact side while keeping the items on the parts side ( because
  55. z e.g. KMails hold custom pixmaps for the folders which had to be
  56. z displayed in the Kontact tree).
  57. g I'm currently having 248 events. A tree is a very bad solution to visualize
  58. g them. selecting "Events" in the tree should just only start the korganizer
  59. g part.
  60. MiB: ...OTOH... yes, /me agrees with g, a folder tree becomes complex quite fast.
  61. Don: The folder tree makes sense for advanced users, but I think
  62. Don: the simplicity of the current navigator widget has advantages for
  63. Don: non power users.
  64. Don:
  65. Don: Actually instead of the navigator widget I think it makes sense
  66. Don: to consider reusing the widget choosing widget in the latest
  67. Don: version of the Qt designer, which in a sense can be
  68. Don: considered a generalization of the navigator widget. And could
  69. Don: make the folder tree in kmail unnecessary.
  70. Don:
  71. Don: I might investigate the Qt designer widget further but if someone
  72. Don: else wants to look at a folder tree widget that's cool with me.
  73. # I had a look at the Qt designer widget choosing widget. I think it has a
  74. # severe usability problem, because the buttons (or kind of tabs) which are used
  75. # to access the widget subgroups are not always at the same place but move
  76. # around when you click on them. Dependening on which group is shown, the button
  77. # is at the top or at the bottom of the widget. In my opinion this solution is
  78. # unacceptable.
  79. # But Daniel had a good idea how to improve that. It looks similar to the Qt
  80. # designer widget, but it opens the current group always at the top of the
  81. # widget and only highlights the current group in the list at the bottom, but
  82. # doesn't move it. This seems to also be the way Outlook does it.
  83. Don: Guenter, agree.
  84. Don: Wouldn't the idea to be to show calendars in the tree or
  85. Don: navigator widget, rather than individual events?
  86. # Yes, that makes sense. Calendars are much more similar to mail folders than
  87. # single events. You wouldn't integrate individual mails in the folder tree,
  88. # would you?
  89. d That raises an interesting point: The KNotes plugin would not need an own
  90. d canvas in the WidgetStack then. It's sufficient to have the notes in the
  91. d folder view, an RMB menu on them and a "New Note" action.
  92. d So the new design must be able to catch that case (the current one does not).
  93. # I think notes are on the same level as mails or events. They should be listed
  94. # in the view. KNotes would probably just create a single entry in the folder
  95. # tree.
  96. KNotes integration
  97. ------------------
  98. MiB: Which reminds me of my own concern about the 'how' of integrating KNotes:
  99. MiB: * the current solution is to start KNotes extern, it is not embedded in Kontact
  100. MiB: at all. Thus opening a note that is on another desktop either leaves the Kontact
  101. MiB: window or moves the note. Either not perfect. Also, Kontact is likely to cover
  102. MiB: notes that reside on the desktop, easy working is impossible. Which is the reason
  103. MiB: I don't like the current approach too much.
  104. MiB: * but there's always hope---my idea would be to show the notes in Kontact itself.
  105. MiB: Now I tend to say it's a bit intrusive to not allow starting KNotes and
  106. MiB: Kontact/KNotes at the same time which raises the following issues:
  107. MiB: - if KNotes and Kontact are running at the same time, changes to the notes have
  108. MiB: to be synchronized (not much of a problem). Changes to be synced are the
  109. MiB: text/contents itself, the text color/style..., the note color. Not sure about
  110. MiB: the note size. Not to be synced is the position.
  111. MiB: - so the position in Kontact has to be saved individually and independently
  112. MiB: of the real desktop position (realized by attaching two display config
  113. MiB: files, works in make_it_cool branch mostly). Kontact's size is generally
  114. MiB: smaller than the desktop.
  115. MiB: - normally notes are on a specific desktop, now they have to be displayed on one
  116. MiB: area---how to do this best?
  117. MiB: what does M$ do? How do they manage the notes in their PIM app? (I don't know
  118. MiB: it, never seen that thing)
  119. Toolbar Items
  120. -------------
  121. d The KParts Technology only provides actions for the current part. It might be
  122. d desireable to have common actions that are always available.
  123. Don: I agree that it is desireable to have common actions always
  124. Don: available (and parts too like the todo list)
  125. Don:
  126. Don: But are you sure Kparts is limited in this way? KOrganizer can load
  127. Don: multiple plugins simultaneously. And all of these plugins are tdeparts
  128. Don: (eg. birthday import), and tdeactions for all loaded plugins are
  129. Don: created and made available simultaneously.
  130. Don:
  131. Don: Yeah, I'm quite positive you can load multiple parts simultaneously.
  132. # Certainly. Actions like "New Mail", "New Contact", "New Event" should be
  133. # available independently of a selected part.
  134. Don: This is a very important issue, I think we need a library with three
  135. Don: methods:
  136. Don: KAddressBookIface loadKAddressBook()
  137. Don: KMailIface loadKMail()
  138. Don: KOrganizerIface loadKOrganizer()
  139. MiB: And don't forget KNotesIface loadKNotes() :-)
  140. h: That doesn't sound extendable ;)
  141. h: So if I would like to add a 'New ShortMessage' part we would have to extend
  142. h: that library... better use TDETrader and some sort of a common framework
  143. h: and Mib's comments shows that problem!
  144. d: That's what KDCOPServiceStarter is for :)
  145. Don: Now if kontact is running then loadX will load the X part in kontact
  146. Don: (if it is not already loaded) and return a dcop iface for that
  147. Don: part.
  148. Don:
  149. Don: If kontact is not running but is the users preferred application
  150. Don: then loadX will start kontact and then do the above.
  151. Don:
  152. Don: If kontact is not running and is not the users preferred application
  153. Don: then a standalone version of X should be started, and an iface for
  154. Don: that standalone app returned.
  155. Don:
  156. Don: I think this library should be in libtdepim ad all the tdepim apps
  157. Don: should be moved into tdepim, so their iface files all be in one
  158. Don: package. Or alternatively a new kdeinterfaces package be created
  159. Don: and used as a general repository for interface files.
  160. Don:
  161. Don: Another important issue is invokeMailer and the fact that currently
  162. Don: KDE just runs kmail with command line arguments by default. That has
  163. Don: to be made smarter.
  164. Don:
  165. Don: I guess when kmail is run with command line arguments it could
  166. Don: actually use loadKMail() and then use the resulting iface.
  167. Don:
  168. Don: And the same for all other loadX apps.
  169. Status Bar
  170. ----------
  171. d We need a more sophisticated handling (progressbar, etc)
  172. Don: Definitely.
  173. # We now have tdelibs/tdeparts/statusbarextension. This is intended to solve these
  174. # problems, right?
  175. d: Right. Simply add it as childobject in your part and use it's API. Works even
  176. d: for other KPart hosts than Kontact
  177. Kontact plugin unification
  178. -------------------------
  179. # Currently all Kontact plugins look quite similar. It would be nice, if we
  180. # could provide infratructure to reduce duplicated code as far as possible.
  181. d I thouht of a KontactPart, similar to a KOPart, if that makes sense. I don't think
  182. d a normal KPart is sufficient for us.
  183. Don: I've spent quite a bit of time in all pim *_part files and IIRC
  184. Don: the amount of duplicated code, is pretty much negligible.
  185. Don:
  186. Don: But a KontactPart could make sense for when the parts want to communicate with
  187. Don: the container. Eg. if the parts want to add folders to the container
  188. Don: apps folder tree (or navigator)
  189. Don:
  190. Don: And maybe for communicating with the status bar.
  191. Communication/Interaction:
  192. ==========================
  193. d Invoking parts when they are needed for the first time takes too long,
  194. d starting all takes too long on startup
  195. d Idea: Mark complex parts as basic parts that get loaded anyway
  196. # parts could be loaded in the background based on usage patterns. Kontact could
  197. # remember which parts were used at the last session and load them in the
  198. # background after loading the initial part to be shown at startup.
  199. z This idea seems to be similar to Microsoft's
  200. z hide-unused-item-in-the-menu strategy. But it probably mess up
  201. z kaddressbook integration. Although not used during every session
  202. z this part is needed and should be always loaded. This strategy
  203. z would be great for could-to-come parts, like a summary part.
  204. z Background loading of parts is OK. The idea is simple : load the
  205. z last used part on startup. Make sure its loading finishes and then
  206. z load the rest once the user can already interact with the last used
  207. z loaded part.
  208. g why do we always need the addressbook? Is libtdeabc not sufficient?
  209. Don: I guess my machine is too fast, starting parts is pretty quick here :-)
  210. d DCOP is too slow, internal communication should be handled via a dedicated
  211. d interface, communication with external applications (i.e. knotes) should be
  212. d done via wrapper parts that communicate with their respective IPC method to
  213. d their application using the native protocol (DCOP, Corba, etc).
  214. # Are you sure that DCOP is too slow for in-process communications? I thought it
  215. # would handle this special case efficiently.
  216. s It is only efficient in the sense that it won't do a roundtrip to the server but
  217. s dispatch locally. What remains is the datastream marshalling. Not necessarily
  218. s ueberfast. But I think the point is a different one: It is simply not as intuitive
  219. s to use as C++. Yes, DCOPRef already helps a lot for simple calls, but talking to
  220. s remote components still requires one to do error checking after each method call.
  221. s in addition the stub objects one deals with (AddressBookIface_stub for example)
  222. s are no real references. To the programmer they look like a reference to a
  223. s remote addressbook component, but it really isn't. there is no state involved.
  224. s like if between two method calls on the stub the addressbook process gets restarted,
  225. s the state is lost and the programmer on the client side has no way to find out
  226. s about that. you'll end up with really complex code on the caller side to handle things
  227. s like that.
  228. d Yes, but of course one should always prefer in-process IPC if possible. DCOP
  229. d currently _works_ for Kontact, but that's all about it. It isn't exactly elegant.
  230. d The only advantange of the current approach is that we can allow the user to
  231. d run one of the parts standalone. I am not really sure we want that. I used to find
  232. d it desireable, but I am not sure anymore.
  233. MiB: But that's the whole idea behind Kontact---to be able to integrate apps
  234. MiB: _and_ to have standalone versions. Just think about KNotes... impossible
  235. MiB: to have it limited to only Kontact!
  236. Don: I love being able to run the apps inside or outside of the
  237. Don: container, it's just really cool being able to choose I think it's a
  238. Don: great feature and users will really love having the
  239. Don: choice. Especially when they are migrating.
  240. MiB: Definitely.
  241. Don: I think if we use the loadX methods defined above then we can still
  242. Don: support this. I'm PRO DCOP. And this way we don't have to special
  243. Don: case of the code depending on whether the application is running in
  244. Don: a container app or not.
  245. Don:
  246. Don: I find difficult to imagine a function that DCOP is not fast enough
  247. Don: to support. It supports all our current PIM IPC needs fine.
  248. MiB: yes, not too much against DCOP. But for KNotes I thought about turning
  249. MiB: a note into a plugin that can be loaded by Kontact and KNotes independently.
  250. MiB: like this, there's no DCOP necessary anymore and makes it much more flexible.
  251. MiB: e.g. usage of different display configs, a note embedded somewhere and having
  252. MiB: a parent or standalone on the desktop.
  253. # Communication with external applications is something which doesn't fit too
  254. # well with the 'integrated' approach of Kontact. Is this really necessary?
  255. d We won't get around it, think knotes, maybe sync tools, think abstact 3rd party
  256. d projects (not sure the latter is really that important, but we should consider it.
  257. d it barely plays a role anyway).
  258. MiB: hm. true. But not too important, IMHO. Just add a Kontact-DCOP interface :-)
  259. h: Pretty much to talk about...
  260. h: 1. the speed of DCOP is not that important. I worry more about the integration
  261. h: of all parts. So how would I cross reference an 'Event' with a 3rd party
  262. h: Kaplan Part? A common base class for all PIM records comes into my mind - again -
  263. h: Now with normal C++ you can pass a pointer through the framework
  264. h: Doing it with DCOP we need to marshall and demarshall it. This part can get really
  265. h: ugly if we want more tight integration of all KaplanParts. We could add
  266. h: a pure virtual method to marshall to a QDataStream. So now marshalling is done.
  267. h: For demarshalling we need to get the type of the QDataStream content and then we need
  268. h: to ask someone - a factory - to get a object for the type and then call another pure
  269. h: virtual.....
  270. h: The question is if this is really necessary
  271. h: 2. stand a lone apps
  272. h: The 'stand a lone' app can always run in the same address space but be a top level widget
  273. h: itself. WIth some DCOP magic clicking on the KMAIL icon code make Kaplan detach the part...
  274. h: 3. Integration!
  275. h: The goal of Kaplan should not be to merge some XML files an give a common Toolbar for
  276. h: X applications in one shell. I want true integration. Yes KMAIL can use KABC to show
  277. h: all emails for one contact but a generic way to do such things would be more than nice.
  278. h: It would be nice if I could relate the PIM objects in a common way. So I create an Event and
  279. h: relate some todos to it. So for KDE4 I want a common base class for all PIM classes including mail
  280. h: see Opies OPimRecord for a bit too huge base class
  281. Security
  282. --------
  283. d If we use the tdeparts (ktrader) approach to find a parts by looking
  284. d for an application with the correct mime type this might raise security
  285. d problems. (Martin's concern)
  286. # Looking up Kontact parts isn't based on mime types but on services of type
  287. # "Kontact/Plugin". This is just as save as starting a program statically linking
  288. # its parts. I really don't see any security concerns here.
  289. d Ok, if we limit stuff to Kontact/Plugin and Kontact/Part that might be safe enough
  290. d indeed. I (and Martin, who raise this concern initially) was just afraid of
  291. d allowing "any" part.
  292. h: hmm If somebody can install a Service into the global kde dir or the user kde home
  293. h: there is something else broken IMHO
  294. Summary View
  295. ------------
  296. h: How would one best integrate a summary view into kontact?
  297. h: a) add a virtual QWidget *summary(const QDateTime&, QWidget* parent );
  298. h: to get a summary widget for a day?
  299. h: b) use some sort of XML to UI to represent the summary informations
  300. h: c) have a stand a lone part which opens the PIM data seperately? ( How
  301. h: to synchronize access? )