godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
90.31k stars 21.06k forks source link

OS::shell_open blocks "Show in File Manager" when using xdg-open #49946

Open kuhnchris opened 3 years ago

kuhnchris commented 3 years ago

Godot version

3.3.1.stable.official

System information

Arch Linux

Issue description

When using blocking file managers (like nemo on openbox) when using the OS' s shell_open causes it to be in blocked mode until you close the file explorer / killall nemo. similar reference to #12188 as I assume it's due to the same case (OS::get_singleton()->shell_open blocks)

See here for reference: https://github.com/godotengine/godot/blob/4fcc5891450a7dca9c8ebae6ff3765f5f060c442/editor/editor_file_dialog.cpp#L669

Referenced here: https://github.com/godotengine/godot/blob/3a8bea3ae3652ec1054bb951fb8ec81cb2507f20/platform/x11/os_x11.cpp#L3168

which, funnily enough, goes to drivers/unix/os_unix.cpp: https://github.com/godotengine/godot/blob/3a8bea3ae3652ec1054bb951fb8ec81cb2507f20/drivers/unix/os_unix.cpp#L263

there, we see there is a "p_blocking" parameter, which is set to "true" in os_x11.cpp for that shell_open command - on purpose?

gio doesn't block on it's own, but I have xdg-open available, which blocks. (example:

06/27/21 14:43 - kuhnchris@~:> gio open file:///home/kuhnchris
06/27/21 14:44 - kuhnchris@~:> 
** (nemo:2941): WARNING **: 14:44:04.690: Current gtk theme is not known to have nemo support (Adwaita) - checking...
** (nemo:2941): WARNING **: 14:44:04.726: The theme appears to have no nemo support.  Adding some...
06/27/21 14:44 - kuhnchris@~:> 
(not blocked)

06/27/21 14:44 - kuhnchris@~:> xdg-open file:///home/kuhnchris
<blocked>

One possible alternative would be:

Please let me know if I overlooked something.

Thanks, Chris

Steps to reproduce

Minimal reproduction project

Not applicable as it is in the core project

Calinou commented 3 years ago

try setting p_blocking to "false"

Can you test this locally and see if it works for you? Ideally, test this on Windows/macOS as well if you have access to those operating systems.

kuhnchris commented 3 years ago

Yes, can do, will do and report back

kuhnchris commented 3 years ago

Doing so will now open the file explorer twice - I assume since the checks for "OK" won't properly trigger here. This definitly is not an desired outcome at all. I assume that all that wanted to be done is a "||" connection of commands, i.e. xdg-open file:/... || gio file://... || ..., correct?

kuhnchris commented 3 years ago

What, however, did work, was throwing the entire shell_exec block into a fork(): image Seems to be a very overkill solution for this problem, not sure if that is a desired direction.

lewiji commented 1 year ago

Any definitive fix for this? I'm experiencing it in 3.5.1 since switching to i3wm. Didn't seem to happen in KDE plasma, but I'm using Dolphin in both.

quinnyo commented 1 year ago

xdg-open doesn't do anything fancy like setsid for whatever it launches, it just runs it. However, if you have one of the big Desktop Environments that xdg recognises, the tool that xdg-open defers to might. This would explain most of the difficulty in reproducing the related bugs. You also won't notice the bug with most multi-window file managers and web browsers if there is already a window open, or file managers with a daemon running, as the new process just exits after notifying the original one to open a window.