albert icon indicating copy to clipboard operation
albert copied to clipboard

[QBM/WBM] Full-screen overlay

Open joeytwiddle opened this issue 8 years ago • 13 comments

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:

albert_overlay_suggestion

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.)

joeytwiddle avatar Nov 11 '17 04:11 joeytwiddle

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

ManuelSchneid3r avatar Nov 12 '17 12:11 ManuelSchneid3r

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.

constant_size

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?

dagolap avatar Dec 08 '17 17:12 dagolap

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

ManuelSchneid3r avatar Dec 12 '17 12:12 ManuelSchneid3r

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.

dagolap avatar Dec 12 '17 12:12 dagolap

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.

Lenbok avatar Jan 23 '18 20:01 Lenbok

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: peek 2018-04-20 08-33

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. 👍

hangxingliu avatar Apr 20 '18 00:04 hangxingliu

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 avatar Apr 20 '18 14:04 ManuelSchneid3r

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

ManuelSchneid3r avatar Apr 20 '18 14:04 ManuelSchneid3r

where even if the window shrinks

Well actually it does not.

menu_001

ManuelSchneid3r avatar Apr 20 '18 14:04 ManuelSchneid3r

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.

stale[bot] avatar Nov 05 '20 03:11 stale[bot]

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

ManuelSchneid3r avatar Nov 05 '20 07:11 ManuelSchneid3r

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.

idkCpp avatar Dec 05 '20 10:12 idkCpp

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.

bloerwald avatar Sep 09 '21 09:09 bloerwald