Re: [kde] How to not restore a konqueror session? (KDE4)
- Date: Mon, 28 Sep 2015 21:36:08 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde] How to not restore a konqueror session? (KDE4)
Thomas Michalka (MLs) posted on Mon, 28 Sep 2015 17:17:48 +0200 as
> 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.
More info: http://www.kde.org/faq.html.