Konqueror 4

[Aaron J. Seigo]

On Saturday 28 October 2006 2:31, Martin Konold wrote:
> Am Samstag, 28. Oktober 2006 01:20 schrieb Aaron J. Seigo:
> > one example is the location bar. it makes all the sense in the world to
> > have a fully editable url bar as we do now for a browser (e.g. a web
> > browser). but is it the most ergonomic thing in a file manager? hm.
>
> Well, I think it is most useful. Why do you think that a fully editable
> location bar is useless for filemanaging tasks?

i didn't say it was useless. i asked if it was the most ergonomic thing.

try the implementation in dolphin; you'll notice it's quite easy to jump 
between breadcrumb and editable location bar. there's a button, a keyboard 
shortcut and a config option.

> > so the big question is: one browser+manager or one browser and one
> > manager?
>
> I guess we need some more indepth reasearch from HCI people.
>
> I regularily experience that Windows users are actually confused that
> explorer and Internet explorer are two different programs and they don't
> understand why they cant use c&p or d&d between IE/ftp and the local
> filesystem / explorer. What makes things even more confusing is that the
> Windows explorer has _some_ networking capailities too.

this has -nothing- to do with what each can access. let's think about this for 
a second: the preferred and recommended means for a kde application to access 
files is via kio which is "network transparent". we view apps that can't do 
this as odd and even buggy. so why exactly would i suggest to neuter konqi 
this way? that would be, in my own estimation, *stupid*.

the difference between a "browser" and a "manager" are interface differences. 
that's why in my email i talked about interface differences rather than file 
access methods. in a "browser" one is navigating a large information space 
that is arranged in a way for perusing; the web is a perfect example; a 
collection of ebooks might be another; one may want to "browse" their files. 
in a "manager" one is more likely to be sorting, labelling, searching, 
grouping and working with the set of data.

so in a browser it may well make sense to type "http://kde.org/areas/sysadmin" 
and deal with that as the first class navigation system but 
typing "/home/aseigo/manuals/kde/sysadmin" in a text edit and having only 
that text edit as a way to deal with my location, while obviously possible to 
live with, is probably not the fastest mechanism since it's a common and 
perfectly correct use case to jump back to /home/aseigo/manuals (as one 
example) which isn't the case with websites (where the list of entries in the 
url may not represent an actual hierarchy). moreover, such a breadcrumb may 
go a long ways to eliminating the need for most users needing an actual tree 
widget to display the hierarchy given the use case of a file manager.


p.s. let's please not derail this conversation (and sink yet another attempt 
at improving on the already pretty nice tools we have in kde3) by discussing 
irrelevant things like "will it be transport neutral?"

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20061029/90d017a0/attachment.sig>