This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
We have big problems (=many bugs) with this in Debugger Window. We use our special layout for managing TopComponents in it. But there is no support fot it in OpenIDE so our implementation is one BIG HACK. We we would like to be platform we should really support somethink like this.
Yes, in ideal world every mode should be able to define its own layout for laying out components that belongs to it. Bigger changes in winsys are needed to accomplish this task, it's doable no sooner then in 4.0 timeframe.
Passing to winsys guys.
Please provide the links to concrete Debugger window problems. I don't think one should be able to change the layout of container (i.e. mode), if it would be possible any module could change it and what the result would be? Yes winsys should improve its layout capability, and offer better use of it, but that's another issue (e.g. issue #20227). Why don't you use jus one TopComponent, passing it to winsys. That TopComponet you can treat as container (it is) set your special layout, and put your TopComponents in it. Do you miss then some features from winsys, for the "inner" TopComponents (like Registry or something else)?
This issue is not about Debugger Window, not about debugger, not about IDE. NetBeans is platfom. So we NEED absolute freedom to define custom layout for custom windows. Current system is not usable for many purposes. Moreover current system is very bad even for IDE itself. For example if you would like to create Outlook like application build on NetBeans you will fall to big problems. I think that if 20227 can be P1 nad NB4.0, this issue must be P0!
To be more concrete, I see several possibilities how to do this: 1) havind some possibility how to define special layout for my Mode. 2) support docking TopComponents to other TopComponent - in this case I have problem that inner TopComponent is hidden for OpenIde and "unmanaged". I have mainly problems with TopComponent.getActivatedNodes(), componentActivated(), and docking / undocking. 3) Third possibility is: - activated nodes can be managed by ExplorerPanel without TopComponent mediation - open Docking actions so I can completely redefine theirs functionality, or define some DockingActionContainer?!?
I prefer solution 1: a) Either to be able to define any layout for mode. b) Or support not only our own PerimeterLayout (SplitContainerImpl). It is less general than previous but easier. Reason is that put also tabbed pane to layout not top component itself and we must be able to select proper top component when tab is clicked. Solution 2: As said above we need not only layout but also container managing top component selection if other area than top component itself gains focus.
Solution also depends on future desktop architecture. ui is preparing specification.
Passing to new owner
could this be solved/made obsolete by the introduction of multiview APIs?
I'm closing this as obsolete, I believe mentioned issues are solved now - after winsys rewrite, it's now possible to define really complex and free window placement through declarative xml API, outlook-like UI is easy to reach, we have basic support for multiviews... We could enhance winsys more, but only in specified areas with well known use-cases. IMO TopComponent has to be non-recursive, TopComponent that would support recursive inclusion is unmaintainable and moreover not needed anymore.