search

fthx / dock-from-dash

GNU General Public License v3.0
97 stars 20 forks source link

Last update doesnt hide the dock #17

Closed frandieguez closed 2 years ago

frandieguez commented 2 years ago

Today's update hide animation behaves strange as it doesnt hides after focus lose.

Please check the attached video cause it is quite annoying.

Note that after unhovering the dock, it keeps visible even if I click on the desktop or another window. It only disappears after moving the cursor to the bottom edge of the display.

https://user-images.githubusercontent.com/4584/155989374-40fc198c-c1d4-4f87-af96-31d6a4e6c0a2.mp4

Thanks for your work!

fthx commented 2 years ago

Hi,

Please read this: https://extensions.gnome.org/extension/4703/dock-from-dash/

I suppose you do use GS 42? If so, GS 42 did break the right-click menu since it removes the focus on the dock so it closes without the possibility to do anything with app's icon menu. So I ran for another behavior. You can display the dock forever, someone asked me this feature.

I played around with this new behavior and I find it somewhat cool. I'm working on a nicer dock highlighting animation.

frandieguez commented 2 years ago

Yes, I'm running GS 42. Have you tested it on GS 42? Cause is quite annoying to use cause it never hides after shown unless you hit the bottom edge of the screen again. For now I'll disable the extension, as this is not the behavior I expect for a dock that autohides. Just as Dash to Dock, plank or even Mac OS dock

fthx commented 2 years ago

I do use GS 42 and that's because of that I had to change behavior. In GS < 42, right-clicking on an app icon did not make the dock hover to be lost. https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/49b9ae08d81345e17b7b7794709a374d5d57e058

I attach you the latest version, to see if it could match your needs: dock-from-dash@fthx.zip

Anyway, it's certainly possible to revert to the old behavior but it needs a lot of changes to detect if the dock is hovered.

fthx commented 2 years ago

Note that you can revert to <= 22 version that behaves as you like, but you'll cannot access right-click app icons menus.

fthx commented 2 years ago

Ok, I found an acceptable solution to restore old behavior. I'll tell you here when it's fully ok.

frandieguez commented 2 years ago

Note that you can revert to <= 22 version that behaves as you like, but you'll cannot access right-click app icons menus.

I'd rather get the old behaviour than using the right click.

frandieguez commented 2 years ago

Ok, I found an acceptable solution to restore old behavior. I'll tell you here when it's fully ok.

Thanks for all your effort, really appreciate it

fthx commented 2 years ago

You'll have soon both old behavior and right click. It already works but needs to check all this cleanly.

fthx commented 2 years ago

https://extensions.gnome.org/review/29937

You can set timeouts if needed, in ext.js.

fthx commented 2 years ago

it's already online! v27

frandieguez commented 2 years ago

wow, that was fast. Let me check

frandieguez commented 2 years ago

Yes! now it works as expected. I only had to tune the SHOW_DOCK_DURATION, DOCK_AUTOHIDE_DURATION vars to have it how I want it. I miss the prefs panel to not have to tune it from the sources and restart g-s, but I understand that you want to keep it simple.

fthx commented 2 years ago

What are your timeouts/duration settings? Do you use app icons right-click menus?

frandieguez commented 2 years ago

Well.. you are gonna laugh at me but... I consider the dock as something quick to launch apps, and I want it to get away as soon as possible as well I want to get it shown as quick as possible so...

var SHOW_DOCK_DURATION = 50; var HIDE_DOCK_DURATION = 50; var TOGGLE_DOCK_HOVER_DELAY = 50; var DOCK_AUTOHIDE_DURATION = 50; regarding apps icons right-click menus? this is something that doesn't matters to me while they work from the dash.

frandieguez commented 2 years ago

something interesting to do would be to have those values in a separate file that anyone can edit... and during runtime the extension could check if the file exists then it loads values from that file (something like a .ini file or so). Note that I'm not particularly sure that this would be the right way to do it.

Obviously, I prefer to move those "values" to dconf, and having to use dconf cli or dconf editor to edit them, so on extension updates my custom values are not overridden and having to relogin to get those changes applied under Wayland. I don't mind about having a prefs panel or not, just having them as gsettings instead of hardcoded values would be AMAZING.