Can we* prettyplease do something about the KUrlNavigator?

[Thomas Lübking]

Am Friday 19 June 2009 schrieb James Richard Tyrer:

>Peter Penz has done excellent work here and I suggest that your tone
>could be taken as personal -- not a good thing.
I did not mean to attack any one in person. This widgets resides in kdelibs. 
If it s... "has rough edges" ;-) it's everyones fault - including and 
especially mine, as i kept these objections for months w/o doing anything 
about it.

[Edit] ============================

After proceeding in this mail i figured you're referring to a KDE3 variant of 
the UrlNavigator what may lead to an entirely different experience. Please 
keep that in mind when reading my responses (as they may seem as invalid to 
you as yours to me) and in doubt try a KDE4 version.

==================

> 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.
it's apparently and visually) more oriented to the mac pendent while 
KUrlNavigator clearly looks more like the vista solution (screenshots... i 
have never used it) and i better won't comment the usability (to me) of the 
Gtk+ widget - that would probably be /really/ insulting. (Luckily there's an 
additional ineedit below...)
However, i'm rather not interested in comparing this to anything, but just in 
improving the visual represrentation (as far as i can and think)

> > 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. 
look into Maciej's reply from Thursday, 16:01:31 - he seems to prefer it on 
the right side... and according to his mail from 15:51:16 the "appearing 
toolbutton issue" has been reported as well.
My main issue with the

> 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.
it's not an "oh - i feel confused because this is the first time" issue but 
rather a "this differs from every other UI element behavior" - clicking into 
empty space to "add" a UI element feels strange.

> 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.
The icon actually changes with the curent path if that is in the favorite 
list. (i.e. becomes a folder when you select a path that's contained in the 
favorites and has a folder icon, or no specific icon, and stays like this 
untill you select the next path that's contained in the favorites)

> I would suggest that
> an icon for Places be created and used instead.
Visually i'd suggest to not place too may icons there, as the whole area will 
look like an additiona toolbar of partial size then.

> > - 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.
And it does what? Undo the text change? No. It changes back the UI to the 
breadcrumb mode. Gotcha! (no offense, and sorry but i /could/ not resist....)

> > 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.
And that is pretty much why i want the breadcrumbs (which is a relatively new 
widget) to look closer to the "Editable Location" lineedit.

> 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).
I do not think that a long button list, flanked by two other buttons would 
make a very well widget to be placed below a toolbar and on top of a main 
window, but that's just my 2¢

> > -> 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.
The KUrlNavigator may be implemented on QAbstractButtons but their visually 
appearance does not match any other button (i.e. they do not use style 
functions to paint ToolButtons or PushButtons) - and imho that would not be a 
good idea either.
Take a look at Aurelién's mock - it's pretty close to what i intended.

> > 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.
It's part of the QComboBox, the appearance is Style dependent (try "dolphin --
style gtk" ...) and who actually said that a KUrlNavigator has to be a 
KUrlComboBox plus some toolbuttons? (especially as the reason to introduce the 
KUrlNavigator was (probably - i won't guess intentions) to replace the 
KUrlComboBox with sth. with extended functionality?
What's the point in keeping redundant information or UI elements then?

> > 4th
> > the undo button is the worst part (regarding the navigator) of them all.
> > it will however vanish because...
>
> I totally disagree here.
If you believe it undo's the lineedit change....

> IIUC, you want to combine the location widget and the breadcrumb widget.
>   This is an interesting idea.
In a way, yes. Not so much on the code layer, though.

> 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.
Nope, actually not.
As soon as the widget get's the input focus it behaves like a lineedit and 
displays the "correct" path (inc. slashes) - everything else was a problem as 
there's no "triangle" key on my keyboard and entering a slash to get a 
triangle would probably be a little too weird.

> 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.
well, in a way the KUrlNavigator already accepts text. As soon as it gets 
focus (including mmb by clicks to X11 paste) by clicking somewhere that's not 
a breadcrumb (and atm. looks like empty space) you can type.
I want a visual representation for this but agree that having text entries 
(the crumbs) that will not have the widget take focus when being clicked could 
lead to confusion.
Therefore a hover indication on text and arrows as well as a different cursor 
(e.g. pointing hand vs. I-beam) should stay. I will not judge whether this 
will be a sufficient indication.

> 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.
errr... KDE3 version? Do we discuss different versions and implementations, 
thus maybe even behavior here?

Sorry if i did not make that clear:
I am referring to the KDE4 version /only/ and have *NO* idea what the dolphin 
UrlNavigator looks and behaves like in KDE3 :-(


> > � the cursor changes to a pointing hand
> No, this is not consistent -- the cursor does not change when hovering
> buttons.
see above: it's not quite like a button at all.

> > � 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??
arrows yes (by QStyle), animation no (and probably not relevent since this is 
a small visual change and near look - gtk has such animated triangles but i 
can live w/o them ;-)

> [...]
for the rest i suggest you try the KDE4 version as we seem to discuss cross to 
each other (in fact i was about to ask you if you ever actually used the 
KUrlNavigator some lines above but resisted to be not offending ;-)

Thomas