Geertjan's Blog

  • October 13, 2011

Window System in 7.1

Geertjan Wielenga
Product Manager

Trying to build up a complete list of all the enhancements in the NetBeans window system in 7.1.

  • Roles. There's support for roles/perspectives/profiles in NetBeans Platform 7.1, for the first time, as I wrote earlier in this blog. That's good news, now window layouts can be stored/retrieved per user. What's less good news is that this is limited to the window system, i.e., would have been nice to have had the entire file system be available on a per-user basis, e.g., some Actions are relevant to Admin users, while others aren't. Though other solutions exist in the NetBeans Platform for solving this scenario, it would have been nice if it had been included in the "roles" enhancement.

  • Modes. New mode "topSlidingSide", i.e., that lets you minimize a TopComponent above the window display area, in addition to the existing "leftSlidingSide", "rightSlidingSide", and "bottomSlidingSide", and you can drag and drop TopComponents into that area, as done below for the Projects window, Services window, and Files window:

  • Groups. For TopComponents found in the same "view" mode—e.g., in the "explorer" mode, which is a "view" mode, you have "Projects window", "Files window", and "Services window", as shown below—there are now new menu items, available when you click to the right of the TopComponent tabs, for manipulating the group as one unit:


    Above, you can see that a number of menu items are disabled, since they do not relate to the current context, which is group behavior, since we didn't select a specific TopComponent but, rather, to the right of the tabs of the TopComponents, i.e., in the brand new "group tab area". So, above, the "Move" action is disabled, since it would only make sense when a single TopComponent is selected, rather than a group, as shown below:

    Above, the majority of the menu items are enabled, since here we right-clicked on an individual TopComponent's tab, rather than to the right of the tabs, in the brand new "group tab area", which is what the earlier screenshot showed.

    So, that's the new behavior for "view" modes. Modes of kind "editor" are different, they've always had different behavior to "view" modes. E.g., TopComponents in "view" modes can be minimized, while TopComponents in "editor" modes can be cloned. That's logical functionality, i.e., it makes no sense to clone (i.e., create a splitter) for the Projects window, while split pane functionality for editor documents is something that is often needed.

    You can see new behavior above for TopComponents in "editor" modes, too. (There's always only one "editor" mode, as far as I am aware, by the way, with multiple editor documents docked within it.) You can now create separated "Document Tab Groups", which then have behavior dedicated to the group, such as the ability for the documents within the tab group to be floated out of the main frame of the application together.

    In the same way as there is a new "group tab area" to the right of TopComponent tabs in "view" modes, there is also such an area to the right of the tabs of TopComponents in "editor" modes.

    Something that's interesting, and possibly unintentional, is that you can now, for the first time, drag TopComponents from "view" modes into "editor" modes, and vice versa:

  • Tools. When you create a new TopComponent via the Window wizard, you'll see a new button to the right of the "Window Position" drop-down, letting you create your own new mode or customize one of those that already exist. Another entry point into the same functionality is the new "Layout of Windows" template in the New File dialog. I blogged earlier about this new template here.

  • Terminology. The term "undock" is replaced by "float". So, where in the past you would dock/undock a TopComponent from the main window, you now dock/float a TopComponent or a group of TopComponents from the main window. Another new term is "Document Tab Group".

A related enhancement is the pluggability of multiview components, though that relates to a completely different API. So, above you see all the window system enhancements of which I am personally aware. Probably there are a few others, hoping I'll be enlightened about these soon.

Join the discussion

Comments ( 4 )
  • stan Friday, October 14, 2011

    the platform also supports group operations (float/undock) for a group of editor windows. you can turn that on using branding.

  • Jesse Glick Friday, October 14, 2011

    Even with a general solution for making particular layer entries available only for certain user classes, special support for roles in @TopComponent.Registration would still be needed. This is because the window system is not "layer-clean", to coin a phrase.

    In the old window system (3.5 and earlier if I recall correctly), mode/component/etc. definitions were in the Windows/ folder in layers, and changes were persisted to $userdir/config/Windows/ just like any other system filesystem modifications. There were ongoing reliability and performance problems related to module enablement and disablement with this implementation, which relied on DataObject and InstanceCookie and so on - events would get fired in unpredictable orders and mishandled in various ways.

    When the window system was rewritten in 3.6 and included a new persistence API and implementation (now defined in Windows2/), the Datasystems dependency was eliminated, and the state/event management was overhauled to not use the usual listener patterns, but rather to just load and store the whole window system at specific times; as part of this, the user's window layout was persisted to Windows2Local/ in the user directory, i.e. intentionally separating the layer-defined defaults from the current layout. (Whether the state management could have made quick and reliable while maintaining the usual system filesystem semantics, I do not know - only the original authors of the change could explain.)

    Because of this scheme, I doubt that simply switching certain definitions under Windows2/ on and off in the read-only section of the system filesystem would actually work. The window system has to explicitly be prepared for role switches.

    To my knowledge, other portions of Platform infrastructure remain layer-clean, i.e. will react naturally to changes in the system filesystem regardless of their origin: inserted or removed static (XML) layers; changes to dynamic layers (Lookup.getDefault().lookupAll(FileSystem.class)); changes in $userdir/config/. This includes menu, toolbar, and shortcut registrations of actions (*), Options panels, palette items, MIME resolvers, DataObject context menus, templates, help sets, Services tab entries, and probably much more. Even Modules/*.xml changes will result in changes to module state, though this must be used with care lest you trigger a feedback loop!

    (*) The keymap customizer added a few years ago (6.0+?) makes no attempt to adjust existing Shortcuts/ and Keymap/NetBeans/ folders, but rather copies the current settings into a fresh keymap. But the infrastructure still ought to react to changes in existing keymaps coming from other sources.

  • Chandan Singh Nagarkoti Friday, October 14, 2011

    its really great for the programmers

  • guest Tuesday, December 10, 2013

    Hi Geertjan,

    I'm using Netbeans IDE 7.4. When I float multiple windows they always adding as tabs. Is there any way to apply the mode(explorer, edit, output) to a floating window same as the main window?



Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.