Hi Mitch,
depends. This is a hard problem to solve, since it might be the right
behavior in some cases, but not in others.
example: ctrl-z will move the view to the change, in some situations
this is very useful and exactly what is expected from the IDE, in other
cases (e.g reverting automatically added imports) the IDE shouldn't
distract by scrolling to the top of the file.
N views at once make that even more interesting. There are certainly
ways to improve this but I don't think there is a single/obvious way how
it should behave - it is somewhat context dependent.
two more examples of scrolling related issues:
- the output window stops scrolling as soon an exception is printed,
this is a feature in 90% of all cases and super annoying in 10% of all
cases, e.g if you dump stack traces in your log
- clicking a link in a scrolled pane did center that link - which was
removed in NB 20 (last minute #6679) since that was annoying when a user
clicked through a stack trace for example which made the view move
slightly on every click.
maybe we should add a scroll-lock button or something like that
-mbien
On 06.12.23 16:47, Mitch Claborn wrote:
Editing a Java class. I'm creating a new version of a method in that
class and want the old version in a separate window for reference. I
clone the current window then float it and scroll to the old version
of the method in the floated window and put that window on a different
monitor.
When I make changes in the same file in the main NB window the floated
window doesn't stay where it was, but scrolls to where I'm making
edits in the main window.
Is that the expected behavior?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
