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.
important impl decisions and requests: - use recursively contained JSplitPane or not? (affect performance) - specification of weights needed - configurability of splitters needed - drag gestures for DnD? - include use of TopComponentContainer.Area somehow? Or move area to this layout as its part? - ability to decorate currently selected item?
Target milestone was changed from '3.4' to TBD.
This is I think very important feature. Passing to UI to make spec. Focus especially on first three points (in the first comment).
I think that this RFE goes to the wrong direction. Current winsys default layout is cumbersome. And you would like to make it more complicated now 8((( I think that we need to open our winsys and allow users to define custom layouts for window. See #21217, please.
I guess you point out the main current problem. And it is too restrictive layout of winsys containers. It allow just to position the TopComponents in certain positions (top, botton, left, right, center). And that there is a desire to make the laying out of the components more general. Currently we need to figure out the solution, so there is no wrong way now. Is really your problem, that you cannot use your special layout, or is it just that you cannot layout the TopComponents some way current win sys doesn't support? (E.g. to have the 4 TopComponents above). I guess the second is that real problem. So using some more general layout (e.g. like it is GridbagLauot) could be the solution. Well, ideal solution is if win sys is generic enough so you can set any layout to its container. I think the bbig problem of this appoach is how winsys would then save and restore such layout? It seems to be not so easilly possible to me, but I could be wrong about this statement.
I think it is already clear the new layout will be made from splitted panes. It needs to be described ASAP, to be able to find out and solve more specific problems dealing with it.
Because Window System v1 will not be supported from now by our team, all old winsys issues (now "core/window system v1" issues) are going to be closed as WONTFIX. Changes in API which emerged both from UI spec and problems with adjusting to the older API are described in the document http://core.netbeans.org/windowsystem/changes.html. It shows also recommends how the client code should be adjusted to the new window system. If you think this issue apply also to the new winsys then change the subcomponent (to "core/window system") and REOPEN it.
issue doesn't apply to new window system - verified