NEEDS WINDOWS TESTING: gui: keep background-job widgets on the GTK thread - #21949
NEEDS WINDOWS TESTING: gui: keep background-job widgets on the GTK thread#21949Arecsu wants to merge 1 commit into
Conversation
|
if you can test this one, this might finally fix the focus stealing in Windows when exporting. I don't have a Windows machine yet to test this myself @TurboGit I've tested possible regressions under Linux, creating many batched exports, canceling, creating them, etc, and everything seems fine so far. Just mentioning in case you might want to check it for yourself, that is what should be tested |
ralfbrown
added
bugfix
|
@Arecsu I'm afraid this has not solved the focus stealing for me on Windows 10 (during export nor import), building on an updated MSYS2 environment. Are there more diagnostics I can provide you, like which gtk libs and other versions were used to build? I could potentially try to bisect since 5.4 when this issue was not there, but that's not at all trivial. |
|
I tested your version on Win11 and for me it worked perfectly. I started the export of few images, switched to another virtual desktop, and the focus stayed on that desktop the whole export, and also remained there when the export had finished. |
|
Okay, let me try to do the same on my Windows 11 laptop. Will probably only be able to do that later this week, but maybe I'll find time. |
|
Perhaps you can ask other Windows testers on Pixls.us? |
|
@lintujuh nice! could you please check if it also does not focus steal while minimized / at the bottom of other windows in the within the same workspace desktop? This way we see if we coincide with the report from @Thanatomanic And @Thanatomanic I think it is important to share the GTK libs and compiler used to build it. Good catch on that one. We don't have any logging paths in the code that would give us important data as far as I know. Bisecting also won't be helpful as we know it's closely related to the event controllers or gtk4-compatible windowing system. I made an AI do some deep research on the GTK3 source code to see where and how it calls to Windows focus stealing APIs. We found a few, none of which were clearly used and triggered by the code at darktable. Ah, GTK3 and its quirks 🥲 I'll see if I could get a hold of a VM machine |
|
I compile with GCC 16.2 in MSYS2 on Windows 10. Here are my packages: My packages and details. |
|
I managed to get build done on Windows 11 sooner than expected and I have some interesting news. I cannot get any focus stealing in Windows 11. I am not able to reproduce the report in #21829 for Windows 11. One specific thing I noticed is that on Windows 11 there exists a mechanism that the icon in the taskbar will flash up, like a notification. This happens each time a new image is exported, but I don't get focus stealing from other apps. Windows 11
Windows 10
|
|
No focus stealing when minimized. Now that @Thanatomanic pointed it out, I also noticed the flashing of the dt icon on the taskbar. |
4 participants
Fixes #21829
The background-jobs panel was creating GTK widgets from worker threads and only queueing their packing/showing. This made widget creation, progress updates, and teardown timing-dependent, contributing to platform-specific focus problems.
The panel now keeps worker callbacks GTK-free: they update plain state, while widget creation, updates, cancellation controls, and removal run on the GTK thread. Queued callbacks also keep job data alive and are invalidated during cleanup.
Linux GTK3 builds and cancellation/lifecycle stress tests pass. Windows testing is still required.
Related: #21843