Closed JakeSFR closed 6 years ago
Is it newer versions bug?
Well, the bug is not present in ROX build from 2017.12.
Btw, were you able to reproduce this bug at all?
No. my window manager gives focus before the popup of the menu. So I will use another WM to reproduce it. which one are you using?
I've encountered it with Openbox and JWM.
Technically, they also give focus before the popup, but despite that the bug still happens if the window was initially unfocused...
Hmm, Not reproduced. Do items of 'Next Click', 'Select' and 'Display' in the menu works? or do you have any clue to reproduce it?
Hmm, Not reproduced.
Hmm, it seems to happen only in VirtualBox and sometimes in QEmu. Just tried it on real hardware and couldn't reproduce it as well. Sorry about that - we're developing a new release of Fatdog and I'm still running it mostly in VirtualBox.
But still, it doesn't happen, even in VBox, with our previous ROX build, from 2017.12...
Anyway, this may suggest that it might be some timing issue perhaps? Maybe ROX does not receive the signal that the window is already focused quick enough?
Do items of 'Next Click', 'Select' and 'Display' in the menu works?
No, they don't.
What works is:
or do you have any clue to reproduce it?
Perhaps you could try it in some "slower" environment like VirtualBox, maybe even directly in latest Fatdog. Here's current (development) ISO: http://distro.ibiblio.org/fatdog/broken/800pre/
We use some custom patches for ROX, but I've also built it without them and the problem persists.
Just note, that there is currently a bug, probably related to kernel 4.18.5, that may prevent showing the desktop (black screen), until you hover mouse pointer over virtual machine's window and move it a little or press any key a few times.
Thank you for very interesting infomations!
Here's something that might help to pinpoint the culprit, I hope. Note that (as I mentioned elsewhere) I'm not really familiar with ROX's internals and have only limited knowledge of C & GTK, so the below was just stab in the dark.
Anyway, I added a delay in menu.c, at line 874:
appmenu_remove():
sleep(1);
window_with_focus = filer_window;
to see if it would improve the situation. But what happend was quite opposite - now it doesn't work at all, even if the window is already focused! So, indeed it looks like some timing issue...
So, may the commit above changes the timing?
It is reproduced with your 'sleep(1)' even on my pc and on the commit above with the 'sleep(1)', the menu items work.
So I think the commit may fixed this isssue. Is it fixed?
Yes it is - I just built it and can't reproduce it anymore.:)
Thanks a lot!
It delays refresh of the paste item of the menu. So could you check whether the paste is enabled or not?
Not sure if this is what you mean, but I just tried this, multiple times:
and it works, as usual.
Oh, and if the clipboard is empty, the 'Paste' option is grayed out, as it should be.
The original src enables the paste item if there was clipboard data but the getting clipboard data is slow and has async func. I changed it to use async func. So I thought dose it works on slow env?
Anyway it seems works. Thank you for reporting! It was very interesting.
No problem and thanks again.
Cheers!
To reproduce:
We're using current master in Fatdog64.