micheleg / dash-to-dock

A dock for the Gnome Shell. This extension moves the dash out of the overview transforming it in a dock for an easier launching of applications and a faster switching between windows and desktops.
https://micheleg.github.io/dash-to-dock/
GNU General Public License v2.0
3.88k stars 459 forks source link

ubuntu-dock branch - Gnome 42 intellihide issues #1690

Closed Pshemas closed 2 years ago

Pshemas commented 2 years ago

First of all - thank you for those committing to this branch. It's basically what for me keeps this (IMO essential) extension alive.

Glad to see updates for Gnome 42. I've encountered one annoying issue - intellihide often "locks" and does not hide the dock. It's like keeping highlight on one of the items in the dock and where it is in this state the dock stays on top. By trying to hove over the dock several times and moving out or (/ and) by bringing the dash up I can sometimes make it hide again.

If you won't get what's the issue is about and would like to know more let me know - I'll try to record a video, it should explain it better. I'm on OpenSUSE Tumbleweed, Gnome 42.

julianfairfax commented 2 years ago

I also have this problem. When using Dash to Dock on GNOME 42 via https://aur.archlinux.org/packages/gnome-shell-extension-dash-to-dock-gnome42-git with autohide enabled and push to show off, moving the cursor directly from the dock to an app window and clicking on it doesn't make it go away. To make it go away I have to move my cursor out of the dock where no window is behind it. This shouldn't be normal behaviour as far as I know. This only happens on GNOME 42, so it must be an issue with the extension and GNOME 42.

J3is commented 2 years ago

This is not a Dash to Dock problem, it's a Mutter 42 problem. If you move the cursor away from any overlay (top bar, dash) into a window without passing by the desktop, the item you hovered in the overlay remains selected. When this happens, Dash to Dock thinks you're still on the dock so it doesn't make it disappear. It's fixed in commit 0280b0aa on GNOME's GitLab. So, either rebuild Mutter from sources or wait for GNOME 42.1.

3v1n0 commented 2 years ago

Indeed we have that commit in ubuntu and we didn't notice it so far...