Konqueror 4
David Faure
faure at kde.org
Mon Oct 30 11:23:19 GMT 2006
On Mon Oct 30 2006, Mark Rose wrote:
> As just a KDE user, I don't see the paradigms as so fundamentally different. I
> see Konqueror as a visual file accessing program. What's so neat about is
> that the transport mechanism is irrelevant. I really stop noticing whether
> I'm seeing something over http, ftp, fish, etc. Some file types Konqueror can
> display natively and others it opens in external viewers. A page of
> information and links known as a website is really not fundamentally
> different than a page of links known as a directory listing or folder view.
> For me, this seamless integration between local and remote, regardless of
> transfer mechanism, known as Konqueror, is the "killer app" for KDE and
> Linux. Konqueror is an absolute joy to use.
That was the kde3 konqueror idea indeed. But it turns out that by having everything
into the same application we end up with a large mess, where file-management and
web-browsing things are all mixed up: in the sidebar, in the configuration dialog,
in the behavior of the "Home" button... (and in the bookmarks).
Not everything can be "seamlessly integrated" between file-management and web-browsing.
Configuration is one good example of that: file management (local and remote, of course,
i.e. "directory views") is unrelated cookies and javascript and java and useragent etc.
Web bookmarks and the advanced history features (sidebar and "most often visited" menu)
are mostly used in the webbrowsing and not so useful for filemanagement.
We need filemanagement bookmarks, but those should be made separate, which even
makes it possible to share them with the file dialog - much more important than mixing
them with the web bookmarks. Basically the distinction isn't the protocol (transport),
but the (mime) type: directory bookmarks are for directory views and for the file dialog.
The part where I'm not sure is the document viewer embedding functionality.
That one seems to be useful for both filemanagement and webbrowsing,
(which is why I'm calling them that way; "document viewer/browser" is part of both).
I guess we can keep kparts embedding in both, but mostly on by default in the
webbrowser and mostly off by default in the filemanager - like it is already, except
for images. Which reminds me of another good reason for separating filemanagement
from webbrowsing: my wife wants images embedded into konqueror when
webbrowsing but not when clicking on local files. Two reasons: local images tend
to have much higher resolution (like scanned images or digital camera images),
and well, currently the embedded image viewer (khtmlimage I guess) doesn't zoom out,
so you only see a little topleft corner of the image. Could be fixed, but still it shows
the need for configurability and separation. The other reason: file manager windows
tend to be smaller than webbrowsing windows (if only because of the sidebar, but also
because if you want to dnd between file manager windows they need to be smaller
than the screen anyway), so there's not enough room for embedding (large) images into them.
But during webbrowsing, embedding makes sense (there's room) and is useful (less windows).
The main problem I had when Waldo first talked about separating filemanagement and webbrowsing
was: what should happen if you type a http url in a filemanager window. Currently you get
the webpage next to your directory-tree sidebar, which kind of sucks ;). With separate programs
we could simply open a webbrowsing window when typing Enter. My own usability study
(i.e. discussing my wife ;) ) shows that this is a good solution, even better than we do now:
for people who want an actual webbrowser window, without directory sidebar, this new
solution is even faster than "click on konqueror-webbrowser icon in panel, then type
url in new window". And vice-versa, we can open a filemanager window when typing
a directory-like url (local or remote) in a web window.
--
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kfm-devel
mailing list