Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-extending autohide panel/dock doesn't open unless over the panel #159

Open
ryanabx opened this issue May 1, 2024 · 3 comments
Open

Comments

@ryanabx
Copy link
Contributor

ryanabx commented May 1, 2024

Not sure if this should be intended behavior or not.

I believe it makes it easier to access autohide panels simply by activating when the mouse reaches the edge of whatever side it's on.

2024-04-30.20-27-17.mp4
@wash2
Copy link
Collaborator

wash2 commented May 1, 2024

Not sure if this should be intended behavior or not.

Ya, this is intended behavior. Panels that aren't extended avoid absorbing input except over the actual rectangle of the layer surface that has applets. Personally, I like it this way because it helps avoid activating or persisting the panel when I don't mean to. but I'm open to changing it if it's a better experience for other people. I think it is a bit awkward if the pointer is over another application but inadvertently interacting with an invisible portion of the open dock or panel though.

@ryanabx
Copy link
Contributor Author

ryanabx commented May 1, 2024

Ya, this is intended behavior. Panels that aren't extended avoid absorbing input except over the actual rectangle of the layer surface that has applets.

Oh yeah, aside from this issue, there's another issue related to the layer surface -- with the panel moving back down if you move the cursor to the bottom edge while the panel is up (#149) I was going to look at it myself but the panel code is still an ongoing mystery to me

Personally, I like it this way because it helps avoid activating or persisting the panel when I don't mean to. but I'm open to changing it if it's a better experience for other people. I think it is a bit awkward if the pointer is over another application but inadvertently interacting with an invisible portion of the open dock or panel though.

Understandable, it might be more suitable having the whole bottom edge act as a trigger for opening the panel but not the area above it for keeping it open -- so you'd have to move the mouse to the panel anyways to keep it open, no invisible hitboxes. Having a solid trigger on the bottom edge might also fix the layer surface issue mentioned above, because my guess as to what triggers it is that the layer surface doesn't fully extend to the very bottom edge of the screen

@wash2
Copy link
Collaborator

wash2 commented May 1, 2024

Having a solid trigger on the bottom edge might also fix the layer surface issue mentioned above

Maybe but the panel can really only receive input in layer surface. It could create a thin strip at the bottom when it is configured for autohide that is always included as an input region, and create a region for the entire extent of its surface when at least partially hidden. It probably wouldn't fix the issue you mentioned above though. I'll have to look into that issue a bit more. It would probably have to adjust the input region depending on whether or not it is currently transitioning to hidden or visible if partially hidden.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants