> > But would it be possible to make the context line configurable like the<br>
> > normal toolbars? I don't need the next/prev context buttons nor that<br>
> > enable/disable source browse mode (what does that even do?!).<br>
> Because those are not simple actions, but special widgets. And together they<br>

> make up a whole panel that is embedded as one single widget, thus you cannot<br>

remove actions from it. And I think that does make sense, as the buttons<br>

should have exactly this order, and not some random order the way the user has<br>

inserted them into the <span class="il">toolbar</span>.<br><br>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?<br>
<br>> I think merging the lines is not a good thing, as both lines do different<br>> 
things. The one at right is actually more a dropdown-list than a line-edit,<br>
> because it always shows the function you're in, and can be used to select<br>> other functions in the file.<br>
<br>> Merging them in some way to get both behaviors at once would mean creating a<br>> clumsy UI, by combining things that do not necessarily belong together.<br><br>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.<br>
These additional features of the two separate widgets don't really contradict each other, so merging them would not technically be a problem.<br><br>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).<br>
<br>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.<br>
<br>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).<br>
<br>Oh, and sorry for intruding into this discussion as a non-developer, I hope you don't mind... ;-)<br><br>PS: While I'm here, I might just as well comment on the actual main topic of this discussion:<br>I'm personally not a great fan of the "text under icons" mode, but to be honest I must say I find <a href="http://www.apaku.de/vardata/kdev4_initial_icontext_noarea.png">http://www.apaku.de/vardata/kdev4_initial_icontext_noarea.png</a> (by Andreas) the best option posted so far for being used as the default toolbar layout.<br>
<br>Regards,<br><br>  Sam<br>