Some users (like me) often run their programs from built-in shell to see stderr error messages. Unfortunately, the program run from shell is a child of konsole, that is a child of dolphin. Closing Dolphin kills the program.
This affects KWrite but for some reason it doesn't touch Kaffeine. So for some reason not even all Qt4 apps are affected.
Dolphin should at least warn the user that closing it will cause his program to get killed.
Solution from my dreams:
Konsole with the program run from it should still be running as children of kdeinit4, with no dolphin above. Dolphin should close normally. Konsole should get a new window. I have nice dreams, huh? :D
Steps to Reproduce:
1. Open Dolphin
2. Summon the shell (F4)
3. Run something like glxgears
4. Close Dolphin.
The program gets killed.
It should be still running.
Configuration shouldn't matter.
Thanks for the report!
I agree that some kind of warning might be nice, but please note that not even Konsole warns when closing it and indirectly killing its child processes. Moreover, I think that this is far from easy to implement. I consider this a feature request and not a bug.
You're completely right, thanks for fast response.
But users are not used to get their program killed when they close file manager. That's kind of trap.
Another idea: Warn the user when he opens (not closes) built-in shell that closing Dolphin will cause the shell job to be terminated and include "Don't show it again" checkbox. That would be rather easy.
However, I didn't emphasize it: some programs like Kaffeine don't suffer from this "trap".
(In reply to comment #2)
> You're completely right, thanks for fast response.
> But users are not used to get their program killed when they close file
> manager. That's kind of trap.
> Another idea: Warn the user when he opens (not closes) built-in shell that
> closing Dolphin will cause the shell job to be terminated and include "Don't
> show it again" checkbox. That would be rather easy.
Yes, but it would annoy many users. Of course, the unexpected closing of apps is also an annoyance, but I think we did not get any bug reports about that before, and the issue has been around for many years. Therefore, I think that the benefit of having such a warning would not outweigh the negative effects of the annoying warning. But I'm not 100% sure, maybe I'm wrong after all.
> However, I didn't emphasize it: some programs like Kaffeine don't suffer
> from this "trap".
It could be that the Kaffeine process which is run in the shell starts the process which actually runs the app indirectly, such that this one is not affected by killing the terminal.
Resetting assignee to default as per bug #305719
There's a patch for this: https://phabricator.kde.org/D10960
Git commit 2100a7a5c85931d46b72d391faa3d136d4401010 by Nate Graham.
Committed on 19/01/2019 at 15:15.
Pushed by ngraham into branch 'master'.
Ask for confirmation when Closing Dolphin windows with a terminal panel running a program
Ask for confirmation when Closing Dolphin windows with a terminal panel running a program.
# Open terminal panel
# Run `watch ls`
# Close Dolphin
# Observe confirmation
# Disable confirmation
# Repeat, observe no confirmation
# Enable confirmation in the settings
# Repeat, observe a confirmation
Reviewers: #dolphin, markg, elvisangelaccio, rominf
Reviewed By: #dolphin, elvisangelaccio
Subscribers: kfm-devel, elvisangelaccio, markg, ngraham, rkflx, broulik, #dolphin
Differential Revision: https://phabricator.kde.org/D10960
M +53 -1 src/dolphinmainwindow.cpp
M +13 -3 src/panels/terminal/terminalpanel.cpp
M +3 -1 src/panels/terminal/terminalpanel.h
M +4 -0 src/settings/dolphin_generalsettings.kcfg
M +28 -0 src/settings/general/confirmationssettingspage.cpp
M +5 -0 src/settings/general/confirmationssettingspage.h