TDE base libraries and programs
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.

IDEAS 9.5KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223
  1. Konqueror "Ideas" Document (specification, general ideas)
  2. Authors:
  3. Waldo Bastian
  4. David Faure
  5. Simon Hausmann
  6. Last modified: 7 Mar 1999
  7. Intro
  8. =====
  9. I am trying to create a picture of how Konqueror should look
  10. like in KDE 2.0. If such a picture is clear, it is easier to
  11. build Konqueror such that it will feel like a consistent piece
  12. of software. This is of course only my view of the things. If
  13. someone has other views please let this know. It will help if
  14. a sort of common idea about the future of Konqueror exists.
  15. KDE 2.0
  16. =======
  17. I think we should keep Konqueror a "browser": You can browse
  18. with it, and look at things. But when you want to _DO_ things,
  19. you will need a full-fledged application.
  20. So you can view HTML with it.
  21. You can view directories with it.
  22. You can view text-files with it (read-only). (basically kless)
  23. You can view images with it.
  24. You can view mail-folders with it.
  25. You can view newsgroups with it.
  26. You can view xxx....
  27. When you want more advanced manipulating options, modify things,
  28. or create things (writing a mail for instance) the "Real (tm)"
  29. application should pop up with its own menubars etc.
  30. There is of course a thin line between viewing and modifying.
  31. With the file browser you want to be able to move/rename/delete
  32. files. So if we allow this functionality for file-browsing, we
  33. should also allow it for mail-browsing or news-browsing.
  34. (e.g. move/delete message cq. postings).
  35. Creating does not really belong in a browser (apart from
  36. directories) because you will almost always need an application
  37. for this anyway. I seldom go to a directory to select "create xyz".
  38. Most of the time you start an application to create "xyz" and
  39. when you are done, you think of a nice place to store it.
  40. (I think Microsoft wants us to believe otherwise, with their
  41. "document-orientated" Windows95 marketing)
  42. ((Well, sometimes you are browsing and have a sudden urge to put
  43. a text-file like README in a directory. But for that you still
  44. need a text-editor. Just creating an empty file is of little use.))
  45. Why is this important?
  46. ======================
  47. There must be a clear distinction between what can be done with
  48. Konqueror and what can be done with the application self. If there
  49. is no distinction we don't need Konqueror.
  50. Smooth integration
  51. ==================
  52. With this Konqueror thing we have to tell the user a thing or
  53. two. We have to tell the user what he/she is doing:
  54. "Viewing a text-file", "Viewing a web-page", "Viewing a FTP-site",
  55. "Viewing e-mail". Because the options available to the user, depend
  56. on what he is doing: You can reply to e-mail. But you can't reply
  57. to a FTP-site. You can sort the entries of a FTP directory, but
  58. you can't sort a web-page.
  59. At the same time, we have to tell the user that he/she is "Viewing".
  60. If you want to edit the web-page, the web-editor comes up. If you
  61. want to reply to the e-mail, the mail-composer comes up. At that
  62. time the user is editing/changing/modyfying.
  63. From the users point of view, the "viewing" part is konqueror. The
  64. editing part is the application.
  65. From the developers point of view, this can be different. The view
  66. e-mail mode of Konqueror could (but it doesn't have to) be handled
  67. by the same instance of kmail as the "edit" mode of kmail. If this
  68. will be indeed the case should depend on programming considerations.
  69. What should not depend on programming considerations, is how it is
  70. presented to the user.
  71. An Example
  72. ==========
  73. Teodor Romeo Mihai wrote:
  74. > Well, I've been working for a few months now on a Outloook-clone for
  75. > KDE, handling mail/contacts/schedule/journal/notes/groups. It is a bit
  76. > different from all KDE applications I've seen, being very close to
  77. > Outlook in look&feel rather than KMail - which I find unusable.
  78. > If you are seriously planning to put mail in kfm, maybe you should
  79. > consider some kind of integration with an external mailer, in
  80. > Explorer/Outlook style.
  81. I'm serious about integrating mail-viewing in Konqueror.
  82. (From a user point of view).
  83. I think it is a very bad idea to put mail-reading code in
  84. Konqueror. (From a developers point of view).
  85. Konqueror should be able to display mail/mailboxes by embedding
  86. a mail-viewer. This mail-viewer should (in the case of a mail-viewer)
  87. be a seperate application from a developers point of view, but should
  88. integrate seemless with Konqueror from the user point of view. This
  89. application can be kmail, a light version of kmail, or any other
  90. application that can display mails and supports this embedded KFM-view
  91. idea.
  92. For viewing HTML or GIF files, Konqueror will most likely implement
  93. the functionality itself. For the user it should not make any difference
  94. if a view is implemented in Konqueror itself or in a seperate
  95. application.
  96. The technology to embed the mail-viewer should be something CORBA based.
  97. Most likely KOM/Openparts.
  98. Konqueror should not become a program like Netscape Communicator:
  99. A program that tries to do everything itself, and as result, does
  100. everything very poorly.
  101. Konqueror should do it better and the Unix way: Have speciliazed
  102. components which are very good in their task. Konqueror provides
  103. the seemless integration of them and provides easy navigation
  104. abilities.
  105. <tfischer> This means i can create an application (container) which host two parts,
  106. which are both ACTIVE, that
  107. means i do not need to click the parts before they start repsonding.
  108. Konqueror Views
  109. ===============
  110. When an embedded part gets the focus (e.g. when the users clicks on it)
  111. the mainwindow (shell) gets notified about this (the focus change).
  112. You can "manually" activate a part by calling a method in the mainwindow
  113. interface. There can be only part that has the focus.
  114. If you click on a non-activated part the click action itself is not "eaten up"
  115. An activated part means the part has focus (keyboard, ...)
  116. When you have "plain" parts they usually "have" their own GUI which get's
  117. "enabled" (created dynamically) when the part gets the focus
  118. Normally this would bring a big problem inside konqueror
  119. Because then we'd have lots of duplicated *bar creation code and
  120. stuff like this. That is the reason why in konqueror functionality is
  121. implemented in openparts to have so called child parts.
  122. A child part does _not_ have it's own GUI (as a normal openpart has)
  123. instead the part part's gui is used.
  124. We still allow konqueror views to have their own view specific gui elements
  125. When a konqueror view (=part child) gets the focus the part parent
  126. (the mainwindow) will receive an event (eventChildGotFocus)
  127. and this helps the mainwindow to send yet another event to the just
  128. activated view (=part) , an konqueror specific event
  129. these events are described in konqueror.idl
  130. The result is:
  131. A konqueror view (that's important, the view must support this interface)
  132. can now specify it's own, view specific, menu entries in the edit/view menu
  133. plus it's own toolbar.
  134. This integration is in fact not sooo seamless because:
  135. whenever the use activates your khelpcenter part
  136. a complete GUI "switch" will take place, meaning all the *bars from
  137. konqueror will be replaced by the *bars from the child view
  138. Therefor another approach is developed:
  139. The *bars of konqueror will contain entries for all child-views which are
  140. inside the main-view.
  141. Care should be taken when multiple views want to add the same entries to
  142. one of the *bars.
  143. In the case of a toolbar, only one entry could be added, the child-view which
  144. has supplied this entry will be made active when his entry is used and will
  145. get the event. If multiple child-views have provided this entry, the currently
  146. active child will get the event.
  147. For the menubar, the entries will be presented grouped per child-view. The same
  148. entry could be listed twice in the same menu, but listed under two differents
  149. views.
  150. Transcript
  151. ==========
  152. <tronical> we have a usual mainwindow (looks/behaves quite like a current kfm window on the screen)
  153. <tronical> now we have two views inside, on the left we've got an iconview
  154. <tronical> and on the right we've got an htmlview
  155. <tronical> now let's say the iconview wants to add a special entry in the common view menu
  156. <tronical> no, let's say three entries: mini-/medium-/large icons
  157. <tronical> and for the htmlview we've got (in the view menu as well):
  158. <tronical> whatevery...hm...*thinking*, perhaps charset-selection of stuff like this
  159. <tronical> now when the iconview is active the view menu will contain
  160. <tronical> all the usual konqueror (mainwindow) entries (what could this be for example?) plus the three iconview
  161. entries
  162. <tronical> and when the users activates the htmlview then view menu will silently change
  163. <Zogje> I think it makes sense to have both sets of entries in the view-menu at the sma time
  164. <tronical> ok, well, it's possible to do this
  165. * tfischer thinks zogje is right.
  166. <tronical> there's no change in the design necessary
  167. <Zogje> because the user just has a html-view and an inco-view on his screen, and has no idea which one is
  168. "active"
  169. <tronical> hm, you're right
  170. <tronical> ok, but I think we can easily solve this:
  171. <tronical> first we create the common konqueror menu entries
  172. <tronical> then insertSeparator( -1 );
  173. <Zogje> ack
  174. <tronical> and then the first views' entries
  175. <tronical> then another separator, ...and so on
  176. <Zogje> yes
  177. <Zogje> that seems quite good
  178. <tronical> we might do something like this:
  179. <tronical> common konqy entries
  180. <tronical> separator
  181. <tronical> dummy-not-doing-anything-entry named viewName()
  182. <tronical> separator
  183. <tronical> view entries
  184. <tronical> yet another separator
  185. <tronical> second view's name as dummy entries
  186. <tronical> and so on
  187. <Zogje> yes.. because if we have two html-views... you want to be able to select things for both independntly