Improve refactoring preview divider handling and tree navigation.

[mbien]

• scroll only vertically on prev/next navigation
• reset divider only if left panel is below minimal size
• share divider location memory between refactoring views

fixes #8068

[matthiasblaesing]

Actually I don't really see a difference, but also no problem, so from my POV ok to go in if it helps. Apart from the inline comment, I would raise the question, whether it would be possible to persist the divider location into options as is done for search results.

[mbien]

Actually I don't really see a difference, but also no problem, so from my POV ok to go in if it helps

Try this:

• run find-usages on something which has many results (like println())
• if the left view doesn't have a horizontal scrollbar yet, move the divider until you see one
• use next/prev button to navigate between results

NB <= 24 will move the horizontal scrollbar, with this PR applied the view is moved to the left and kept there on selection change.

I think allowing the tree to scroll horizontally on selection change is fine as default case for trees, but in this particular case it isn't very helpful. The tree is often shallow and the whole row is selectable, so locking it to the left makes sense I believe. (suggestion taken from the linked issue and mailing list)

I would raise the question, whether it would be possible to persist the divider location into options as is done for search results.

The divider memory is a bit of an afterthought, I didn't implement it at first. The reason for this is because this is essentially management code for many different refactoring views. It would have to persist it on a per-view-type manner. I am also not sure if there is even a good default or initial value. I think it is very usecase dependent and might not make sense to persist.

However, if the user runs a refactoring preview with slider position X, the second time it is run might look good with the same position from before since it is probably the same codebase. So maybe in-memory persistence is good enough / potentially better anyway?

This might look patchy but the way it is implemented:

        if (splitPane.getDividerLocation() < MIN_DIVIDER_LOCATION) {
            if (dividerPosMemory > MIN_DIVIDER_LOCATION) {
                splitPane.setDividerLocation(dividerPosMemory);
            } else {
                splitPane.setDividerLocation(0.3);
            }
        }

means that the whole logic won't be active if the concrete view is setting a width via regular layout logic - this would already move the divider at this point and the whole thing is skipped.

But maybe I am overthinking this.

[matthiasblaesing]

Lets keep this as is. With the comment I can see the difference. Thank you