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

overlay behaviour #169

Open
devvythelopper opened this issue Jul 31, 2024 · 3 comments
Open

overlay behaviour #169

devvythelopper opened this issue Jul 31, 2024 · 3 comments

Comments

@devvythelopper
Copy link

devvythelopper commented Jul 31, 2024

First of all, the switcher is a great piece of software!

One thing that is unintuitive is, is its overlay behaviour:

  1. I have no way of closing the switcher with the mouse.
  2. I cannot click on some window to activate it, while the switcher is open (but maybe this is after all desirable, because see point 3)
  3. I cannot use my on-screen keyboard while the switcher is open

I realize this is a bit tricky to implement, but to make the switcher usable on my tablet, allowing the on-screen keyboard is a must. And of course there should be a close button, that I can tap on with my touchscreen.

@daniellandau
Copy link
Owner

Clicking on a row with the mouse activates it and closes the switcher. It used to be that clicking anywhere else closes the switcher, but the way I had implemented it stopped working with a shell release some time ago and I couldn't figure out a new way to make it work.

On-screen keyboard I hadn't even thought about, I'll see what I can do about that.

@devvythelopper
Copy link
Author

devvythelopper commented Aug 7, 2024

I tend to open and close the switcher a lot, using the esc key. Because I open it, but then I realize I want to stay with the current app, or using the app switcher and jump back to the last used app is faster. So I think the CANCEL action definitely deserves its gui equivalent (maybe a little x at the right end of the switcher bar).

Maybe you could implement the switcher as a normal window (without decorations of course). And when that window looses focus, this means the user has clicked elsewhere. This would also make keyboard shortcuts work that open the quick settings menu or open apps.

On-screen keyboards tend to be implemented so that they do not make other windows loose focus. And even if the onscreen keyboard makes the window switcher loose focus, you could have a short (and maybe configurable timeout) until you close the switcher window.

@devvythelopper
Copy link
Author

And once you have all that you might want to bring your extension to the gnome core developer's attention. Because all this is something that deserves integrating in the core shell ;-)

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