Konqueror 4

Michael S. Mikowski mmikowski at valueclick.com
Tue Oct 31 01:22:48 GMT 2006


Hi Everyone:

I am not a kfm developer, but I use Konqueror every day for hours.  I 
subscribe to this list.

I sent a note earlier, but don't see it posted.  Perhaps there is an 
authorization list.  If not, maybe this will make it through.

In sum, I like Konqueror very much.  It is the first thing I show off to 
people who are considering moving from Gnome to KDE.  We open up 3 panes 
using multiple transports, -- say Samba, sftp, local disk -- and then move 
files between them and preview their contents in each.  Very compelling.

I don't see a need for a separate application for file management.  Maybe a 
cleaning up of menus for Konqueror, but a separate application seems like 
overkill.  I find Gnome bread crumbs very restrictive and annoying most of 
the time.  And it takes up too much screen space.

The only benefit to breadcrumbs is navigating back up the tree.  Maybe the 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.

Overall, I think Konqueror as a combined file manager and canvas is brilliant.  
Outside of some UI tweaks, I'd say "don't fix it" because I don't think its 
broken.

Cheers,

Mike


On Monday 30 October 2006 16:34, Aaron J. Seigo wrote:
> On Monday 30 October 2006 17:05, Allan Sandfeld Jensen wrote:
> > On Tuesday 31 October 2006 00:28, Aaron J. Seigo wrote:
> > > this is not true in all use cases. it's only guarantee-ably true when:
> > >
> > >  - the user is descending (upwards and sideways navigation is often
> > > slower) - the user knows where they are going
> >
> > No, descending is faster by typing,
>
> if the user knows where they are going, yes. isn't that what i said?
>
> > sideways navigation is faster.
>
> going from /home/aseigo/pix/venezuela to /home/aseigo/music:
>
> editable:
> 	click mouse in edit area or press F6+end
> 	press delete key or highlight pix/venezuela with keyboard or mouse
> 	type "music"
>
> breadcrumb:
> 	click aseigo, hold momentarily
> 	select music
> 		or
> 	click aseigo button
> 	move mouse into view
> 	click music folder
>
> and that's assuming the user has perfect knowledge of their system. this
> does not measure user confidence and awareness in any way.
>
> > > "throwing it away we are not!" says yoda. "letting the user switch
> > > between breadcrumb and editable are we, as well do we let them choose
> > > their default. the force may be strong with you so you use an editable
> > > bar, mmmh? but most weak are with the force. trees and URIs ergonomic
> > > they are not. them we give the breadcrumb."
> >
> > That's a problem, not a solution. As you state above there are different
> > cases where one is usefull. This makes it a poor replacement, and makes
> > no improvements to the current users skilled in the current interface.
>
> if you don't like it: don't use it. simple. flip to the editable text edit
> and be happy. but let others have something that works for them, too.
>
> that said, you assume that most of our users are skilled in the current
>
> interface. similar to this statement:
> > Sorry if I am reactionary, but I value real users higher than potential
> > users.
>
> the implicit assumption in this statement is that current kde users are
> served well by the editable bar. it is true that you and i may be skilled
> with it; other power users may be skilled with it; but you may have (or
> not?) noticed that most of our users today are not like you and i. we
> became the minority by a long shot some years ago. we need to continue
> serving us and those like us well because we're exceedingly valuable and
> important to the project, and as loyal users deserve nothing less. this
> needs to be balanced with the needs of our general user base.
>
> having been using this widget now for the last several days it strikes
> quite a nice balance here; not to mention i haven't missed the
> editable-only alternative one bit because, as a power users, i've
> discovered the keyboard shortcut (there's also a button you can click if
> you'd like) that, much like F6 does today, gives me an editable bar with
> keyboard focus. and unlike in GNOME's file dialog these modes of usage are
> well revealed in the interface.
>
> now, how about support for the statement opposite to the one you note: that
> current kde users are not served well by the editable bar? evidence
> relating to the poor performance of raw URIs (leading to media:/, system:/
> and others which caused other problems), evidence of breadcrumbs actually
> working very well for a broad class of users ... seems there's a good set
> of arguments here. not to mention dolphin's user base, which is rather
> larger than i expected to be honest.
>
> of course we -could- find out by trying this that the breadcrumb completely
> sucks ass for most people. in which case we just switch to the editable
> thing by default. but we'll only know by trying. dare to try and we'll all
> learn a hell of a lot more than we do when we jerk our knees about and
> refuse to imagine and create new things where problems have arisen.
>
> > > > we should have
> > > > locationbar with active parts so you can click on any part of the
> > > > path, and drag to any parts of it.
> > >
> > > then you end up dealing with appropriate click-drag distances for
> > > editing. there lie dragons. and for the minor difference this presents
> > > from a dual mode bar i don't see the point, though i do see the
> > > pitfalls.
> >
> > Yes pitfalls that's UI design, but as long as you cannot drag the path
> > onto itself you should be pretty safe. So you can drag away from the
> > path, or you can drag onto it.
>
> i meant that if you want an editable bar with clickable bits you need to
> differentiate between click-and-drag-because-i-wish-to-highlight-and-edit
> and click-to-go-to-this-element. and yes, this does mean no dragging of
> path elements (though that's probably not much of a loss).

-- 
Michael S. Mikowski
Software Engineering Manager
ValueClick Search
ValueClick Inc.
818.575.4587




More information about the kfm-devel mailing list