[QBM/WBM] Full-screen overlay

[joeytwiddle]

Why? I use Fluxbox with the window focus mode: Mouse Focus (strict). That means whenever my mouse is over a window for more than 300 milliseconds, that window will be focused and raised to the front.

As a result, if my mouse is hovering over Albert, but then I type and Albert shrinks due to filtering, and now my mouse is hovering over the window behind Albert, then that window will gain keyboard focus!

So admittedly this is my fault for using Fluxbox's strict focus mode. But anyway, here are two ways that Albert could avoid that problem:

1. Create a full-screen overlay behind Albert. If my mouse is not directly on the Albert list, it would be on Albert's overlay instead, so at least it won't focus the window behind Albert.

2. Or, never shrink Albert's size: When the results list shortens, just leave a blank area.

Solution number 1 comes with a bonus feature: This overlay could also be used to darken everything on screen except for Albert, for those users who want to emphasise Albert as a modal. Conceptually, this is probably the same as just having a huge shadow. Here is an artist's impression:

Any additional behaviour should be optional, because some users want Albert to keep working how it does now.

(My current version: albert=0.11.1-1~webupd8~trusty0 from this ppa on Ubuntu 14.04. It is not easy to get the latest version compiled on this OS.)

[ManuelSchneid3r]

Well thats intended. The mouse wheel has to work for other windows. Btw update with the correct official repos

[dagolap]

I'm interested in this as well. I have made a PoC for myself with the same logic as the second proposal above. It definitely makes the experience better when using Focus follows mouse.

My current PoC-implementation implements is two-fold:

• A theme that sets static height of the results list.
• An option that when disabled no longer calls hide() in ResizingList::updateAppearance().

For a proper solution I'm thinking the simplest way might be to just disable the hide()/show()-mechanism entirely and make sure it takes no space with 0 results by default. This way it's just a matter of creating a theme file for it for those who want this feature.

Another solution could be to make this an option, and then size the list according to maxItems - this would make it a useful feature for anyone not able to create a custom style as well. I haven't tried this myself, but I imagine it could be done by changing ResizingList::sizeHint() or similar?

@ManuelSchneid3r: Would you be interested in a pull request for this? And if so, do you have any preferences on implementation details?

[ManuelSchneid3r]

Why dont you just disable hide-on-focus-out when using sloppy focus?

[dagolap]

For me the problem is not Albert hiding, but rather some other application suddenly getting focus as the result list shrinks (strict, instant focus follows mouse). This happens every now and again when the mouse is - by chance - placed where the results list of Albert will be.

When the list shrinks as the number of results are reduced the the background app will get focus, and further search refinement and launch action will not be received by albert until I manually move the mouse into the Albert window.

For this scenario any kind of theme or mechanism to make the window static in size should solve the problems.

[Lenbok]

I'm also finding this Albert behaviour quite problematic. I'm coming from synapse, where even if the window shrinks so that the mouse is no longer over the launcher, synapse maintains the focus. I don't know how synapse does it, but it seems functionally equivalent to the full-screen overlay proposal.

[hangxingliu]

I met same problem after I set gnome focus-mode to sloppy (Because I need switch focus between difference monitors quickly but not after a mouse click).

And set hide-on-focus-out to false could not fix this problem because although Albert window still in here but I could not type any text for Albert.

It looks like:

And I have try set window size to static (or auto increase size but don't decrease), It's fine. But there will be a big area without content but has ugly white background under the QLineEdit.

So I think overlay is a good idea for fix this problem, and I hope it will become a option into Albert. 👍

[ManuelSchneid3r]

Guys, some frank words now: I will not bend albert to fit every weird env it will run in.

There are reasons for the full screen overlay (shadow, general bg, open gl flicker bug) but none of them will be visual transparent but opaque for mouse events. This problem is not with albert. It is with sloppy focus. What you are complaining about is a natural implication of the sloppy focus. Thats why sloppy focus is crap (personal opinion).

There is a major users base against you: Those who want the mouswheel to work while albert is visible and/or be able to focus another window and expect albert to implicitly hide.

However there is a solution for sloppy focus users: You could develop a new fullscreen frontend. Especially with QML its not that much work.

[ManuelSchneid3r]

Offtopic: may I ask which font this is in your editor?

[ManuelSchneid3r]

where even if the window shrinks

Well actually it does not.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ManuelSchneid3r]

If you could find out how I regions of the window transparent for mouse clicks I'd happily implement this for you.

[idkCpp]

I vote to reopen this issue. It is a valid request. (Also I have this problem :D)

Maybe the overlay does not need to be mouse-click-transparent... Like context menus are also not click-transparent when clicked elsewhere. They just close and you have to reclick what you wanted to click anyway.

[bloerwald]

I had a variation of this issue on Ubuntu with sloppy focus: When opening albert while not having the mouse where it appears, it will lose focus, even without moving the mouse. I agree it should happen when moving the mouse, but this annoyed me.

The workaround here appears to be to disable org.gnome.shell.overrides.focus-change-on-pointer-rest. With that setting disabled, albert will keep focus until you actually touch the mouse.

[qadzek]

I also experience this issue. I am using the setting Window focus mode: Mouse in Cinnamon.

I will limit the number of displayed items in Albert, to minimize the chance of this occurring.

[ManuelSchneid3r]

I will limit the number of displayed items in Albert, to minimize the chance of this occurring.

does this make sense? :D

i never got the point of sloppy focus, but well. i see there is a need.

[qadzek]

Hi @ManuelSchneid3r, first of all, thanks a lot for this amazing launcher!

I will limit the number of displayed items in Albert, to minimize the chance of this occurring.

does this make sense? :D

Yeah, this was just a silly workaround I was attempting. It's a bit annoying when I am typing a word in Albert, Albert shrinks and then I am suddenly typing in another window. I would prefer not to disable sloppy focus. I guess for now I will try to keep my mouse away from the center of the screen when using Albert.

[agvxov]

@joeytwiddle
@dagolap
@Lenbok
@hangxingliu
@idkCpp
@bloerwald
@qadzek
I have created a patch: https://github.com/agvxov/plugins/tree/dev
However, before submitting a PR, I would like to make sure it's bugless. I'm hoping that I could get a few souls to beta test it.

You can install it by following the official from source guide: https://albertlauncher.github.io/setup/ ; With the only modification that you replace the original plugins folder with my repo cloned recursively
It uses the widgetsboxmodel frontend and must be enabled from the options to take effect.

Any feedback is appreciated.

[qadzek]

@agvxov Thanks for reaching out. I no longer use Albert, since I switched to Rofi because of this very issue. Hopefully a current user is willing to give your patch a try.

[dagolap]

@agvxov My situation is much the same as @qadzek - I'm currently using the launcher from Plasma.

If I find some available time I might give it a try, but I'm rather swamped these days so unfortunately no promises.