Skip to content

Conversation

@NamorNiradnug
Copy link
Collaborator

Fixes #177

Tbh, I have no idea how and why it works.

@NamorNiradnug NamorNiradnug force-pushed the autohide-volue-after-scrolling branch from 5fa09d5 to 827c268 Compare August 5, 2023 10:22
@NamorNiradnug NamorNiradnug force-pushed the autohide-volue-after-scrolling branch from 827c268 to 35585c3 Compare September 24, 2023 22:39
@ammen99
Copy link
Member

ammen99 commented Sep 26, 2023

Sounds as if the actual problem is that the timeout in line 107 is not actually set, because the popup grabs input .. Do we actually ever want the popup to stay forever on screen and grab the keyboard? I'd say the popup should always auto-hide after a configurable timeout and never grab the keyboard.

Currently, it grabs the keyboard so that clicking on another view will auto-close the popup (which is actually broken in recent times, I am starting to work on that) - but that won't be a problem at all if we always auto-close after, say, 2 seconds of inactivity.

@NamorNiradnug
Copy link
Collaborator Author

Sounds as if the actual problem is that the timeout in line 107 is not actually set, because the popup grabs input .. Do we actually ever want the popup to stay forever on screen and grab the keyboard? I'd say the popup should always auto-hide after a configurable timeout and never grab the keyboard.

Currently, it grabs the keyboard so that clicking on another view will auto-close the popup (which is actually broken in recent times, I am starting to work on that) - but that won't be a problem at all if we always auto-close after, say, 2 seconds of inactivity.

Sounds like a good feature, but I think it should autohide faster after changing volume level via scrolling or pressing keyboard button because 2 seconds (or whatever, it obviously should be configurable) it too much to simply see the current volume level.

@ammen99
Copy link
Member

ammen99 commented Sep 28, 2023

Sounds as if the actual problem is that the timeout in line 107 is not actually set, because the popup grabs input .. Do we actually ever want the popup to stay forever on screen and grab the keyboard? I'd say the popup should always auto-hide after a configurable timeout and never grab the keyboard.
Currently, it grabs the keyboard so that clicking on another view will auto-close the popup (which is actually broken in recent times, I am starting to work on that) - but that won't be a problem at all if we always auto-close after, say, 2 seconds of inactivity.

Sounds like a good feature, but I think it should autohide faster after changing volume level via scrolling or pressing keyboard button because 2 seconds (or whatever, it obviously should be configurable) it too much to simply see the current volume level.

A configuration option sounds good ;)

@ammen99
Copy link
Member

ammen99 commented Nov 4, 2025

Seems like the original issue has been fixed somewhere on the way to gtk4, or do you still experience it?

@NamorNiradnug
Copy link
Collaborator Author

Seems like the issue is already closed and the patch is irrelevant.

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

Successfully merging this pull request may close these issues.

volume icon slider doesn't disappear

2 participants