Hi,<br><br>In trying to fix other startup related issues, I discovered that if you lauch Konsole from within Konsole, the session parameters of that second session are not restored on reboot.<br><br>The second instance of Konsole is started with KUniqueApplication::NonUniqueInstance, which triggers some code inside KUniqueApplication to create a separate instance.. including session saving. So after shutdown, there are two files for Konsole in ~/.kde/share/config/session.<br>
<br>On reboot, ksmserver asks for the launch of Konsole twice, each with a -session parameter that can be used to load the session file. The second instance of Konsole fires up, sees that it is a second KUniqueApplication instance, and sends the command-line arguments over to the other instance via DBus, which causes the creation of a new window. However, the set of command-line arguments sent over DBus is deliberately stripped of the -session argument (on both send and receive) so the first instance of Konsole isn't made aware that there is another session file to restore.<br>
<br>The effect of this is that the second instance of Konsole starts with a default session, no matter how many tabs you had open to what dirs. Launching a useless instance of Konsole seems buggy, so as I see it there are some options:<br>
<br>1) Pass the session information over to the first instance via DBus.<br>2) Prevent the session being saved for instances created with KUniqueApplication::NonUniqueInstance.<br>3) Create a command-line option tested in forceNewProcess and (optionally?) saved with the session. This would address <a href="http://lists.kde.org/?l=kde-core-devel&m=122948843508478&w=2">http://lists.kde.org/?l=kde-core-devel&m=122948843508478&w=2</a> as well.<br>
<br>I'm leaning towards 3, however both 2 and 3 will still cause Konsole to launch one more set of stray instances before the upgrade. I'm part of the way through a test implementation of 1, so it probably wouldn't bother me too much to finish it.<br>
<br>Thoughts?<br><br>~eli<br>