summaryrefslogtreecommitdiffstats
path: root/konqueror/IDEAS
diff options
context:
space:
mode:
authortoma <toma@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2009-11-25 17:56:58 +0000
committertoma <toma@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2009-11-25 17:56:58 +0000
commit4aed2c8219774f5d797760606b8489a92ddc5163 (patch)
tree3f8c130f7d269626bf6a9447407ef6c35954426a /konqueror/IDEAS
downloadtdebase-4aed2c8219774f5d797760606b8489a92ddc5163.tar.gz
tdebase-4aed2c8219774f5d797760606b8489a92ddc5163.zip
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
Diffstat (limited to 'konqueror/IDEAS')
-rw-r--r--konqueror/IDEAS223
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
+
+
+