Closed lucianofr closed 2 years ago
I'll try that once 42.0 will land in Ubuntu 22.04. ATM it's 42 beta and the ext is ok.
Do you have any other extension enabled?
For what its worth, I'm seeing this issue too on Fedora 36 Gnome 42.0. Tested with no extensions installed. Attached vid. Also, I don't if that little 'jump' the dock does when the overview is triggered at the end is related to this?
https://user-images.githubusercontent.com/2906363/160420942-f784ec24-ff29-4158-b603-d49d636d528a.mp4
Edit: Actually, I lie. I had the clipboard history extension still installed for that vid. This still happens with that extension switched off however
Sorry I do not see anything in your screencast? The shift in overview when dock is displayed is solved. I had seen the GS commit that reverted the beta behavior. Will land very soon.
I cannot reproduce the not hide bug. GS 42.0 has landed in Ubuntu so I'm stuck here. The error messages you see in logs are safe, that's a bug in GS itself not cleaning properly. GS team is aware of that. That's not a problem for the extension.
same on Fedora 36
I've tried in a Suse Virtualbox VM and it's working, though hiding does fade (not slide). @all you have to be sure that another extension does not interfere and give me some logs, because I cannot reproduce.
I've noticed that when there is no apps open the dock hides normally, but when I have a chrome instance running it doesn´t.
On Mon, Mar 28, 2022 at 5:21 PM fthx @.***> wrote:
I've tried in a Suse Virtualbox VM and it's working, though hiding does fade (not slide). @ALL https://github.com/ALL you have to be sure that another extension does not interfere and give me some logs, because I cannot reproduce.
— Reply to this email directly, view it on GitHub https://github.com/fthx/dock-from-dash/issues/22#issuecomment-1081102355, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA247ULYZBL6CEUBTAZXFKLVCIIDJANCNFSM5R2NTKOQ . You are receiving this because you authored the thread.Message ID: @.***>
-- Atenciosamente,
Luciano
I cannot reproduce either, running Chrome (or not). Maybe there's an Ubuntu patch to GS 42.0 ?
Have you seen the video that I´ve sent? Ok, I will wait, maybe in few days an update will land in my tumbleweed.
On Tue, Mar 29, 2022 at 7:14 AM fthx @.***> wrote:
I cannot reproduce either, running Chrome (or not). Maybe there's an Ubuntu patch to GS 42.0 ?
— Reply to this email directly, view it on GitHub https://github.com/fthx/dock-from-dash/issues/22#issuecomment-1081690221, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA247UMMKXT7BOUSCZPJGGDVCLJZVANCNFSM5R2NTKOQ . You are receiving this because you authored the thread.Message ID: @.***>
-- Atenciosamente,
Luciano
What video? If it's the video above from seanleavy, I see a static image during all the video.
I had sent it through e-mail, I think it was blocked by the server.
On Tue, Mar 29, 2022 at 8:40 AM fthx @.***> wrote:
What video? If it's the video above from seanleavy, I see a static image during all the video.
— Reply to this email directly, view it on GitHub https://github.com/fthx/dock-from-dash/issues/22#issuecomment-1081765157, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA247ULP7EYTUGZ2DPC6OJLVCLT3RANCNFSM5R2NTKOQ . You are receiving this because you authored the thread.Message ID: @.***>
-- Atenciosamente,
Luciano
Well, could you again return your logs, only for the queries 'fthx' and 'js' ? It must exist something, maybe an error. Because hiding is just a timeout here since v42 does not allow me to detect correctly leaving dock hover.
Ok I can reproduce a non-hiding case: hit the bottom of the display and go around the dock without hovering it. I'm not sure it's a normal way of using the dock, though. ;-) Just hovering the dock does allow the dock to auto-hide again.
Maybe I was used to the dash-to-dock behavior.
On Tue, Mar 29, 2022 at 9:17 AM fthx @.***> wrote:
Ok I can reproduce a non-hiding case: hit the bottom of the display and go around the dock without hovering it. I'm not sure it's a normal way of using the dock, though. ;-) Just hovering the dock does allow the dock to auto-hide again.
— Reply to this email directly, view it on GitHub https://github.com/fthx/dock-from-dash/issues/22#issuecomment-1081798664, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA247UPD6LQCT4NS3BPZKITVCLYELANCNFSM5R2NTKOQ . You are receiving this because you authored the thread.Message ID: @.***>
-- Atenciosamente,
Luciano
Well that's the same. The bottom invisible bar that detects hitting the edge of the screen has dock width. So I feel not natural to skip the dock after that. This behavior can be modified by detecting all the dash hover, not just dashContainer. This way make impossible to go up with mouse cursor without hovering (then leaving the hover) the dock.
I you can post here a video with your way of reproducing the problem?
Sorry @fthx , I don't know why that video didn't play correctly. @lucianofr 's video is the same thing so their's is a good reference for this. I attached some logs too. Since boot with only your extension loaded.
If the app name (or label/title/tooltip, not sure what to call it really) shows, then the issue will occur. The hover event seems to get 'stuck'. I wonder if this is some upstream bug?
I think that I found how to reproduce this (or, at least, one case where the dock doesn't hide): go down with the mouse to show the dock. When it is shown, move the mouse up outside the dock, but through an app icon. The icon will show the tooltip with the app name, and the dock won't hide until the mouse enters and exits again the dock (thus generating a 'leave-event').
Damn I cannot reproduce, I tried dozen of times.
Ok, there is a bug in St: the 'hover' property sometimes fails and get stuck in TRUE.
You have to move the mouse at "half-speed". Neither as slow as to give it time to show the icon's tooltip while the mouse is inside, nor as fast that the tooltip not even appears.
Anyway, the bug is even deeper: it is at least in Clutter, because in that case, the "leave-event" isn't emitted. I'll fill a bug report.
Nope. I'll never succeed to do that. I resign.
What gnome shell version do you have? I'm using gnome shell 42...
I have a video capture, but github doesn't support webm.
Yes GS 42.0 in Ubuntu 22.04. gtk+ 3.24.32 patched by Ubuntu I'll try again tomorrow...
Maybe the problem is only in X11 (I'm using it to easily reload gnome shell after modifying the extension). Are you using Wayland?
Yep, Wayland.
Yes, I'm unable to trigger this from Wayland. So moving this to very-very-low-priority :-D
I'm unable to reproduce in X11 too. I'm not that skilled. ;-)
Note that I do use this extension only at office when my laptop is docked (external mouse and kb). Now GS has 3 fingers gestures that are very very convenient. Obviously, without a touchpad, GS behavior is quite odd, as you have to go top left to display the dash at bottom... So I do use super key, if not this extension.
I always use the left-side windows key for that, and also use my extension ActivitiesAppLauncher, which keeps the applications in a very handy location :-) </sponsored message> :-D
If you're interested, I'm thinking/planning about a modified BaBar (lite) extension, picking the ideas I found on dock from dash one (it took me some time to learn how to create another dash and place it correctly). So the taskbar would be a clone of the dash, picking all the app icons objects. Just creating a mini-dash in the top bar does not look well, I did that too. ;-)
I'm almost certain now this is outside of your control and is an upstream bug (I'm on Wayland by the way). I'm seeing this hover issue on the panel too:
Notice the applications and system status area are both still hovered.
Rgds Sean
Of course, we could always do some hack, like reading periodically the mouse position and detect manually when it is outside the dock's surface, but it would be quite... ugly.
Anyway, there is a way of forcing a refresh, which is to move the mouse inside another surface (like the dock or the top bar). This is: if the element remains visible and you have the mouse over the current application, just move it over the top bar or the dock, and that will "reset" the problem.
On Mon, Mar 28, 2022 at 7:36 PM Luciano França Rocha @.***> wrote:
I've noticed that when there is no apps open the dock hides normally, but when I have a chrome instance running it doesn´t.
On Mon, Mar 28, 2022 at 5:21 PM fthx @.***> wrote:
I've tried in a Suse Virtualbox VM and it's working, though hiding does fade (not slide). @ALL https://github.com/ALL you have to be sure that another extension does not interfere and give me some logs, because I cannot reproduce.
— Reply to this email directly, view it on GitHub https://github.com/fthx/dock-from-dash/issues/22#issuecomment-1081102355, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA247ULYZBL6CEUBTAZXFKLVCIIDJANCNFSM5R2NTKOQ . You are receiving this because you authored the thread.Message ID: @.***>
-- Atenciosamente,
Luciano
-- Atenciosamente,
Luciano
The dock doesn´t hide itself. I've tried to tweak the extension.js file change the times and had no success. I am using opensuse Tumbleweed, wayland, Gnome 42.0