Auto-hide editor scrollbars #829
Conversation
Prior to this, `editor.xcode.like.scrollbar` would render a black rectangle instead of error stripes. This change makes error stripes panel ignore registry option. It is always rendered and responds to events.
|
@nvartolomei thanks, will check it out. |
|
Thank you for the fix. I'm testing it locally, but I do not want to push it into master as is. |
|
@SergeyMalenkov old behaviour is? For me
To me that looked like a bug/abandoned feature, so I came up with this patch which hides editor scrollbar handle (thumb) only when this registry entry is set to true. When |
|
@SergeyMalenkov I agree with @nvartolomei, the option is experimental and we should fix the original behavior, there's nothing to discuss with UI team. |
| @@ -581,8 +575,7 @@ protected boolean isDark() { | |||
|
|
|||
| @Override | |||
| protected boolean alwaysPaintThumb() { | |||
| if (scrollbar.getOrientation() == Adjustable.VERTICAL) return !(xcodeLikeScrollbar() && EditorUtil.isRealFileEditor(myEditor)); | |||
| return super.alwaysPaintThumb(); | |||
| return true; | |||
There was a problem hiding this comment.
It is suspicious. Why it returns true, that mean always paint thumb?
There was a problem hiding this comment.
This method is inside MyErrorPanel, to have event listeners bound, this method should return true.
From what I understand it is only used in code editor and only in vertical context, so scrollbar.getOrientation() == Adjustable.VERTICAL always evaluates to true, so it always returns result of return !(xcodeLikeScrollbar() && EditorUtil.isRealFileEditor(myEditor));.
Under default behaviour xcodeLikeScrollbar() evaluates to false, condition is short-circuited and negated, so it returns true.
Under editor.xcode.like.scrollbar=true this would return false and hide MyErrorPanel, disabling mouse event handlers when thumb is hidden by logic from the parent class that implements OS X scrollbar hiding behaviour.
In the case of this patch, I decided to always render MyErrorPanel thumb (which is actually invisible) and have mouse event handlers active, you can see this in action in the demo video linked in PR description where I hover cursor on error stripes.
tl;dr: alwaysPaintThumb returns whether or not to render invisible thumb for error stripes, which under all conditions should be true
Is there a case when this is not desired?
There was a problem hiding this comment.
The scrollbar (actual scrollbar) handle logic is correct and respects registry entry is located in ButtonlessScrollBarUI.java.
|
@nvartolomei I mean 2 scenarios for scroll thumb in editor:
@ignatov We should discuss which behaviour should be used by default, at least. |
|
@SergeyMalenkov I think you misinterpreted the code a bit. Re-compile with this patch applied and test both cases ( |
|
Sorry. Seems that patch was applied incorrectly first time. Or full rebuild helped... |
) * Consider navigation element in PSI equality checks This seems to solve issues related to psi becoming outdated. Extension of comment by ajchun: mplushnikov/lombok-intellij-plugin#840 (comment) Covers issues: #821, #827, #829, #840, #842, #844, #846, #850, #853, #854, #855, #857 * Remove debug logging related to equality of PsiElements GitOrigin-RevId: e9ad9801b15dc91b872b14add012a9261033fbc7
The root issue was fixed in IntelliJ core, see: https://youtrack.jetbrains.com/issue/IDEA-248146 #829 #840 GitOrigin-RevId: 5693b4348b4ba41599885e0b5b8ef0e152f81cfe
Since
editor.xcode.like.scrollbarseems broken, I decided to make few changes to make it at least somewhat usable.Demo https://youtu.be/ro2A7EzjrB0 with
editor.xcode.like.scrollbarenabled after change.cc @ignatov (based on git blame)