UEXTabReuse

(Difference between revisions)
(Test Results)
Line 1: Line 1:
-
Date: 23 FEB 2012
+
Date: 28 FEB 2012
-
Author: Petr Somol, Ralph Ruijs
+
Author: Petr Somol, Ralph Ruijs, Jesse Glick
== Motivation ==
== Motivation ==
Line 10: Line 10:
[[File:Tabreuse2.png|200px|thumb|right|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]]
[[File:Tabreuse2.png|200px|thumb|right|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]]
-
An inconsistency has been identified in internal tab creation behavior inside windows that by default reside under the main editor area (Search Results, Usages, Output...). Bugzilla issue [http://netbeans.org/bugzilla/show_bug.cgi?id=208638 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. To summarize (please add other cases not listed):
+
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 [http://netbeans.org/bugzilla/show_bug.cgi?id=208638 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.)
 +
 
 +
Current behavior of the respective windows (please add other cases not listed):
====Search Results====
====Search Results====
Line 88: Line 94:
# If the user disables Open in New Tab while already having tabs opened, then the output is redirected to reuse the last focused tab.
# If the user disables Open in New Tab while already having tabs opened, then the output is redirected to reuse the last focused tab.
-
----
+
== Open Problems / Alternative Suggestions ==
-
(comments to be reflected in the proposal above)
+
-
 
+
-
''Comment by Vladimir V.'':
+
-
 
+
-
Even in case of 'reuse' mode => each tab still can be set as "sticked" which prevents it from reusing:
+
-
* 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.
+
-
* or user want to keep results of one slow "Find", while reuse other tabs for Finds and safe space
+
-
 
+
-
In fact with general support from window system, approach can be simplified to the following:
+
-
* In case of global "reuse" make visible "pin" pressing on which file became non-reusable.
+
-
* In case of global "no reuse" always create new tab.
+
-
 
+
-
''Comment by Jarda H.'':
+
-
What about adding action like "Pin" (or "Keep") to Output Window Tab context menu?
+
* some users suggest adding a "Pin" action to Tabs (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.
-
It could be used generally whenever users want to prevent a particular output from being erased and reused.
+
-
Question is whether it is more useful or confusing.
+
* There is admittedly a difference in which windows typically should allow for new tabs and which shouldn't (i.e. should always be replaced?)?  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, I'm not so sure we need to augment the IDE or standardize on anything.

Revision as of 10:42, 28 February 2012

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

Contents

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.)

Current behavior of the respective windows (please add other cases not listed):

Search Results

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

Usages

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.

Output

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.

VCS

Reuses tabs per checkout (VCS root).

Test Results

Reuses tab per project.

New tab for results from a Hudson build.

Others

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.

Problem

It is clear that consistency can and should be improved with respect to tab creation inside these windows. However, it is also clear that this must be done with caution as the variety of windows is such that "one solution may not fit all".

Proposed Solution

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.

Usages

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.

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.

Pros

  • option to save vertical space, valuable with the current proliferance of wide-screen LCDs
  • option to keep working with the keyboard, user needs to use a mouse to close tabs in some cases
    • though Output Window tabs can be closed via KB: Ctrl-4 to focus, Ctrl-PageUp/Dn to cycle, Ctrl-F4 to close
  • consistency

Cons

  • users not aware of Open in New Tab control may get confused, because tab creation is generally expected

Remarks

  1. With respect to possible user confusion it should be considered whether to set Open in New Tab in all relevant cases to true. This would result in default behavior being the same as before.
  2. If the user disables Open in New Tab while already having tabs opened, then the output is redirected to reuse the last focused tab.

Open Problems / Alternative Suggestions

  • some users suggest adding a "Pin" action to Tabs (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.
  • There is admittedly a difference in which windows typically should allow for new tabs and which shouldn't (i.e. should always be replaced?)? 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, I'm not so sure we need to augment the IDE or standardize on anything.
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