toolbar icons

[David Nolden]

Am Donnerstag 13 August 2009 16:29:45 schrieb Samuel S.:
> The previous/next buttons certainly are special controls relating directly
> to the line edit - but why put the "source browse mode" action in here like
> this? From a user's point of view, it's a normal toolbar action just like
> any other, and should have text under/next to it if the other toolbar
> actions do, and you should be able to remove it independently or drag it
> anywhere you want on the toolbar. Or am I missing something here?
That is not a normal click-once action, but it is a 'switch' when 
enables/disables the mode, and the button also shows whether the mode is 
currently active or not through keyboard (CTRL or ALT key). So probably this 
could only be done using a custom widget, which would make it nearly the same 
thing it is now.

> > I think merging the lines is not a good thing, as both lines do different
> > things. The one at right is actually more a dropdown-list than a
>
> line-edit,
>
> > because it always shows the function you're in, and can be used to select
> > other functions in the file.
> >
> > Merging them in some way to get both behaviors at once would mean
> > creating
>
> a
>
> > clumsy UI, by combining things that do not necessarily belong together.
>
> On the other hand, the functionality of the two does overlap: Both are used
> for navigating to functions in the current file. One has the added feature
> to always display the name of the function the cursor is currently in; the
> other has the ability to navigate outside of the current file and to jump
> to other logocal entities than just functions.
> These additional features of the two separate widgets don't really
> contradict each other, so merging them would not technically be a problem.
>
> Also, the fact that only one of the two line-edits presents a useful UI
> element at any given time might be taken as a reason for maybe merging
> them: When currently using quickopen navigation, the text in the
> context-browser line edit is meaningless as it's about to change. At all
> other times, the text in the quickopen line edit is meaningless (if not
> empty) as the context-browser line edit already reliably shows you the name
> of the current function. So if you look at it this way, around one third of
> the toolbar width is wasted at any point in time (taking Andreas's latest
> 1024x768 screenshot as a reference).
Both line edits always have a functionality, the same way a button has a 
functionality. Most of the time buttons just sit there, their main sense is 
you noticing them. If there wasn't the line-edit which contains "Quick 
Open...", that functionality would be hidden. There's already enough 'secrets' 
functionality in KDevelop, we shouldn't make it even more. ;-)

> I'm not saying the two should be merged just like that and everything will
> be great; I guess it will require some thinking (and maybe applying some
> innovative/unusual UI concepts) to make all the functionality currently
> covered by the two line-edits easily discoverable and easily accessible in
> one slick unified "quick navigation" widget. However, I don't think it
> would be impossible, and seeing as the problem of wasted toolbar space
> raised this whole discussion covered in this (rather long) thread, you
> should at least take it into consideration.
It will need some experimentation. But if the quickopen line was so small that 
it merely contains "Quick Open...", then it would not be a big loss anymore, 
it would be similar wide as one icon-with-text.

> Take the address bar in Firefox 3 as an example: Who would have thought
> that one slightly "jazzed up" line-edit could be used for showing the
> current location, navigating to any globally reachable location, as well as
> navigating within some well-defined set of locations (bookmarked and
> recently visited web pages in this case).
Sorry I'm not aware of that address bar it seems.. :)

Greetings, David