Can we* prettyplease do something about the KUrlNavigator?

Thomas Lübking thomas.luebking at web.de
Wed Jun 17 23:09:18 BST 2009


*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

---

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.

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)

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."

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
- 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 want to chage this /in general/

proposal:
-----------

1st
the look should please *not* be entirely changed between "breadcrumb" and 
lineedit mode

2nd
the look should clearly indicate that "this is an input area" (then this thing 
would be even usefull outside the filemanager context)

-> conclusion:
the whole thing should always look like a lineedit, with changes on the 
content /only/

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.

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

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

in detail:
- the navigator /always/ looks like a lineedit
- by default (i.e. not focus'd) the lineedit /always/ contains the 
"breadcrumbs"
- 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? 

* 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)

* when hovering a "triangle",
----------------
° the cursor changes to a pointing hand
° the triangle direction changes to S or SE (SW on rtl)
° the triangle color is changed to QPalette::Link (see above)

* 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)

* 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)

* when clicking the empty area (I-beam) the content changes to a traditional 
lineedit / KUrlSelector with delimiting slashes, a (blinking) cursor etc.

* when the UrlNavigator looses the focus, the content returns to the 
breadcrumb mode. no undo icon, ever.

objections, opinions, additions or comments anyone?

Regards,
thanks for reading until here.
you can stop reading now.

Thomas




More information about the kde-core-devel mailing list