From kfm-devel Tue Feb 16 14:16:15 1999 From: Waldo Bastian Date: Tue, 16 Feb 1999 14:16:15 +0000 To: kfm-devel Subject: Re: konqueror components X-MARC-Message: https://marc.info/?l=kfm-devel&m=92386536625622 Simon Hausmann wrote: > (this way it'd be possible for apps to create their own kfm views and "add" > them to konqueror (here as KfmMainView) . For example KMail might provide a > kmail-kfm-view to process mails "inside" konqueror when browsing the web) > In addition I think we might add a fourth (fifth?) part kfm view which does > nothing else than embedding other apps parts (for apps not wanting to "use" a > common kfmview parent interface) . 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. Discussion please? Cheers, Waldo -- KDE, Making The Future of Computing Available Today http://www.kde.org