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.
Summary: | Permit "follow mode" for document windows | ||
---|---|---|---|
Product: | platform | Reporter: | Jesse Glick <jglick> |
Component: | Window System | Assignee: | Stanislav Aubrecht <saubrecht> |
Status: | REOPENED --- | ||
Severity: | normal | CC: | anebuzelsky, tboudreau |
Priority: | P4 | Keywords: | UI |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
Jesse Glick
1999-06-27 00:39:56 UTC
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. |