Bug 182091 - A better NetBeans menu bar
A better NetBeans menu bar
Status: NEW
Product: ide
Classification: Unclassified
Component: UI
6.x
All All
: P4 with 2 votes (vote)
: 7.0
Assigned To: issues@ide
issues@ide
issue_reviewed
: NETFIX
Depends on:
Blocks: 209259
  Show dependency treegraph
 
Reported: 2010-03-16 09:38 UTC by dynamite
Modified: 2013-09-04 13:46 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dynamite 2010-03-16 09:38:38 UTC
The blog article http://blogs.sun.com/jglick/entry/a_better_netbeans_menu_bar showed a way to put items from the main toolbar into the IDE's menu.  The motivation was that only a few toolbar items are ever used and that space can be saved if those were moved to the menu which has to be there.  This was noted as being particularly valuable when using a laptop.

I request that this be added as a feature of the IDE that the user can enable.  Perhaps the view menu could include an entry that would somehow trigger a "minimal" view mode that would hide the toolbars and populate the menu.  Ideally there would be some means to also customize what ended up in the menu bar.

I am a member of NetFIX 6.9 [1] as if this is seen as possibly suitable for a NetFIXer then I would be willing to try and implement this.  Is it possible? [1] http://wiki.netbeans.org/NetFIX
Comment 1 Jesse Glick 2010-03-16 15:12:13 UTC
Should not be technically very difficult, but the UI to set it up could be contentious. NB used to have the ability to fully customize menus and toolbars, but this was not well maintained (especially alongside changes in how actions were defined and registered) and it was finally dropped from the UI - leaving only the ability to customize keyboard shortcuts.

The most natural UI would I guess be to drag-and-drop toolbars directly into the menu bar. However you could not then get the Garbage Collect button on its own, only in conjunction with Run-Time Watches and Snapshot. Gnome allows panel icons to be moved after F7 which could be a natural model.
Comment 2 dynamite 2010-03-16 18:41:18 UTC
I think my initial proposal would be to use the View->Toolbars menu.  Adding an "Enhance Menubar" option that would populate the menu bar with the GC and search.  This menu also has a "Customize..." item which opens a window that could be used to change the contents of the menu bar.

Is it however a problem if the contents of the menu can only be switched on and off rather than configured?  The more I think about it the less of a problem it seems to be.  People who use this will learn keyboard shortcuts and/or menu.
Comment 3 Jiri Kovalsky 2010-03-17 17:44:42 UTC
Ondro, what do you think about this proposal from the xDesign point of view? Do you agree with this little UI change provided it's turned off by default? Thanks for your opinion!
Comment 4 Ondrej Langr 2010-03-18 12:29:58 UTC
Being able to maximize viewable code area addresses an existing need and is a handful feature, indeed!

But why to introduce a new "hide toolbar" feature when we already have a mode which hides the toolbar and maximizes viewable area - full screen. Why don't we just move QuickSearch and Garbage collector to menu automatically when full screen is enabled?
Comment 5 Jesse Glick 2010-03-19 18:02:56 UTC
Well, Alt-Shift-Enter has other effects as well, such as hiding window decorations and the system status bar, which may or may not be desirable. Whereas the area to the right of the Help menu is _always_ wasted, so it costs nothing to keep Memory and Quick Search there all the time, if (like me) you are a keyboard user and have no use for other toolbar buttons.
Comment 6 dynamite 2010-03-20 10:59:08 UTC
The maximal view is also temporary: when I close all my open files I automatically go back to the normal view.

Vertical space is often more valuable than horizontal space.  Code lines are often quite short and long expressions typically go over many lines.  I often scroll up and down, but rarely left and right.

The more lines of code I can see though the better and that means freeing space vertically in the window.  The toolbar is full of things that I do through other means, either with a keyboard shortcut or through a context menu.
Comment 7 Ondrej Langr 2010-03-22 15:09:48 UTC
> Whereas the area to the right of the Help menu is _always_ wasted, 
> so it costs nothing to keep Memory and Quick Search there all the
> time, if (like me) you are a keyboard user and have no use for 
> other toolbar buttons.

Makes sense. So how about the following: 

1) It would be possible to merge toolbar into menu for people (such as Jesse) who are keyboard based and want to get rid of it permanently. (UI - probably drag&drop from customize dialog to menu together with an info message in the customize dialog to allow users to discover this). 

