TDE personal information management applications
Vous ne pouvez pas sélectionner plus de 25 sujets Les noms de sujets doivent commencer par une lettre ou un nombre, peuvent contenir des tirets ('-') et peuvent comporter jusqu'à 35 caractères.

376 lignes
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? )