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

List:       kde-i18n
Subject:    Re: new desktop metapher?
From:       David Faure <faure () kde ! org>
Date:       1999-04-01 8:07:19
[Download RAW message or body]

On Thu, Apr 01, 1999 at 12:20:28AM +0200, Martin Konold wrote:
> Dear David, 
                   
Dear Martin,

> I am rather impressed with your progress. 
BTW, you must know that credits also go to Simon Hausmann for most of the KOM/OP
view-embedding, as well as many other people.

> But please I do somewhat get the                   
> impression that this konquerer develops to a complete desktop within a
> desktop.
I will try to show you why this new konqueror design is consistent, and doesn't
replace a desktop. Let me detail this below.

> What are the advantages of MDI views compared to multiple
> instances of konquerer windows?       
Being able to open N views is a choice left to the user.
We took into account your last remark about the complexity introduced,
as we decided not to use a KMultiPanner-type widget, too complicated 
in terms of user-interface, and we use instead simple horizontal
QSplitters, vertically divided.

> Please consider that, due to consistency, people will also expect to be
> able to edit the stuff which is currently only displayed (after all it is
> a browser and NOT an editor/desktop).
AFAIK, users don't expect that. The 1.1 kfm behaves this way :
* click on an HTML file, it shows it embedded in kfm, for _browsing_ only,
not editing.
* click on an image, it will open kview, for browsing only, but not embedded.
* click on a Text file, it will open an editor.

This is totally inconsistent, obviously !
Hence the idea of being able to browse anything in konqueror.
Click on a text file, HTML file, image, dvi, whatever, you can SEE it in konqueror.
Now if you want to edit it, RMB + choose your app.
Of course this would be configurable (got an idea about that yesterday,
separate post
to come), so that users that want the "always-edit" behavior can have it.

Any of those behaviours IS consistent : either always-browse or always-edit.
(In fact, as the user can choose what app. to launch, the choice is rather
always-show-embedded or always-show/edit-with-other-application).
Consistent nevertheless.

More consistentcy can even be gained in handling ALL types of URLs (of all
protocols) 
in the konqueror location-line. Lots of users expect
man:ls, info:cp, mailto:joe@kde.org, ... to work in kfm.
But none does.
This IS inconsistent, really is.
info:cp works ONLY in kdehelp, whereas http://www.kde.org works in kdehelp
AND kfm.
Ouch.

So konqueror could embed a kdehelp (well, khelpcenter) view when asked for
a man: or an info: URL. (We could even imagine a help:<program> URL scheme).

> IMHO the MDI concept was a necessety when interapplication communication 
> was very difficult/not standardized and full screen apps used to be the 
> default.
Our goal is NOT to replace the desktop, and NOT to make people use
konqueror full screen.
If you have a small/medium image or text somewhere, viewing it embedded it
really fast, doesn't require you to maximize the window, and is simpler to
handle (for the user) than a separate window popping up. Just play around
a bit with the current konqueror and you'll find that very handy. Oh, a 
text file, I just click on it, and you can see it
at once, and in a place you can expect. kedit (or kview) would pop up any place
on the desktop, whereas you KNOW where the image will appear in konqy.
Then click back (or up), you're back. Easy, fast, lightweight. But just for 
browsing, sure.


For everybody : those are the screenshots that started this thread.

konqueror with 3 view : ftp://sabpc.resi.insa-lyon.fr/incoming/konqueror.gif
kview embedded :  ftp://sabpc.resi.insa-lyon.fr/incoming/konqykview.gif
text view in konqy : ftp://sabpc.resi.insa-lyon.fr/incoming/konqtext.gif
(European daytime only)


-- 
David FAURE
david.faure@insa-lyon.fr, faure@kde.org
http://www.insa-lyon.fr/People/AEDI/dfaure/index.html 
KDE, Making The Future of Computing Available Today

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