Revision as of 13:41, 28 February 2012 by Psomol (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)

Date: 28 FEB 2012 Author: Petr Somol, Ralph Ruijs, Jesse Glick


Problem / Motivation

Open in New Tab option allowing to choose between reusing whole window area and auto-creation of tabs
With Open in New Tab checked, a new tab is created inside host window to accomodate new output
With Open in New Tab unchecked, each new output replaces the previous one (alternatively appends to the previous if applicable) to fill completely the host window area

Inconsistencies have been identified in internal tab creation behavior inside windows that by default reside under the main editor area (Search Results, Usages, Output...).

  • Bugzilla issue 208638 points out that Find Usages reuses the Usages window by default, although before 7.1 it produced new tab under the Usages window for each find. Other similar windows, however, follow a different convention.
  • the Output Window hides the tab row when there is just one tab, which is very useful in terms of saving vertical space (especially on modern wide displays); but other windows such as Test Results do not do so. This is in part because there is no general infrastructure in the NB window system for managing tabs/subwindows, so it is left to each implementing module to handle this individually. (Note that there is one module which provides the Output Window and manages its tabs generally, but a lot of modules which create tabs in it and write the specific contents and add specific toolbar buttons.)
  • Some keyboard shortcuts may seem illogical. Ctrl-PageUp/Dn cycles over the considered windows (Output, Search Results, ...) but when a window with Sub-Tabs is reached, then cycling gets restricted to the sub-tabs only without the option to reach the next window. Ctrl-F4 seems to duplicate Ctrl-W in closing a window, although there seems to be no keyboard shortcut to close a sub-tab.

It is clear that consistency can and should be improved with respect to tab creation support inside these windows. The option to reuse window/tab area instead of creation of new sub-tabs should be more generally available. Conversely, it should be possible to exclude certain areas from automatic reuse (e.g., to keep selected search or Find Usages results). Vertical screen space can be used more economically if single-sub-tabs are prevented.

Remark: However, any changes must be done with caution as the variety of the dockable windows and their purposes is such that "one solution may not fit all".

Current Behavior of Windows in Question

(Please add other cases not listed)

Search Results

Each search creates new tab. There is no way to request tab reuse.


Each Find Usages call by default reuses the whole area of the Usages window. Tab creation can be requested by a checkbox Open in New Tab in Find Usages dialog. The checkbox state is persistent across sessions. The default value is unchecked.


Complicated. Each IDE feature which writes to the Output Window has its own logic for handling reuse (if any); there is no system for reusing tabs across features.

Ant Builds

By default, reuses its area whenever possible (repeated builds, repeated runs, runs + tests). Creates tabs when necessary for parallel builds. But user may uncheck "Reuse Output Tabs from Finished Processes" in Ant settings.

Maven Builds

Like Ant's default behavior, reuses tabs from finished builds.

XML Validation



Reuses tabs per checkout (VCS root).

Test Results

Reuses tab per project.

New tab for results from a Hudson build.


Database and Java EE servers, ...?

Refactor - Inspect and Transform...

First call uses the whole Refactor window area, subsequent calls open tabs. Reuse can not be requested. Note that it multiple Inspect and Transform.. sessions open at once may be actually incorrect - please review.

Proposal Areas of Concern

Consistency in Single Sub-Tab Display

Question: should all considered windows display single sub-tabs or should all stay tab-less until the second sub-tab is created ?

Proposal: To save vertical space (esp. with the current proliferance of wide-screen LCDs) it is preferable, if there is no other concern, for the considered windows to stay tab-less until more than one content needs to be displayed, at which moment the original content is moved to first sub-tab and other content is displayed in additional sub-tabs.


  • save vertical space (esp. with the current proliferance of wide-screen LCDs)

Consistency in Re-Use Possibility

Question: Should all considered windows permit content area/tab re-use ?

