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.
224 lines
9.5 KiB
224 lines
9.5 KiB
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
|
|
|
|
|
|
|