after launching an app, a urxvt window is left open and visible until app closes
chesty opened this issue · 6 comments
More of an FYI as I found a solution without fully understanding what's going on. I haven't noticed any side effects.
I changed in my sway config from the original
-e env TERMINAL_COMMAND="urxvt -e "
to
-e env TERMINAL_COMMAND="exec setsid sh -c "
The full lines are
for_window [class="URxvt" instance="launcher"] floating enable, border pixel 10, sticky enable
set $menu urxvt -geometry 55x18 -name launcher -e env TERMINAL_COMMAND="exec setsid sh -c " /home/michael/github/sway-launcher-desktop/sway-launcher-desktop.sh
bindsym $mod+d exec $menu
Thanks for the issue. Can you tell me which program you're seeing this with?
This might be a somewhat tricky situation. If I get things right, the assumption here is that if there's a "terminal command" selected (either directly as an executable or within a desktop file), then the user is probably interested in its output. say for example htop. So it makes sense to spawn a new terminal instance that shows the command output for as long as the program runs.
But what if the command itself just launches a GUI? Then you get 2 windows. The GUI and a terminal that stays open as long as the GUI is open. wpg is one such example
I actually don't know how to handle this..
I see. So firefox, for example, would launch leaving a blank urxvt window hanging around. I just tested with htop and yes, it doesn't work with sh -c which I'm OK with.
I can't see an automated solution. You could ldd and look for gui libraries but that would fail for shell wrapper scripts that launch a gui app and probably statically linked binaries.
Unless something like shift+enter launches using urxvt and enter launches using sh -c, or a config file that lists tui apps like htop.
I'm happy with using sh -c and not being able to use tui programs. You could mention it as an option in the README.md with the pros and cons.
BTW, thanks for your work. It's a nice evolution of flyingwombat's work.
Okay it absolutely should not happen with Firefox. Is this happening with master or the latest release? And you are talking about the first Firefox desktop entry, not the binary, right?
Interesting. Probably some weird setting in my system.
I mainly use firefox, a terminal and x2goclient and they all did it. I just tested then with a few more apps, urxvt, handbrake, deluge, yelp, and calibre, they all leave an empty urxvt window lying around.
I don't know if it's using the desktop entry or not.
I guess it doesn't matter since it happens with every app I've tested but firefox is started with a shell wrapper script and it's the latest stable.
This is the latest sway from github master and I'm not using a display manager, I was just starting sway after logging into a getty, now I have a systemd service starting sway.
I noticed the same behaviour while testing with urxvt on its own without sway-launch-desktop, that's when I tried sh -c in .config/sway/config and it worked OK.
This is very very weird. I'm running pretty much the same setup:
- urxvt
- no display manager
- recently converted to systemd service
...and I simply cannot reproduce your issue. I set up the basic launch command from the README again, but it behaves the same (my actual TERMINAL_COMMAND is urxvt -e /bin/bash -i -c " which has the benefit of reapplying my color schemes).
I'm really sorry, but I am out of ideas. Please do let me know if you find something.
Btw does your urxvt support glyphs? You should be able to tell apart dektop entries and binaries by color and the glyph used
I have a feeling it's something to do with whether the app is X or wayland. I'm not worried about it and it's not a bug or anything like that with your project. If I feel inspired to look into in the future and discover what was going on I'll let you know.
Thanks for your time and thanks again for sway-launcher-desktop.