Proposal: Yes, re-use should be made generally possible to reduce visual clutter (growing number of sub-tabs is often inconvenient). Typically this would be commanded by the Open in New Tab checkbox in caller dialog as is the case of Find Usages. Changing the checkbox state would change the behavior persistently. TBD where such UI would be for tabs opened from some UI gesture which is not the OK or Finish button in a dialog or wizard: builds, XML validation, etc. However, if "pinning" is implemented (see below), then re-use can be used by default in these cases while the user would still have the option to preserve a tab of choice.

Remark: If the user disables Open in New Tab while already having sub-tabs opened, then next output is redirected to re-use the last focused tab.


  • reduces visual clutter (growing number of sub-tabs may be inconvenient)
  • option to keep working with the keyboard, user needs to use a mouse to close tabs in some cases

Consistency in Default Re-Use Policy

Question: Should all considered windows by default re-use existing content area/tabs or should they by default create new tabs ? Currently this behavior is inconsistent.

Answer: The inconsistency was actually designed with the user's needs in mind, which isn't really that big of a deal. As long as we've considered that some windows lend themselves to always being replaced and others need the flexibility of being opened in new tabs, based on usage patterns and gut instinct, it is not sure we need to augment the IDE or standardize on anything. It should be also remarked that consistency in this aspect would be contraproductive in both possible cases: a) if re-use was the default behavior, then the whole tabbing functionality could remain undiscovered by users. However, tabbing had been added after numerous user requests. b) if re-use was disabled by default, i.e., Open in New Tab was in all relevant cases to true, then space would be senselessly wasted in many cases (e.g., there is no need to have separate tabs for separate Builds etc)

Content/Tab "Pinning" (Re-Use Prevention)

Some users suggest adding a "Pin" action to Tabs (invokable through keyboard shortcut + context menu item), that would prevent the respective Tab from being erased or reused. Use case 1: it is important sometimes when user prepared Find Usages query and then start to refactor code and it's impossible to "refresh" Fins Usages without lost of information, due to not yet compilable code. Use case 2: or user want to keep results of one slow "Find", while reuse other tabs for Finds and safe space. However, question is whether it is more useful or confusing.

Proposal: "pinning" should be made possible. A "pinned" tab would never be re-used regardless of current re-use policy setting. A "pinned" tab would be visually marked (see below). The "pin" action would be invocable through context menu and shortcut. The "Pin" action would be applicable to Tab or Sub-tab. In case of invocation on Tab without Sub-tabs, contents would be first moved to a Sub-tab and that Sub-tab would be marked as pinned (to restrict pin marking to Sub-tabs only). Sub-tab tooltips should indicate "pinned" status, e.g., "Usages of buttonOK (Tab excluded from re-use). "Pinned" Sub-tab context menu should include Close All Non-Pinned Tabs action.

"Pinned" marking options:

  • pin icon - bad, consumes space, adds UI clutter
  • grayed tab title - suggests that tab is non-modifiable, but may also suggest "disabled" status, thus wrongly suggest tab contents are not navigable
  • italic tab title - ?
  • grayed italic tab title - preferable? as it says the same as grayed tab title but prevents confusion as of the disabled status
Illustration of a "pinned" sub-tab Usages of btn. Marked by grayed italic tab title.

Remark: non-existence of pin button/icon is not favorable from discoverability point of view, but preventing clutter is IMHO stronger argument. Note that there is more actions in context menu that may look undiscoverable.


  • gives user more control over which sub-tabs to keep and which not to keep (cf. use cases described above)

Proposed Behavior of Windows in Question, for NetBeans 7.2

Promote more widely the option to choose between auto-tab creation and window area reuse. This can be meaningfully accomplished in windows:

Search Results

Add to dialog Find in Projects the checkbox Open in New Tab. Changing the checkbox state would change the behavior persistently.

Modify the root of the tree that is generated as result of Find in Projects, so that the root text informs about what string has been searched for. This is to cover the case when no sub-tab header is displayed.


Remain as it is now in 7.1. (default state to be decided)

Other windows

(Please review all that may apply.)

Whenever possible, add the Open in New Tab option as suggested for Find in Projects. Changing the checkbox state would change the behavior persistently.

Not logged in. Log in, Register

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