Konqueror 4

[Aaron J. Seigo]

On Wednesday 01 November 2006 10:16, you wrote:
> On Wednesday 01 November 2006 08:04, Aaron J. Seigo wrote:
> > [...] Do you ever actually use more than 2 panes for work [to manage
> > files] or is that something you do only for demos?
>
> I do split to 3 panes for work maybe once a week or two, often when I need
> to consolidate from multiple source into a single directory.  Then it is
> /very/ handy for my work (which involves managing clusters of dozens of
> servers).

hmmm.. the awkward part here is that the UI gets progressively more complex 
when supporting arbitrary splittings/arrangements. in konqueror we have 
issues with visual feedback between panes as well as a complex control UI. 

perhaps we could do it as seen in spreadsheets and having a split "grab 
handles" that would let one split a view? it would leverage a probably better 
known visual metaphor.

we really do need to get some better usage metrics on these things, though. 
right now i have no idea how much certain features are used by our user base 
and that makes it all judgement calls which are never easy and prone to 
error.

> > it's a slightly different view from the code ...
>
> While I don't program in C++, I do develop on large scale mod_perl
> applications.  And I know how messy things can get sometimes :)

=)

> My point is, as a long time (8 years) Konqueror user, I think splitting the
> UI is a mistake.  It would introduce inconsistencies between two very
> similar UI's, confusing the user.  "Gee, am I in the web browser, or the
> file manager?"  "Why can't I do this here -- oh, I see, I'm not using the
> browser, I'm in the file manager," etc.

some inconsistencies are actually desirable since the use cases are not 
identical between browsing and managing (note i did not use the words "web" 
or "file" in there ;) in fact, i'd go so far as to say that it is not 
reasonably possible to optimize the experience for both browsing and managing 
in the same UI.

the trick is to categorize which inconsistencies are good and which 
consistencies are good. i think the following consistencies are mandated from 
both usability and code perspectives:

 - access to network vs static local vs dynamic local must remain transparent
 - utility dialogs for properties, transfers, etc should remain the same
 - clipboard features (drag 'n drop, cut/copy/paste) must not become specific 
to an application
 - toolbar and menubar ordering must be consistent (though not all entries 
would appear in both)

any others?

by keeping as much of this in the "file manager utilities" library (libkonq) 
as dfaure, ottens et al have clearly advocated we can keep from implementing 
these things separately in both applications. just as we do with everything 
else in kde.

> > we're not implementing "Gnome bread crumbs" [...]
>
> Thank you for the screen shot.  And while dolphins bread crumb presentation
> is much nicer, its still "crumby" :)

heh =) well, progress is made! if you have some concrete suggestions about how 
it could be made better i'm all eyes and ears (and fingers).

and i do understand that:

 - change is met by revolt, this is natural
 - not everyone likes every thing

> > > URL could be parsed and highlighted in a manner, e.g.:
> > >
> > > /usr/local/bin
> > > ----|-----|---|
> > >
> > > Then one could click on the space under, for example, /usr, and be
> > > moved to that directory.
> >
> > use more vertical space, which there is generally less of on most screens
> > (doubly so with "widescreen" displays), and provide a cryptic interface
> > element under the url? well, i'd be happy to try it out if someone does
> > up an implementation but i'm sceptical based on the above.
>
> I believe SGI's Indigo desktop used a similar interface at one time, and I
> recall finding it useful, not cryptic. 

do you or anyone else have access to screenshots of this? i haven't used an 
SGI CDE interface since the last century.

-- 
Aaron J. Seigo
humru othro a kohnu se
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/20061101/c4d841dc/attachment.sig>