Konqueror "Ideas" Document (specification, general ideas) Authors: Waldo Bastian David Faure Simon Hausmann Last modified: 7 Mar 1999 Intro ===== I am trying to create a picture of how Konqueror should look like in KDE 2.0. If such a picture is clear, it is easier to build Konqueror such that it will feel like a consistent piece of software. This is of course only my view of the things. If someone has other views please let this know. It will help if a sort of common idea about the future of Konqueror exists. KDE 2.0 ======= I think we should keep Konqueror a "browser": You can browse with it, and look at things. But when you want to _DO_ things, you will need a full-fledged application. So you can view HTML with it. You can view directories with it. You can view text-files with it (read-only). (basically kless) You can view images with it. You can view mail-folders with it. You can view newsgroups with it. You can view xxx.... When you want more advanced manipulating options, modify things, or create things (writing a mail for instance) the "Real (tm)" application should pop up with its own menubars etc. There is of course a thin line between viewing and modifying. With the file browser you want to be able to move/rename/delete files. So if we allow this functionality for file-browsing, we should also allow it for mail-browsing or news-browsing. (e.g. move/delete message cq. postings). Creating does not really belong in a browser (apart from directories) because you will almost always need an application for this anyway. I seldom go to a directory to select "create xyz". Most of the time you start an application to create "xyz" and when you are done, you think of a nice place to store it. (I think Microsoft wants us to believe otherwise, with their "document-orientated" Windows95 marketing) ((Well, sometimes you are browsing and have a sudden urge to put a text-file like README in a directory. But for that you still need a text-editor. Just creating an empty file is of little use.)) Why is this important? ====================== There must be a clear distinction between what can be done with Konqueror and what can be done with the application self. If there is no distinction we don't need Konqueror. Smooth integration ================== With this Konqueror thing we have to tell the user a thing or two. We have to tell the user what he/she is doing: "Viewing a text-file", "Viewing a web-page", "Viewing a FTP-site", "Viewing e-mail". Because the options available to the user, depend on what he is doing: You can reply to e-mail. But you can't reply to a FTP-site. You can sort the entries of a FTP directory, but you can't sort a web-page. At the same time, we have to tell the user that he/she is "Viewing". If you want to edit the web-page, the web-editor comes up. If you want to reply to the e-mail, the mail-composer comes up. At that time the user is editing/changing/modyfying. From the users point of view, the "viewing" part is konqueror. The editing part is the application. From the developers point of view, this can be different. The view e-mail mode of Konqueror could (but it doesn't have to) be handled by the same instance of kmail as the "edit" mode of kmail. If this will be indeed the case should depend on programming considerations. What should not depend on programming considerations, is how it is presented to the user. An Example ========== Teodor Romeo Mihai wrote: > Well, I've been working for a few months now on a Outloook-clone for > KDE, handling mail/contacts/schedule/journal/notes/groups. It is a bit > different from all KDE applications I've seen, being very close to > Outlook in look&feel rather than KMail - which I find unusable. > If you are seriously planning to put mail in kfm, maybe you should > consider some kind of integration with an external mailer, in > Explorer/Outlook style. I'm serious about integrating mail-viewing in Konqueror. (From a user point of view). I think it is a very bad idea to put mail-reading code in Konqueror. (From a developers point of view). Konqueror should be able to display mail/mailboxes by embedding a mail-viewer. This mail-viewer should (in the case of a mail-viewer) be a seperate application from a developers point of view, but should integrate seemless with Konqueror from the user point of view. This application can be kmail, a light version of kmail, or any other application that can display mails and supports this embedded KFM-view idea. For viewing HTML or GIF files, Konqueror will most likely implement the functionality itself. For the user it should not make any difference if a view is implemented in Konqueror itself or in a seperate application. The technology to embed the mail-viewer should be something CORBA based. Most likely KOM/Openparts. Konqueror should not become a program like Netscape Communicator: A program that tries to do everything itself, and as result, does everything very poorly. Konqueror should do it better and the Unix way: Have speciliazed components which are very good in their task. Konqueror provides the seemless integration of them and provides easy navigation abilities. This means i can create an application (container) which host two parts, which are both ACTIVE, that means i do not need to click the parts before they start repsonding. Konqueror Views =============== When an embedded part gets the focus (e.g. when the users clicks on it) the mainwindow (shell) gets notified about this (the focus change). You can "manually" activate a part by calling a method in the mainwindow interface. There can be only part that has the focus. If you click on a non-activated part the click action itself is not "eaten up" An activated part means the part has focus (keyboard, ...) When you have "plain" parts they usually "have" their own GUI which get's "enabled" (created dynamically) when the part gets the focus Normally this would bring a big problem inside konqueror Because then we'd have lots of duplicated *bar creation code and stuff like this. That is the reason why in konqueror functionality is implemented in openparts to have so called child parts. A child part does _not_ have it's own GUI (as a normal openpart has) instead the part part's gui is used. We still allow konqueror views to have their own view specific gui elements When a konqueror view (=part child) gets the focus the part parent (the mainwindow) will receive an event (eventChildGotFocus) and this helps the mainwindow to send yet another event to the just activated view (=part) , an konqueror specific event these events are described in konqueror.idl The result is: A konqueror view (that's important, the view must support this interface) can now specify it's own, view specific, menu entries in the edit/view menu plus it's own toolbar. This integration is in fact not sooo seamless because: whenever the use activates your khelpcenter part a complete GUI "switch" will take place, meaning all the *bars from konqueror will be replaced by the *bars from the child view Therefor another approach is developed: The *bars of konqueror will contain entries for all child-views which are inside the main-view. Care should be taken when multiple views want to add the same entries to one of the *bars. In the case of a toolbar, only one entry could be added, the child-view which has supplied this entry will be made active when his entry is used and will get the event. If multiple child-views have provided this entry, the currently active child will get the event. For the menubar, the entries will be presented grouped per child-view. The same entry could be listed twice in the same menu, but listed under two differents views. Transcript ========== we have a usual mainwindow (looks/behaves quite like a current kfm window on the screen) now we have two views inside, on the left we've got an iconview and on the right we've got an htmlview now let's say the iconview wants to add a special entry in the common view menu no, let's say three entries: mini-/medium-/large icons and for the htmlview we've got (in the view menu as well): whatevery...hm...*thinking*, perhaps charset-selection of stuff like this now when the iconview is active the view menu will contain all the usual konqueror (mainwindow) entries (what could this be for example?) plus the three iconview entries and when the users activates the htmlview then view menu will silently change I think it makes sense to have both sets of entries in the view-menu at the sma time ok, well, it's possible to do this * tfischer thinks zogje is right. there's no change in the design necessary because the user just has a html-view and an inco-view on his screen, and has no idea which one is "active" hm, you're right ok, but I think we can easily solve this: first we create the common konqueror menu entries then insertSeparator( -1 ); ack and then the first views' entries then another separator, ...and so on yes that seems quite good we might do something like this: common konqy entries separator dummy-not-doing-anything-entry named viewName() separator view entries yet another separator second view's name as dummy entries and so on yes.. because if we have two html-views... you want to be able to select things for both independntly