How to not restore a konqueror session? (KDE4)

Duncan 1i5t5.duncan at cox.net
Mon Sep 28 22:36:08 BST 2015


Thomas Michalka (MLs) posted on Mon, 28 Sep 2015 17:17:48 +0200 as
excerpted:

> anybody there who knows where I can configure konqueror to prevent it
> from restoring its last session?
> 
> Background: Since KDE4 I get all konqueror windows twice on a new login.
> I assume one from the KDE Session Management, one from konqueror's own
> restoring mechanism.  KDE3 didn't have conflicts by restoring windows.

See if this is it...

KDE systemsettings > system administration > startup and shutdown > 
session management > on login section.

Presumably you have it set to restore previous session, which is what you 
want in general if you want other apps restored.  But as something else 
is restoring konqueror already, you don't need the session restore 
mechanism to restore it as well.

So add it to the exclusions list. =:^)


Meanwhile, something that I've wondered about this exclusions list, that 
hasn't been clear to me, and that the help button doesn't appear to help 
with, as I get a "documentation not found" error...

When populating this exclusion list, am I supposed to use the executable 
name, some bit of the window name (imprecise and thus unlikely), the name 
of the *.desktop file, or whatever name appears in the menu (which comes 
from a line in that *.desktop file)?  For some apps, all these things are 
different, so it matters.

And in some cases I have wrapper scripts (bash) that do some setup, 
environmental variables, perhaps changing the working dir, etc, before 
calling the normal (elf) executable.  In this case, if I'm listing 
executable, do I want to list the shell script wrapper, or the elf/X 
binary?  Does it matter if I exec the elf/X binary so execution transfers 
directly from the shell script using the same PID, instead of launching 
it separately so both are running?

"Inquiring minds want to know!" =:^)

I generally do get it to work, but sometimes it's only by brute force 
after some trial and error, listing a number of different variants from 
the list above, since I don't know which one it's actually going to try 
to match.  Maybe it matches on more than one?

Some hints beyond the bare "Applications to be excluded from sessions:" 
label could be very helpful! =:^)

FWIW, superkaramba was a big problem in this regard for me.  Somehow, it 
seemed I either got multiple instances of my theme running, or 
superkaramba itself would start without loading my theme, only a popup 
asking me what theme to load.  I eventually got it to work, but only 
after well hacking things, starting it with a wrapper script I have in 
the startup dir that specifically feeds superkaramba the theme to load as 
a parameter, while listing both superkaramba and the superkaramba.sh 
wrapper script in the sessions exclusion list, AND loading a separate 
"popcloser.sh" script from the startup dir as well, that looks for the 
theme-loader popup and immediately closes that window when it finds it.  
That does seem to work, but what a pile of hacky shell scripts and 
session exclusions I had to create to get it to do so!  Something tells 
me it's supposed to be simpler than that!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.


More information about the kde mailing list