Created attachment 118495 [details] Latte layout attached, in case that helps(?) SUMMARY I've noticed that quite frequently, but inconsistently latte will stay visible when set to auto-hide when moving the mouse in & out quickly when set to auto hide. This will also happen with the hover-to-preview window preview open. Unfortunately, as it isn't very consistent behavior, I can't give you very useful steps to reproduce. However, it happens a lot. I'm sure if you were to set your dock to auto hide the behavior would exhibit itself at least once. STEPS TO REPRODUCE 1. Have latte set to auto hide 2. Complete an action quickly (seems like you need to actually do something, ie. launch something or do something via contextual menu). 3. Be frustrated at lack of polish. OBSERVED RESULT Dock stays visible, sometimes zoomed as if the cursor was hovering over an item, or even with a window preview open. EXPECTED RESULT Dock should hide when cursor is not "in" it at all times, unless a contextual menu is open. SOFTWARE/OS VERSIONS Windows: N/A MacOS: N/A Linux/KDE Plasma: Manjaro (current stable 18.something) (available in About System) KDE Plasma Version: 5.15.1 KDE Frameworks Version: 5.55.0 Qt Version: 5.12.1 ADDITIONAL INFORMATION
I am trying with Latte git version but I can not reproduce it in my system for stable branch this is difficult to solve
On the other hand maybe we could try to identify it. Run Latte from command line with: latte-dock -d --with-window A debug window will appear, when the issue appears please make a video showing both the debug window and the issue and upload it in Google drive or dropbox
I'll play around with it when I get some free time. Thanks for leaving the bug open.
Having the same problem here. I have a theory that it's caused by the user leaving the MouseArea (for the window preview) before it's active, meaning the onContainsMouseChanged signal is never sent. However, I haven't done enough testing to verify this is the case. Unfortunately, it also happens quite rarely for me, so I haven't been able to find a way to reproduce it reliably. I will do some testing and report back what I find.
Done some debugging, and I believe this may be a Qt bug. Basically, when this happens, containsMouse is still true for the ToolTipWindowMouseArea component, even though my cursor is clearly outside the window preview. To make this even more clear I tested it by starting a timer that would trigger 1 second after the window preview was shown, and made it output containsMouse. And sure enough, it was true even if my cursor was in the middle of the screen. Looking at the qt code, containsMouse only returns a value that's set when leaving, entering or moving the cursor. If I were to guess, the hoverLeaveEvent is never triggered, causing the internal value to never be updated. I still haven't found a reproducible way to trigger this bug yet, but I am working on it. It just happens randomly when you quickly move the mouse cursor over the window preview, just as it appears.
I have hit the same bug. I have the dock set to "Dodge active". I also have a feeling that the mouse leaving event is somehow not received by latte dock. Here's a video[1] reproducing them with debug window open. 1. at about 0:26, zoom effect not reset after mouse leaving 2. at about 0:42, zoom effect not reset, tooltip not hide, dock not hide 3. at about 1:08, zoom effect not reset [1] https://drive.google.com/open?id=12WYyTzkK9CL_CySGf85ScKkPGaHWq84J
(In reply to Aetf from comment #6) > I have hit the same bug. I have the dock set to "Dodge active". I also have > a feeling that the mouse leaving event is somehow not received by latte dock. > > Here's a video[1] reproducing them with debug window open. > > 1. at about 0:26, zoom effect not reset after mouse leaving > 2. at about 0:42, zoom effect not reset, tooltip not hide, dock not hide > 3. at about 1:08, zoom effect not reset > > [1] https://drive.google.com/open?id=12WYyTzkK9CL_CySGf85ScKkPGaHWq84J Are you using Latte v0.8 or git version?
(In reply to Michail Vourlakos from comment #7) > Are you using Latte v0.8 or git version? I'm using 0.8.8. But the bug was also there for the previous 0.8.7. But I'm not sure which version exactly did the bug first appeared.
(In reply to Aetf from comment #8) > (In reply to Michail Vourlakos from comment #7) > > Are you using Latte v0.8 or git version? > > I'm using 0.8.8. But the bug was also there for the previous 0.8.7. But I'm > not sure which version exactly did the bug first appeared. A way to reproduce this for git version is needed in order to have a proper fix
I'm going to attempt to compile qt to see if I can find out what's causing this over the coming days. I will report back what I find!
is anyone is this thread using Latte git version? in order to confirm me that today commits fixed this issue for the git version?
Do you mean git master? Unfortunately I haven't been able to get that working on my system due to the task manager widget not loading at all. It shows a bunch of errors on startup, so I'm guessing it's not working because of some incompatibility issue. Does it depend on some later plasma framework version? I'm on KDE neon testing which has 5.15.4.
(In reply to Mathias Tillman from comment #12) > Do you mean git master? Unfortunately I haven't been able to get that > working on my system due to the task manager widget not loading at all. It > shows a bunch of errors on startup, so I'm guessing it's not working because > of some incompatibility issue. Does it depend on some later plasma framework > version? I'm on KDE neon testing which has 5.15.4. It should be fine, please open a bug report and provide the installation output and the errors when running Latte
Running git master now, and things are looking good so far. Will report back in a few days after testing it more.
Done some more testing, and it is definitely fixed in git master. To test I checked out 77f7d27c83b2be01a6ad49c09df3f58c489790c1 and the issue is back again, then checked out 834b6477ac53a81541207b9ade8d58051fb4e6d2 and it's fixed.
(In reply to Mathias Tillman from comment #15) > Done some more testing, and it is definitely fixed in git master. To test I > checked out 77f7d27c83b2be01a6ad49c09df3f58c489790c1 and the issue is back > again, then checked out 834b6477ac53a81541207b9ade8d58051fb4e6d2 and it's > fixed. perfecto! The fix was part of a refactor step, I really like when refactors solve problems just by better design!
Yeah, feels nice when a simple refactor actually fixes something! I backported 834b6477ac53a81541207b9ade8d58051fb4e6d2 to the v0.8 branch, and it looks to be working there as well. Any chance you could push out a new 0.8 release with it fixed? Prefer to stay on the official distro version since I get automatic updates and such that way.
Sorry I don't agree pushing this to stable because it could create breakage to other parts that now cant identify