[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: konqueror components
From:       Waldo Bastian <bastian () ens ! ascom ! ch>
Date:       1999-02-16 14:16:15
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic