Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features.

BUG:215923


git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdebase@1054174 283d02a7-25f6-0310-bc7c-ecb5cbfe19da

1 files changed, 223 insertions, 0 deletions

diff --git a/konqueror/IDEAS b/konqueror/IDEAS
new file mode 100644
index 000000000..426b4d006
--- /dev/null
+++ b/konqueror/IDEAS
@@ -0,0 +1,223 @@
+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.
+
+
+<tfischer> 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
+==========
+<tronical> we have a usual mainwindow (looks/behaves quite like a current kfm window on the screen)
+<tronical> now we have two views inside, on the left we've got an iconview
+<tronical> and on the right we've got an htmlview
+<tronical> now let's say the iconview wants to add a special entry in the common view menu
+<tronical> no, let's say three entries: mini-/medium-/large icons
+<tronical> and for the htmlview we've got (in the view menu as well):
+<tronical> whatevery...hm...*thinking*, perhaps charset-selection of stuff like this
+<tronical> now when the iconview is active the view menu will contain
+<tronical> all the usual konqueror (mainwindow) entries (what could this be for example?) plus the three iconview 
+  entries
+<tronical> and when the users activates the htmlview then view menu will silently change
+<Zogje> I think it makes sense to have both sets of entries in the view-menu at the sma time
+<tronical> ok, well, it's possible to do this
+* tfischer thinks zogje is right.
+<tronical> there's no change in the design necessary
+<Zogje> because the user just has a html-view and an inco-view on his screen, and has no idea which one is 
+  "active"
+<tronical> hm, you're right
+<tronical> ok, but I think we can easily solve this:
+<tronical> first we create the common konqueror menu entries
+<tronical> then insertSeparator( -1 );
+<Zogje> ack
+<tronical> and then the first views' entries
+<tronical> then another separator, ...and so on
+<Zogje> yes
+<Zogje> that seems quite good
+<tronical> we might do something like this:
+<tronical> common konqy entries
+<tronical> separator
+<tronical> dummy-not-doing-anything-entry named viewName()
+<tronical> separator
+<tronical> view entries
+<tronical> yet another separator
+<tronical> second view's name as dummy entries
+<tronical> and so on
+<Zogje> yes.. because if we have two html-views... you want to be able to select things for both independntly
+
+
+