Actions are executed on an inactive window #41
Comments
|
Hi Luis, I managed to find a method to reliably reproduce this, so I am able to record video to demonstrate. It seems the problem is that I'm going too fast. I don't understand how that works, but maybe you will?
If I repeat the above, but do step 5 slower, at about half that speed, everything works fine. Or if I move fast, pause a moment and hover the spacer before I click, then click, that's fine too. Hope this helps nail it down! untitled.mp4Edit: Whoops, mkv doesn't work here. |
|
Hi, sorry I forgot to respond to this issue before. Is this on X11 or ayland? At least on wayland I can't seem to reproduce the issue with scrcpy, the window takes the focus immediately for me. Are you maybe using window rules or a KWin script that could interfere with windows focus? |
|
Please do this
|
|
Previously I had this issue with xwayland windows not being focused correctly (e.g when dragging the xwayland window, it dragged instead the wayland window from the other screen) but that seems gone now. |
No worries mate I figured it was just being difficult to reproduce :)
That's the weird thing - it has focus. For this test, rather than just opening the window and closing it, I open it, then click in it, unlock my phone, browse around, maximize scrcpy then restore it, browse around some more.... Then try to close with this tool, and same failure. I do have a kwin rule for scrcpy so I deleted it and the behaviour was the same. Perhaps it's noteworthy that my scrcpy .desktop file actually starts I tried the troubleshooting thing before but couldn't find a log file. I didn't think to check the journal facepalm I think I just had an old guy moment 😆 This shows why I'm seeing the behaviour for sure. It is detecting the wrong window as active before the bug occurs. This is the impoartant part of the log: At the moment of that last line, scrcpy is active, focussed, and accepting mouse input. When I click the spacer after this, that Kate window is closed. The first time I'd try this, I had konsole open running journalctl, and when I tried to close scrcpy, konsole would steal focus to prompt me if I wanted to close it. To avoid this focus stealing interfering with the results, I opened two copies of Kate, then opened scrcpy, then clicked the spacer 'close button' and moved my mouse off the spacer, repeated three times. Here's the full log of that: Armed with the knowledge of how to log this, I was able to come up with a more 'vanilla' reproduction process which doesn't rely on scrcpy and all that: Or here, with journalctl running in konsole in the background: ....and as soon as I type that and try to expand upon it.... Now I can't reproduce that any more (still can repro reliably with scrcpy). Gah! computers! 😆 |
|
Hi thanks for the detailed report, and since I forgot in the last response sorry for the data loss this bug has caused. I think I may have figured what the problem is, apparently TaskManager.TasksModel is not detecting the launched window vkcube in this case through the just as a quick experiment I uncommented the Which is used right before the code that runs the actual action: Can you try installing the branch https://github.com/luisbocanegra/plasma-panel-spacer-extended/tree/fix-active-window to see if it works? |
|
Thanks mate, I'm glad you were able to make some sense of it! I'm afraid I was unable to build it. I did change the dependency from I'm guessing this is a simple plasma 5 - 6 thing... I hope :) |
|
No problem, inside the project folder run this command The install script is kind of an overkill for qml-only widgets, I will replace that with the above command some day. |
|
Yep that's sorted it! Nice work mate! Thanks heaps 💚 |
Sorry mate I just saw this. Don't worry, I didn't lose anything too important and it was pilot error anyway. I knew I had this bug and I rode with it anyway. It was a conscious decision that the productivity I gain from this addon is greater than the potential lost productivity if it closed something I wanted to keep. I hope that gives you some impression of just how much I appreciate your work with these addons. I image that for most people, things like these are 'nice-to-have' but for disabled people they become 'hey that's a really big deal'. So, thank you!! |
Yay! I'll merge it and make a new release ASAP.
Good to know it wasn’t too important. Thanks for the kind words, warms my heart knowing the project has helped someone this much! |
luisbocanegra
added a commit
that referenced
this issue
Sep 19, 2024
Some newly opened windows don't seem to be registered by TaskManager's onActiveChanged But they seem to be correctly detected by onCountChanged when we update the last active one closes: #41
luisbocanegra
added a commit
that referenced
this issue
Sep 19, 2024
Some newly opened windows don't seem to be registered by TaskManager's onActiveChanged But they seem to be correctly detected by onCountChanged when we update the last active one closes: #41
|
I think the fix might be causing plasma to crash on startup. When developing plasmoids, I need to restart plasmashell a lot, since this patch, sometimes after a plasma restart it crashes, sometimes it enters a crash loop. At first I thought the crash was caused by my changes to panel-colorizer but looking at the stack trace it mentions libtaskmanager. I am not sure what causes the crash as it seems random but since reverting that patch yesterday it didn't happen again, and after applying the patch some hours ago I had the same crash again. If I have to make a guess it could be because it's updating the windows info too fast. |
|
Oof sorry mate! For what it's wortth, I haven't seen plasma crash yet... Seems like it is quite sensitive. I hope it won't be too annoying and hard to reproduce :( If there's anything I can do to help, please let me know. |
luisbocanegra
added a commit
that referenced
this issue
Sep 22, 2024
|
Can you try installing the branch At least here with vkcube I always see it as the last window in the debug log, and doing actions on it works. But I can't reproduce the actual bug even in the current released version so is not entirely clear if this change is really doing anything. |
Yep that does the trick for me :) |
luisbocanegra
added a commit
that referenced
this issue
Oct 2, 2024
luisbocanegra
added a commit
that referenced
this issue
Oct 2, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi again Luis, hope you're well!
I've been noticing a strange bug lately. It doesn't happen always. I especially notice it with two apps, scrcpy and coolercontrol, if I start them from the Application Launcher, then execute an action from your awesome spacer, such as to maximise or close the window, then the previously active window will be maximised or closed.
Eg right now if I click my App Launcher and select coolercontrol from my Favorites, it opens up in front and the Task Manager widget shows that it is active, if I scroll up on my spacer, that should normally maximise it, but when I do, it will maximise this window. If I click on it or interact with it in any way, before I send it a command with the spacer, it works as intended. It's as though the spacer doesn't know it is the active window.
I feel like this wasn't always an issue, so I had a look through the changelog and noticed this b3d25a0 I wonder if maybe this could be related? I was seeing this bug with 1.6.0 (before this commit) and am now seeing it in 1.8.2, so perhaps not, or perhaps I see a similar bug and this commit doesn't fix mine?
It's early days, so forgive me if this changes, but it seeeems like with 1.8.2, it still fails for scrcpy, but works OK for coolercontrol? That seems odd, but... I had a 100% reproducible break just moments ago as I typed this, I upgraded the spacer from 1.6.0 to 1.8.2, and now it still always fails on scrcpy but never on coolercontrol, which has been reliably failing for maybe several weeks now. Weird?
The text was updated successfully, but these errors were encountered: