Can we* prettyplease do something about the KUrlNavigator?

[Peter Penz]

Hi Thomas,

On Thursday, 18. June 2009 00:09:18 Thomas Lübking 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

Originally I did not intend to reply, as I like to discuss such details 
without terms like "sucks", "period", "worst part". Especially when we should 
work together to improve some things, this is no good start...

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

Generally if something is as broken as you indicate by your mail below, we get 
a lot of bug reports at bugs.kde.org or endless discussions at 
usability at kde.org This is not the case here, so the chances are good that we 
did not create a "usability monster" at all ;-)

This does not mean that there is no room for improvement (for sure there is), 
but let's discuss this objective...

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

As Matthew already replied: that's a bug.

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

I agree that the visual feedback can be improved here.

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

OK. Please note that the default line edit offers a lot of functionality 
regarding text completion, which is used by people out there (I know this from 
feedback at bugs.kde.org). No matter what you intend to do with the breadcrumb 
mode, the default line editor functionality must remain.

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

It would be no big problem to turn off this icon and I'm fine with removing 
it.

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

Assuming we don't remove the button completely as you suggest: Which icon do 
you suggest?

>
> i want to chage this /in general/
>
> proposal:
> -----------
>
> 1st
> the look should please *not* be entirely changed between "breadcrumb" and
> lineedit mode

Please be aware that the breadcrumb mode per default shows a simplified URL, 
while in the edit mode the full URL will be shown. E. g.

breadcrumb:
Pictures > 2009 > June

edit mode:
file://home/jeff/Documents/Pictures/2009/June

I don't intend to change this default behavior during the KDE 4.x cycle. So no 
matter which colors etc. you use for the breadcrumb, the main problem will be 
to provide a smooth transition from "Pictures > 2009 > June" to 
"file://home/jeff/Documents/Pictures/2009/June"

>
> 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/

I object at this point. I don't like to change the look of the breadcrumb view 
to a lineedit-look (= white background etc.) The breadcrumb mode and the 
editable mode are modes with a different behavior and should be visually 
distinguishable too.

What can be improved IMO is how the switching between the modes is done.

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

This is a no brainer and I'm fine with this.

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

Please don't forget that there is a different content in the breadcrumb mode 
and the line edit mode -> just underlining and changing colors is not 
enough... 

>
> (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?

I'm open to:
- find a better alternative to the "undo" button
- to improve the visual feedback when hovering the empty area in the 
breadcrumb mode to indicate that an editing is possible

I object against taking away any functionality that has been offered since KDE 
4.0 (e. g. like that the URL navigator shows shortened path per default).

Regards,
Peter

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