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.
Currently we can split editor area only by drag and drop. This path allows to do that through API. One new abstract method of WindowManager is introduced: public abstract void attachTopComponentToSide(TopComponent tc, Mode attachMode, String side); WindowManagerImpl has simple implementation: public void attachTopComponentToSide(TopComponent tc, Mode attachMode, String side) { central.attachTopComponentsToSide(new TopComponent[] {tc}, (ModeImpl)attachMode, side); }
Created attachment 61588 [details] diff file
Reassigning to API reviews. Thanks for the patch, but I have several comments, as each API change needs to be justified properly and carefully to avoid mistakes: 1) Why is this new API needed? What are real use cases? Is it needed for app written on top of the platform, or for some module to do tricks with window layout? Note that window layout generally should chang only per end user's request. Automatic window shuffling can puzzle the user. 2) DummyWindowManager impl should do something or perhaps no operation, but it shouldn't throw an exception. Note that DummyWindowManager is often used in unit tests. 3) I don't like the signature of new method. attachTopComponentToSide says nothing about editor split. Why is there Mode parameter to attach to, when you want to split editor only? I suggest something like public void splitEditor (TopComponent tc, String side) 4) Where are string constants for "side" parameter defined? They are becoming part of API as well so it needs to be documented. 5) Such addition needs to be documented in API changes of openide module.
>1) Why is this new API needed? What are real use cases? Is it needed for app written on top of the platform, or for some >module to do tricks with window layout? Note that window layout generally should chang only per end user's request. >Automatic window shuffling can puzzle the user. We are creating application on top of the platform. There are two scenarios when we need that functionality: 1. Users always open several files (3-5) and want all of them on the top. Right now they do the same annoying thing: open file - drag and drop, open another file- drag and drop. 2. They often switch from one set of file to another (pretty much like open/close project in Netbeans). If you open project, split editor mode and then close project you loose your layout. Next time you have to drag and drop each topcomponent again. In other words editor layout is not persistent. I mean open/close project, not IDE itself! >2) DummyWindowManager impl should do something or perhaps no operation, but it shouldn't throw an exception. Note that >DummyWindowManager is often used in unit tests. That method could be empty. >3) I don't like the signature of new method. attachTopComponentToSide says nothing about editor split. Why is there Mode >parameter to attach to, when you want to split editor only? >I suggest something like >public void splitEditor (TopComponent tc, String side) Actually the current implementation of WindowManager (WindowManagerImpl) has that method, but it is not exposed, because package org.netbeans.core.windows is private. I just made this method public by coping it to WindowManager (which is abstract class). That method actually can split any top component, not editor only. So, probably public void splitTopComponent(TopComponent tc, String side) ? >4) Where are string constants for "side" parameter defined? They are becoming part of API as well so it needs to be documented. They are defined in org.netbeans.core.windows.Constants { ... /** Sides of attaching, used both for regular modes and sliding modes */ public static final String TOP = JSplitPane.TOP; public static final String BOTTOM = JSplitPane.BOTTOM; public static final String LEFT = JSplitPane.LEFT; public static final String RIGHT = JSplitPane.RIGHT; ... } that class is in the same private package. It looks like we have to move them to WindowManager or remove them at all and use directly JSplitPane. 5) Such addition needs to be documented in API changes of openide module. Where is it? What file?
>1) Why is this new API needed? What are real use cases? I maintain the jVi plugin. There are a variety of vim commands that do horizontal and vertical editor window splits. Its on my TODO list to implement these as possible for NB. (BTW, several of these commands are implemented on the old JBuilder port of jVi). So it looks like, acc'd to this bug, there are currently no APIs for this. In addition to simply splitting an editor window, there are vim behavior and command to set/adjust the size of split edit windows. Is there an API to get the appropriate split pane, given an editor? If not, that might be part of this API addition. (I suppose in the absence of an API you could traverse upwards from the TC looking for JSplitPane; but that seems potentially flakey. For example, if considering only editors, don't want a non-editor.)
+1 the possibility to split the editor window (vertically, horizontally) and switch between splitted views with keyboard shortcuts could be an awesome enhancement for both netbeans and jvi
FWIW, jVi on NB supports vim's '^W^W' which changes focus to the next visible editor. so you can manually do the split then switch between visible editors with the shortcut.
I've filed Bug 198657 which would handle this. I will take a look at your diff file.
Forgotten?
This can be done with reflection. Using reflection, jVi now implements vim's window split, move, resize commands. The resize, and setting the initial size, is a real kludge; it's awkward and has visual artifacts. It would be great if - A friend only interface to manipulate things. - Some a way to resize modes from the data-state/top-half. jVi access the bottom-half as though user did the resize with GUI, and this updates the top half. - Some way for the window system to advertise what capabilities it had. Need this since there is no guarantee that there could be mulitple editor modes. There's notes/discussion on some of this in Bug 198657
Long time open. What is the status? Implemented or won'tfix?
I have increased the priority to P2 defect to demand a resolution of this long term opened API change request. Feel free to close as won'tfix.
(In reply to Jaroslav Tulach from comment #11) > I have increased the priority to P2 defect to demand a resolution of this > long term opened API change request. That's what issue comments are for.
You don't understand. Either drive the API request to conclusion, or close it. Or stop treating it as a request for review. Having hundered of open API requests that nobody cares about makes it harder for people to find the ones that are live and important. Closing as won'tfix for you.