CSSTUDIO-1335: Erratic movement of the OPI widget area on select

[cjenkscybercom]

[Copied from Jira Issue]

When selecting widgets that are close to a left side of the OPI area, the widgets get scrolled away from the user in an undesired manner. Why is it necessary to have such movement allowed?

[cjenkscybercom]

In investigating this @kasemir , I'm wondering if/how this can be changed to e.g. slow down scroll speed.

In AutoScrollHandler#createAndStartTimeline, for example, changing the KeyFrame delay or the rate doesn't affect the speed of the scroll. But, there's a lot going on in other parts of DisplayEditor that also fuss with the Scrollpane -- and while I'd think possibly creating a skin that lets us set the unit or block increment/decrement might be another way to approach this I'm not confident that would affect scroll speed either? (e.g. https://stackoverflow.com/questions/56739913/how-to-increase-scrolling-speed-of-scrollpane-javafx)

It's all a bit complex given my "greener" experience with JavaFX, and assuming this is an issue that should be solved I wonder what kind of approaches might make sense (if there are any at all).

[kasemir]

I didn't introduce the autoscrollhandler. It was an ESS contribution, https://github.com/kasemir/org.csstudio.display.builder/blame/master/org.csstudio.display.builder.editor/src/org/csstudio/display/builder/editor/util/AutoScrollHandler.java, which I've carried over to phoebus and tried to keep it running, https://github.com/ControlSystemStudio/phoebus/blame/master/app/display/editor/src/main/java/org/csstudio/display/builder/editor/util/AutoScrollHandler.java

Most of the time, I find it not helpful. Especially when you're running the GUI via remote X-ssh or thinlinc and there's some slowdown, the auto-scolling will use up even more resources and the display just scrolls away from where you want it to be without any chance to stop it.

I'd be fine with having an option to disable it or even completely remove it.

[cjenkscybercom]

Hmm...If I completely disable or remove it in DisplayEditor, I still see the same behavior

[kasemir]

What if you change the Tracker or the TrackerListener that receives the updates to limit the X, Y to be >= 0?

[cjenkscybercom]

Howdy! Sorry for the delay, been sick. Tracker isn't triggered at all when dragging with the mouse; it's only triggered when selecting a widget and dragging one of the handles (which is bounded to x < 0 and y < 0 as expected). I'm gonna pull out the big guns and setup some Debug class/method name filters/patterns...

[cjenkscybercom]

Unfortunately I'm not getting anywhere with that method either; stuff like ImageCache gets called up far too often and isn't being excluded like I expect in the class filters.

[cjenkscybercom]

Looking around haphazardly for uses of "drag", I did finally find it is in the RubberBand class for e.g. "rubberband" type selection 🎉

[kasemir]

Looks good, thanks!