2) In full-screen mode, toolbar would be merged with the menu automatically (and temporarily, until this mode is switched back to normal). This will allow access to toolbar in the maximized mode, which is currently not possible.
Comment 8 Jiri Kovalsky 2010-03-22 20:57:18 UTC
I for one like this solution. How about others?
Comment 9 Jesse Glick 2010-03-22 21:40:02 UTC
(In reply to comment #7)
> In full-screen mode, toolbar would be merged with the menu [...to] allow
> access to toolbar in the maximized mode, which is currently not possible.

Which toolbars would be merged with the menu? Bear in mind that

1. There is limited space left in the menu bar at a typical screen resolution.

2. Memory Meter and Quick Search are the only toolbar controls that I know of which have any value in being visible to a keyboard user. Everything else is a simple action presenter: i.e. a button which conveys no information and can simply be clicked on. These can be run just as easily from accelerators where available, or menu mnemonics where not. Whereas Memory Meter displays an ongoing chart; and Quick Search must be displayed as a text field for you to enter a search phrase. The only other toolbar control I can think of which has a complex presenter is Set Project Configuration, but this functionality is also easily accessible from the Run menu.
Comment 10 dynamite 2010-03-22 23:35:05 UTC
Full-screen mode is most often a temporary thing in my experience: I have a file with an unusual number of long lines and it is convenient to minimise the amount of scrolling that I have to do.  I trigger this mode only when necessary because it hides context (output  and project windows etc), which is part of the point of the mode.  I think that the menu bar is best left alone in full-screen mode.

The simplest approach is to let the user choose to use the menu bar as a toolbar if they wish by letting it be a drag-n-drop target.  If the user doesn't want anything in their menu bar, they don't need to drag to it.  It's their choice.

To enable convenient setting up of a minimal configuration of no toolbars with some use of the menu bar we can provide a menu item to enable/disable viewing of the toolbars.  This mode would be different from full-screen mode because it only affects the toolbars and is persistent.
Comment 11 Ondrej Langr 2010-03-23 13:59:33 UTC
> Which toolbars would be merged with the menu? 

I was speaking in the context of the original blogpost referenced from here, i.e. I only meant QuickSearch and Memory meter. And .. since memory meter is essentially a tool for NetBeans developers (irrelevant to vast majority of users) this basically only applies to QuickSearch. 

> 1. There is limited space left in the menu bar at a typical screen resolution.

Agreed. However, this is a concern even for this customization as originally suggested in this issue. And can be solved by displaying the appropriate menu fields (i.e. QuickSearch in fullscreen mode and others if customized) only if there is enough space in the menu bar.

> To enable convenient setting up of a minimal configuration of no toolbars
> with some use of the menu bar we can provide a menu item to enable/disable 
> viewing of the toolbars.  This mode would be different from full-screen 
> mode because it only affects the toolbars and is persistent.

I'm not sure if I understand. Is something like "Hide toolbar" item in View->Toolbars what you are suggesting here? If so, I don't consider it important since you can simply turn off all toolbar sections, but I don't have any objections either. The only thing I'm requesting in addition to that is moving the only item left (Quicksearch) unaccessible without toolbar into menu bar automatically in fullscreen mode. This is so that users who need to effectively use the screen-estate can only switch to full-screen and would have all standard IDE functionality accessible *in some way* without having to play around with toolbar configuration.
Comment 12 dynamite 2010-03-23 18:41:22 UTC
Okay what about:

1. Full-screen mode hides toolbar (as it does now), but additionally puts the quick search into the menu bar if the menu bar has only menu items in it.

2. Allow drag-'n'-drop from the toolbar configuration to the menubar as well as the toolbars.

3. Add a "Hide toolbars" item to View->Toolbars which would hide all the toolbars and put the quick search into the menu toolbar.

4. Add "Run with..." item to the project context menu to run a project with a different configuration than that currently set in the project properties.
Comment 13 Ondrej Langr 2010-03-25 13:06:53 UTC
> 1. Full-screen mode hides toolbar (as it does now), but additionally puts
> the quick search into the menu bar if the menu bar has only menu items in it.

Agreed. 

> 2. Allow drag-'n'-drop from the toolbar configuration to the menubar as
> well as the toolbars.

Agreed. 

> 3. Add a "Hide toolbars" item to View->Toolbars which would hide all the
> toolbars and put the quick search into the menu toolbar.

This would basically duplicate functionality of full-screen. I see no point in having two modes, which would hide toolbar and move quicksearch to the menu bar, each accessible from other place in the UI. Let's KISS (keep it simple and stupid). 

> 4. Add "Run with..." item to the project context menu to run a project 
> with a different configuration than that currently set in the project 
> properties.

How did this come up here? :-). It's out-of-scope for this issue + it already is possible to run a configuration in both "Run" and project contextual menus. Please file a separate enhancement if you insist on this.
Comment 14 dynamite 2010-03-25 18:30:56 UTC
Is is okay for me to NetFIX[1] items 1 and 2?  [1] http://wiki.netbeans.org/NetFIX
Comment 15 Jiri Kovalsky 2010-03-26 14:19:08 UTC
Yes, you can. Ondrej will review & approve the UI and Jesse will review the patch & integrate it. Thanks!
Comment 16 Jesse Glick 2010-03-26 14:55:27 UTC
Note that we are past feature freeze for 6.9.
Comment 17 Jiri Kovalsky 2010-03-26 18:23:24 UTC
Yes, the code would be integrated to trunk after release69 clone is created.
Comment 18 Jiri Kovalsky 2010-04-26 18:36:57 UTC
Forgot to mark with NETFIX keuword.
Comment 19 Jiri Kovalsky 2012-07-18 16:50:15 UTC
Daniel is no longer working on this issue. Resetting to default assignee.
Comment 20 Stanislav Aubrecht 2013-04-23 09:58:16 UTC
QuickSearch already does show in menu bar, there's 'Set Configuration' item in project's context menu, it is possible to show memory meter in status bar (http://plugins.netbeans.org/plugin/48517/?show=true) - lowering priority.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo