Can we* prettyplease do something about the KUrlNavigator?

[Thomas Lübking]

On Thursday 18 June 2009 13:51:16 Maciej Pilichowski wrote:

@Maciej
please keep me or kcd in cc as i have not subscribed to kde-usability (so far 
at least)

> 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
> I agree, already reported.

great. i searched bugs.kde and the kde-usability archieves for kurlnavigator, 
but that was probably the wrong term :-(

> I don't see here a problem.
assume you click some random label and a pushbutton appeared... - personally i 
wouldn't do so.

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

> You mean the similarity (between icons) is a problem?
no. the fact that you get an undo button next to your path selecting lineedit 
(to undo the UI change...)
the undo button seems not connected to the UI but to the path.
the other thing is that you've a pushbutton on the left side (to select a 
default) and a toolbutton on the right side (to undo the UI) what i'd mark as 
"out of balance"

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

> Because...?
To avoid the visual change of the UI structure as consequence of clicking 
empty space. To indicate that this is an input area (especially if this shall 
ever be used w/o a fileview below).  Because a lineedit creates more 
attachment to the below iconview than some sort of label (though this might be 
conditioned) and for a better UI struture (though this might be a personal 
aestethic view)

>> * when hovering a text part,
>> --------------
>> ° the "link" get's underlined

>Within lineedit? There are already too much horizontal lines. Editbox 
>is self-explanatory (i.e. if you don't know how to use edit box, 
>better don't touch it).
The point is that at this very moment it's not a "normal" lineedit (they do 
not contain links) and the text item you might be about to click will actually 
trigger some action (just as a link)
I agree that underlining in a lineedit has visual problems. A solution could 
be to increase the listview margins (i.e. the whole thing is a little heigher 
- the Urlnavigator already is a little bigger than the contained lineedit)

The active state ("can be cliecked") of the text item (in the breadcrumb mode) 
however needs to be indicated somehow and the current solution looks out of 
place atm and would in a lineedit as well.

Regards,
Thomas