toolbar icons
Samuel S.
smls75 at gmail.com
Thu Aug 13 14:29:45 UTC 2009
> > But would it be possible to make the context line configurable like the
> > normal toolbars? I don't need the next/prev context buttons nor that
> > enable/disable source browse mode (what does that even do?!).
> Because those are not simple actions, but special widgets. And together
they
> make up a whole panel that is embedded as one single widget, thus you
cannot
> remove actions from it. And I think that does make sense, as the buttons
> should have exactly this order, and not some random order the way the user
has
> inserted them into the toolbar.
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?
> 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).
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.
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).
Oh, and sorry for intruding into this discussion as a non-developer, I hope
you don't mind... ;-)
PS: While I'm here, I might just as well comment on the actual main topic of
this discussion:
I'm personally not a great fan of the "text under icons" mode, but to be
honest I must say I find
http://www.apaku.de/vardata/kdev4_initial_icontext_noarea.png (by Andreas)
the best option posted so far for being used as the default toolbar layout.
Regards,
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090813/a3632853/attachment.html>
More information about the KDevelop-devel
mailing list