Can we* prettyplease do something about the KUrlNavigator?

[James Richard Tyrer]

Thomas � wrote:
> *we means "if i get the ok from someone who feels in charge, i'm willing to do 
> this"
> 
> if you want to respond, please notice that usability list is cc'd
> 
> this is gonna be rather long, sorry :-(
> 
> this could partially sound like a little rant. well, yes it is. ;-P
> 
Note that unless a rant is clearly humorous, it is possible to take it
as a personal insult.

Peter Penz has done excellent work here and I suggest that your tone
could be taken as personal -- not a good thing.  However, this is
software engineering and things are improved by discussions (even
objective arguments) so there is nothing wrong with saying what you
think is wrong, why you think this, and how it could be improved -- that
is useful criticism.  However, this should be done in formal descriptive
terms -- saying that something 'sucks' is not useful because it is not
descriptive, not objective, and some might take personal offense at it.

Still, you may have some valid points.

> ---
> 
> Hi everyone.
> 
> first off all:
> i'm neither questioning the usability nor the need of a way to manipulate 
> paths w/o a keyboard input, but the way it's atm. /imho/ just sucks.
> 
Perhaps there is room for minor improvements to improve usability
despite that fact that the current implementation is very good (it is a
long distance from 'sucks').

> i won't mourn about implementation details like that it hardcoded paints 
> QPalette::ButtonText on autoFillBackground() == false or the arrow foreground 
> differs from the text when hovered (ok: in fact i just did), but will mourn 
> about the general (visual) concept.
> 
> a.
> the default appearance does no way indicate that the user is able or supposed 
> to change the path or anything here, as it resembles rather a label than an 
> input. (iff, then because the user knows the concept from e.g. vista... and 
> can detect it by the arrow delimited items)
> 
Perhaps it is better to compare it to the File Select dialog in GTK
(Firefox uses it).  This has something similar to bread crumbs but it 
has no triangles.  This has each bread crumb on a button and the button 
for the current
directory is depressed.

> b.
> if you click it for editing, it changes it's entire appearance to a default 
> line edit and adds a toolbutton, what doesn't look like "i've activated 
> something" but like "i just changed the app... in... errr... whatever."
> 
I don't see this point except that I don't think that this (on the 
right) is a good location.  It is better in the KDE-3 version -- on/off 
icon on the left.  I agree that clicking on the bar to change to 
"Editable Location" could confuse some newbie users, but I don't see it 
as a major issue.

> c.
> in the lineedit mode you get an
> - additional icon in front of the path (i.e. inside the lineedit) that in 
> worst case looks exactly like the one on the pushbutton to select a default 
> path

That icon in the location field belongs there.  It is the same in 
Konqueror.  However, there is a valid point about the icon for the 
Places list.  Currently, the icon used appears to be the icon for the 
Home Folder.  IMHO, this is not the best choice.  I would suggest that 
an icon for Places be created and used instead.

I note that we appear to lack an Oxygen icon for "Editable Location".

> - a toolbutton (in contrast to the pushbutton...) that shows an undo (to do 
> what? undo the path change? *grrr*) icon to "go back" to the previous 
> "breadcrumb" appearance
> 
I see not issue here.  It is editable text and there is an "Undo" 
function.  The use should be obvious.

> i want to chage this /in general/
> 
> proposal:
> -----------
> 
> 1st
> the look should please *not* be entirely changed between "breadcrumb" and 
> lineedit mode
> 
These are widgets.  The appearance is that of the widgets.  For 
consistency, the location bar ("Editable Location") should look the same 
in every application that uses it.

> 2nd
> the look should clearly indicate that "this is an input area" (then this thing 
> would be even usefull outside the filemanager context)
> 
As I said, using buttons like GTK should accomplish this.  Yes, the 
widget would be useful other places.  I would like to see it available 
in Konqueror (at least for file management functions).

> -> conclusion:
> the whole thing should always look like a lineedit, with changes on the 
> content /only/
> 
That would not be good, it would make the interface inconsistent. 
Buttons (even if you can't tell that they are buttons) have one color 
and an editable text box has another color.

> 3rd
> the double icon sucks, so the path-selecting pushbutton should display the 
> icon for the current path and the in-line icon should go away. period.
> 
That icon is part of the location widget.  The change that could be made 
is to change the icon for the button that displays the Places list.

> 4th
> the undo button is the worst part (regarding the navigator) of them all. 
> it will however vanish because...
> 
I totally disagree here.

> 5th
> ...i want the behaiour a little more "automagic"
> 

I miss the point.

> in detail:
> - the navigator /always/ looks like a lineedit
> - by default (i.e. not focus'd) the lineedit /always/ contains the 
> "breadcrumbs"

IIUC, you want to combine the location widget and the breadcrumb widget. 
  This is an interesting idea.

So, you would have the breadcrumbs buttons on the left and you could 
enter text to the right of them and it would be combined with the bread 
crumb path to make a URL.

This would be a totally new widget that would require new development, 
it is not just a minor change.

> - the "breadcrumbs" (if there's any proper term for this, please help me out) 
> will resemble the look of weblinks, rather than of "i don't know what" - 
> itemview icons w/o icons? 
> 
No, they don't need to look the same and they shouldn't.  A window that 
accepts text should not look the same as buttons.  And, it needs to be 
consistent with the rest of the interface.

> * when hovering a text part, 
> --------------
> � the cursor changes to a pointing hand
> � the "link" get's underlined
> � the textcolor is changed to QPalette::Link (which is supposed to contrast 
> QPalette::Base what itself is supposed to be the QLineEdit background role)
> 
> (the underlining in addition to the color change should be done in respect of 
> ppl. with visual disfunctions as well as catching the case that the user just 
> set QPalette::Link to QPalette::Text)
> 
I don't think that this would be good.  The reason is that it would be 
totally different from the rest of KDE.  However, when you hover over a 
button, the button should indicate this (even if it doesn't look like a 
button).  In the KDE-3 version, the quasi-buttons act like buttons when 
hovered and change colors -- but that is style dependent.

> * when hovering a "triangle",
> ----------------
> � the cursor changes to a pointing hand

No, this is not consistent -- the cursor does not change when hovering 
buttons.

> � the triangle direction changes to S or SE (SW on rtl)

This might be a good idea.  I don't know if KDE currently supports this. 
  Animated icon perhaps??

> � the triangle color is changed to QPalette::Link (see above)
> 
Yes, it should act as a hovered button, but that would not be a change 
to the link color.

> * when hovering an empty area the cursor becomes an I-beam (instead of the 
> pipe "|" at the end of the line which looks rather like a visual error)
> 
Again, that is part of the larger style and shouldn't be changed for 
just this widget.

> * when clicking an arrow or link the behaviour remains as it is (except the 
> popups could provide access to subdirs, but that''s sth. different)
> 
This would be excessively complex.  Actually, I don't think that the 
triangles are necessary.  I would simply eliminate them as unnecessary 
complexity.

> * when clicking the empty area (I-beam) the content changes to a traditional 
> lineedit / KUrlSelector with delimiting slashes, a (blinking) cursor etc.
> 
Again, this would require a new widget, it is not just a change to the 
existing ones.

> * when the UrlNavigator looses the focus, the content returns to the 
> breadcrumb mode. 

Yet there is something to be said for some sort of automatic changes 
between the two modes.

> no undo icon, ever.
> 
I always expect 'undo' for text edit.

> objections, opinions, additions or comments anyone?
> 
To reiterate, I would object to anything that was at odds with the 
general KDE interface.

If you want to try to develop a new widget, that would be a good project 
for you.

-- 
James Tyrer

Linux (mostly) From Scratch