Bug 135385 - add attachTopComponentToSide method to WindowManager
add attachTopComponentToSide method to WindowManager
Status: NEW
Product: platform
Classification: Unclassified
Component: Window System
6.x
All All
: P3 with 1 vote (vote)
: TBD
Assigned To: Stanislav Aubrecht
issues@platform
: API, API_REVIEW_FAST
Depends on:
Blocks: 179047
  Show dependency treegraph
 
Reported: 2008-05-19 21:44 UTC by ailinykh
Modified: 2011-11-28 18:55 UTC (History)
6 users (show)

See Also:
Issue Type: TASK
:


Attachments
diff file (2.15 KB, text/plain)
2008-05-19 21:46 UTC, ailinykh
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ailinykh 2008-05-19 21:44:16 UTC
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);
     }
Comment 1 ailinykh 2008-05-19 21:46:06 UTC
Created attachment 61588 [details]
diff file
Comment 2 David Simonek 2008-05-20 14:51:50 UTC
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.

Comment 3 ailinykh 2008-05-20 16:15:59 UTC
>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?
Comment 4 err 2008-05-28 04:10:33 UTC
>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.)
Comment 5 beaubert 2009-08-14 19:14:06 UTC
+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
Comment 6 err 2009-08-14 19:22:04 UTC
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.
Comment 7 err 2011-05-18 00:56:13 UTC
I've filed Bug 198657 which would handle this. I will take a look at your diff file.
Comment 8 Jesse Glick 2011-11-28 18:10:08 UTC
Forgotten?
Comment 9 err 2011-11-28 18:55:57 UTC
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


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