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.
org.openide.windows.TopComponent.Mode Just ideas, not to lose sleep over: - List of modes in the Explorer, reorderable, renamable, etc. I guess this was planned anyway. - Idea for mode type: "follow", which would display one TopComponent in a multi-split-pane window, with each pane having a scrollport of a portion of the component (might need to be cloneable??). The scrolling areas would be kept in synch, they would always follow one another. For example, look at Emacs `M-x follow-mode` then `M-x follow-delete-other-windows-and-split`, very very useful. - Replace static TopComponent.createMode with (nonstatic) TopComponent.Mode.createMode, which would create a new mode to be displayed inside the one called on. So for example, you could have multitabs inside multitabs, or more usefully multitabs inside an MDI docking mode. Current behavior would be obtained by TopComponent.SINGLE.createMode().
Priority is changed to P4 (normal).
x
Please evaluate - close WONTFIX if needed.
I think there are some plans especially with the "multi-split-pane" window. Depends on UI which I guess prepares some spec to this Passing to Jano to evaluate from UI perspective, please.
Adjust then target milestone.
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.
All right, leaving open just for the "follow mode" idea, which anyway I think Tim was working on a prototype of.
I played with this a bit again the other day. It's actually a surprisingly difficult problem. The painting part is easy: ---------------- | | | | | | | | x | | | | ---------------- The problem is, when the caret is blinking at x, getting RepaintManager (which will think the invalidated area is in the coordinate system of the real component and not on screen) to actually repaint it. Two options: 1. Do something similar to JViewport, with an offscreen buffer and the real component parented to a CellRendererPane or something such that always returns true from isShowing. 2. Create a hacked wrapper graphics object that wraps the real one, and re-maps coordinates. BTW, you can't do this by implementing your own weird AffineTransform - I tried it. The challenge in the graphics wrapper object is any draw operations you have to do across the page boundary - they have to get turned into two calls, etc. None of it hard code to write, just lots of boring boilerplate. The graphics solution probably is the better one; JScrollPane went through lots of revisions for performance, and we'd have similar problems with a double-buffered solution (though it's much easier to write). A custom repaint manager would also do the trick, but that would be global, so possibly not a great idea. Could maybe do it with a custom repaint manager that delegates to the default one unless there is a multi-pane ancestor. I'm still thinking there's some easy and obvious way to do this that's eluding me.
It's possible to split a document in 7.4
That merely splits the window, but is not equivalent to M-x follow-mode: it does not keep the viewports synchronized. BTW a buglet for split mode: the editor toolbar appears on the right pane (when splitting horizontally) even when View » Show Editor Toolbar is unchecked. Also BTW: there is no obvious keyboard shortcut for jumping to the other side of the split.