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.

Bug 2336 - Permit "follow mode" for document windows
Summary: Permit "follow mode" for document windows
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: All All
: P4 normal (vote)
Assignee: Stanislav Aubrecht
Keywords: UI
Depends on:
Reported: 1999-06-27 00:39 UTC by Jesse Glick
Modified: 2013-09-10 16:17 UTC (History)
2 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 1999-06-27 00:39:56 UTC

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().
Comment 1 Marek Grummich 2000-07-25 09:24:59 UTC
Priority is changed to P4 (normal).
Comment 2 Jesse Glick 2002-02-14 19:10:43 UTC
Comment 3 Jesse Glick 2002-02-14 19:11:46 UTC
Please evaluate - close WONTFIX if needed.
Comment 4 Peter Zavadsky 2002-07-23 16:36:27 UTC
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.
Comment 5 Peter Zavadsky 2002-07-24 09:27:29 UTC
Adjust then target milestone.
Comment 6 Marian Mirilovic 2003-11-26 12:59:43 UTC
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

Changes in API which emerged both from UI spec 
and problems with adjusting to the older API are described in the document
 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.
Comment 7 Jesse Glick 2003-11-26 15:36:32 UTC
All right, leaving open just for the "follow mode" idea, which anyway
I think Tim was working on a prototype of.
Comment 8 _ tboudreau 2003-11-26 21:50:47 UTC
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

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.
Comment 9 Stanislav Aubrecht 2013-09-05 08:40:12 UTC
It's possible to split a document in 7.4
Comment 10 Jesse Glick 2013-09-10 16:17:06 UTC
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.