Consider this setup (C/C++ environment):
* 10 open files:
- 8 C files
- One Makefile
- One text file
* Developer navigates/edits a bit here and there in these files
* Developer is currently in a C file, it shows a toolbar with the navigation
drop-down to the left, followed by Back and Forward buttons, etc.
* Developer clicks Back a few times, thus eventually traversing back through files
* Developer ends up in either the text or Makefile
* Now the placement of the back button is changed due to the disappearance of
the navigation drop-down on the left of the toolbar
* The developer, having his/her attention strictly on the text and not the
toolbar, is now surprised to find that the next click happens to hit Previous
Bookmark and not Back.
Thus we arrive at this enhancement proposal:
* Editor Toolbar UI items that are common across file types must remain in the
same UI position.
One way of achieving this, perhaps, was to sub-divide the toolbar into
"mini-toolbars" that the user could position, same way as "real" toolbars?
I can see the problem, but I am not sure how making toolbars adjustable would
help solving it. Do you expect users to rearrange toolbars for all file types
they are working with? If so, should not editor toolbars be arrange in some
other way by default? If so, in what way?
The guiding principle, IMHO, should be to let "things that do the same thing
stay the same place" in the GUI.
Looking at the C/C++ toolbar, the only thing C/C++-specific there is the
Navigator drop-down. Everything else is constant across file types (as far as I
can tell, anyway).
So, why not simply split that toolbar into two, and re-order it a bit:
<constant stuff> | <file-type specific stuff>
In other words, put the Navigator at the end? That's flexible space with room to
grow should other things be needed in the future, and the unchanged things in
the UI don't "jump". But this may go against another idea "put the most
important things first", although what's important is clearly an individual
Building the toolbar from sub-toolbars means that I, as a user, can re-arrange
it to my liking, at the cost of, perhaps, a less visually pleasing UI in some
cases. Assume this imagined example (view in fixed font):
File type Default toolbar
.foo Navigator | Back, Forward, FindNext, ...
.bar Navigator, Transmogrify, Rot13 | Back, Forward, ...
.baz Back, Forward, ...
As can be seen, the toolbar can jump. But if the user can re-position the
sub-toolbars, the effect I desire can be obtained.
Navigator | Back, Forward, FindNext, ...
Navigator, Transmogrify, Rot13 | Back, Forward, ...
| Back, Forward, ...
I hope I've been clear and that you'll consider it for the future. It won't kill
NetBeans if it's not included, but I think it would make NetBeans nicer still.
This is also a problem for files that use the multiview editor, such as web.xml etc.