Drawer becomes unresponsive for some inputs #68
Comments
|
I know nothing about NixOS, as well as tor. What wonders me are these lines:
Anything wrong w/ your system configuration? Do you have these lines in your sway config file? This file should be re-created if missing. You must have an error inside it. |
I do. But it looks like enabling the service
I created this file manually which makes this error also go away. By the way, the installation command With these two errors disappeared, I still get the same behavior as before when typing |
|
I'll try to find some time to get a GDB backtrace. |
|
On second thought, I'm not sure I know how to do that, given that when unresponsive, nwg-drawer blocks my entire desktop. |
|
I'm having this issue as well, except with the string "game". Nwg-drawer becomes unresponsive and starts blocking the desktop. The desktop responds to inputs underneath but I have found no other way to fix the issue other than dropping to TTY and killing sway. I'm on Arch using the latest zen kernel |
|
I've not yet found my string to hang the drawer. This will probably tell us nothing, but, in case you have 2 outputs, could you:
|
|
I don't have two monitors unfortunately, but I think I can type in the terminal while the drawer is hanging. Let me try it |
|
So nothing printed on the terminal underneath the transparent drawer while the error was happening, however after spamming mouse clicks, the escape key, and the backspace for about 2 minutes the drawer died and some errors printed in the terminal: |
|
Hmmm... No idea why "game" could be not a valid UTF-8 string, but we have at least some little clue. |
|
@OlivierNicole, @zoro11031: what's your |
|
echo $LANG |
|
May I see the full |
|
I do have one custom .desktop file that I made that appears when I search "game", but it launches fine and doesn't cause issues when I scroll to it without searching so I'm not sure if it's the issue. It's the only unusual condition that's triggering though I think. This is the contents of it: |
|
You could change its extension temporarily, to make sure.
Nothing unusual. It's damned difficult to find a solution to an error that you cannot reproduce. :/ |
|
One way or another, we have just 2 culprit candidates: searchEntry or statusLabel. |
|
Unfortunately hiding the desktop file for game2text doesn't seem to have fixed the issue :/ |
|
Could you check and show me the content of the .desktop file of the focused item? Probably this one:
|
|
Also, to make sure that the error doesn't come from the file search, please check if it still occurs with the |
|
|
@OlivierNicole, OK, thanks. It seems the reason is different. Could you please check which app icon is focused when the drawer gets stuck, and then show me its .desktop file content? Also check if the drawer hangs if started with the |
|
I think it's the file search. I just tried with and without file search, it freezes with, and doesn't without. I do have a second drive connected with a games folder, and a network drive connected that also has a games folder. Could it be possible that trying to parse through those drives is causing the hang? As a side note, I haven't been able to reproduce the UTF issue in the console logs since the first time I ran it using nwg-drawer -d. This was the output of the last crash: |
Only if they're mounted inside your home directory. I see you use |
|
No, they're mounted in /mnt. I'll try it anyway when I'm off work just to see |
Assuming you're right, I'd like to see the path that causes the failure. I added a line to print them while creating file search results. You'd need to install the Example (the phrase if "bro", as "game" returns just 1 result on my machine): To kill the hung drawer, you could use a key binding to |
|
I think I figured out the culprit, it was game2text but not the desktop entry itself but the Python virtual environment in the application directory. It was being backed up to another folder outside of it's usually home and the drawer was catching it. Here's a small sample (the logs go on for hundreds of lines) |
|
Is it possible to code an upper limit to the amount of paths nwg-drawer will return before stopping the directory search? 50 seems like a good number, I feel like if you're looking for results beyond that you would be using grep or your file manager's search function haha |
|
Hmm here's something though: I tried excluding the directory in question to see if it still caused issues... and the string is still causing the application to hang |
|
Yes, the directory walk is effective enough to support hundreds of results. Sorry, for now I have no idea how to fix the issue. I need to reproduce it on my machine first. |
|
No worries, I'm using the -nofs argument right now as a workaround and it works as a temp fix for the issue. I'm okay with using my file browsers search function for everything for now. Thanks for taking a look anyway! |
|
Yeah, but it needs to be resolved. Let me know if some clue appears. |
|
Actually, the other day I ran it without fsmode and it locked up on a string that wasn't "gam". If I remember right it locked when I was trying to type emacs. So it seems the issue is either progressive somehow or there's something in common between both those queries on my system that's locking it. I'll mess around with it later and let you know |
|
Whatever that I can see on my development machine will be of help. |
|
I have the same, my magic word is So maybe it chokes on my 7992 firefox cache files ? Why does it scan that directory in the first place ? |
|
@varac It shouldn't search it at all. May I see the content of your |
Sure: |
|
Thank you! When I'm home, I'll prepare another version on this branch, w/ some more debug messages. |
|
[debu68 branch] I've added a line to see which paths are actually going to be searched. Should appear prefixed by @varac Which distro do you use? |
|
I've also fixed the userDirsFile path to use the |
|
Hugh, this might be related: I'm using Arch Linux installed 3 days ago. |
It looks like this. And the |
|
Right - I had a symlink for With these dirs nwg-drawer works fast and like a charm. Thanks for this project ! |
|
Excellent, but does it prevent the drawer from hanging? |
|
Yes it does ! |
|
Great! Hope @OlivierNicole and @zoro11031 have the same issue, but it needs to be confirmed. Guys, this branch now also includes a fix to the userDirsFile path, that may be important on NixOS. Please give it a try. |
|
Sorry for not being more responsive on this issue, I have not found the time recently. I confirm that the issue no longer appears at 85cc2d7. 😃 |
|
Thank you, @OlivierNicole. If so, I'll merge the branch soon. |
|
Sorry man, I've been busy with finals over here as well and haven't had a chance to look. I can give the new branch a try tonight if you still need testing for it |
|
@zoro11031 I'm merging one way or another. Let me know if it still misbehaves on your side. |
|
Just tried it out, just wanted to confirm that it fixed the behavior for me as well. Thanks as always for being so responsive and quick to update |
I'm using nwg-drawer 0.2.8 on NxOS 22.05.
How to reproduce
tor-In my setup, the program just freezes and freezes my entire Sway desktop. If I hit Escape, the nwg-drawer exits and my desktop is back to normal after some time (around 10 s).
I don't know why Tor Browser in particular triggers this behavior. I have also noticed that nwg-drawer is not very responsive in general. Response to keypresses takes always takes at least half a second.
nwg-drawer output:
The text was updated successfully, but these errors were encountered: