Konsole uses class KUniqureApplication ever since KDE4. That decision means at least two features: 1. All konsole instances started through krunner/menu/hotkey runs in the same process 2. konsole instance started from one existing emulator/shell will run in its own process, but runs in the background(more precisely, detached from the existing emulator/shell). That two features are sometimes annoying to users, and they need some way to suppress that two features and make konsole behave in a more traditional way: each instance runs in its own process, and runs in the foreground. At the moment, the "--nofork" option (provided by KUniqureApplication) is used for both purposes. I think using "--nofork" to suppress feature 1 is not a good idea, because : 1. That is kind of abuse. That "--nofork" option is actually intended for suppressing feature 2. 2. Its name is not easy to understand, and the option is hard to find (buried in the output of --help-kde). So I propose adding a new "--separate" option dedicated for suppressing feature 1. That doesn't means "--nofork" will not suppress feature 1 any more. It is just that we should recommend using "--separeate" for that purpose. Note, the "--separeate" option is inspired by roxterm. Actually, I remember some user asked for that option in the #kde channel. Reproducible: Always
Are there any statistics, how simply not KUniqueApplication would affect memory usage? Dolphin no longer uses it. Actually, browser developers start using the reverse approach: One process per tab, so that all the memory the tab used is freed, when it is closed.
I don't know about any statistics. But there are other things to consider besides memory usage. For example, the existing "--new-tab" option will stop working if konsole stops using KUniqueApplication. I'm not a fan of adopting the single-process model in a terminal emulator, especially when that is the default. I think what rxvt-unicode is doing is better: provide "urxvt" for the traditional way, and "urxvtc + urxvtd" for the sexy way. But practically, I don't think the situation of using KUniqureApplication will change. There are just ideas , and nobody has really evaluated the influence of that change in a concrete way.
Git commit 2b31d261519acb3c26e6c0369a7cbb0a8fc024e3 by Kurt Hindenburg. Committed on 12/02/2014 at 16:20. Pushed by hindenburg into branch 'master'. Add --separate command line Use a new process if --separate is used on command line. Similiar to --detach (from kuniqueapplication). Patch by Jekyll Wu <adaptee@gmail.com> REVIEW: 107127 FIXED-IN: 2.13 M +6 -0 src/main.cpp http://commits.kde.org/konsole/2b31d261519acb3c26e6c0369a7cbb0a8fc024e3
Git commit 11c1de4bb70ed70f97bc3bddc8422ff894829f38 by Kurt Hindenburg. Committed on 12/02/2014 at 16:20. Pushed by hindenburg into branch 'frameworks'. Add --separate command line Use a new process if --separate is used on command line. Similiar to --detach (from kuniqueapplication). Patch by Jekyll Wu <adaptee@gmail.com> REVIEW: 107127 FIXED-IN: 2.13 (cherry picked from commit 2b31d261519acb3c26e6c0369a7cbb0a8fc024e3) M +6 -0 src/main.cpp http://commits.kde.org/konsole/11c1de4bb70ed70f97bc3bddc8422ff894829f38