Disable restart of LibreOffice

Duncan 1i5t5.duncan at cox.net
Sat Oct 15 14:11:17 BST 2011

Jogchum Reitsma posted on Wed, 12 Oct 2011 17:31:26 +0200 as excerpted:

> I've looked in ~/.kde4/share/config/ksmserverrc, but didn't find any
> reference to LibreOffice (or OpenOffice).
> So how can I disable the restart of LibreOffice when logging in to kde?

That's usually the location (unless you've setup a specific startup 
launcher, see kde settings, system administration, startup and shutdown, 
autostart), but I suspect the binary goes by a different name.  However, 
I don't have libreoffice installed here, so I can't tell you what it 
might be.

Here on gentoo, I'd go about figuring that out by querying the package 
manager for the files belonging to the libreoffice package, grepping the 
output for bin, so as to only get application binaries.  Then when I knew 
what to look for, I'd check ksmserverrc again, and if not found there, 
grep all of $KDEHOME/share/*/* (with $KDEHOME substituted as appropriate, 
of course) for that name.

Alternatively, open ksmserverrc in a text editor and check the programN 
and restartCommandN lines (where N is a number), and see if any of them 
look like they might be the libreoffice binary.

Altho, correctly editing that file looks like it might be a bit of a 
hassle, so just blowing it away and manually starting what you want in a 
new session might be easier.  Plus, that way you can easily confirm 
whether that file is indeed the problem, or not.

BTW, you might just check the parallel location in system (as opposed to 
user) as well, probably /usr/share/config/ksmserverrc, tho it depends on 
the location your distro uses for kde.  Again, it's unlikely to be there 
unless you put it there, but it can't hurt to check.

If it's not ksmserverrc, then try the tried and true bisect method.  
Backup your whole $KDEHOME dir (which appears to be ~/.kde4 for you) and 
delete the working copy.  Try starting kde and confirm that you're fine.  
If so, you know it's in that kde dir.

There are two subdirs within that, both under $KDEHOME/share, that 
contain pretty much all kde's user config.  These are the config dir as 
you mentioned, and the apps dir.  So step two is blowing away the set of 
defaults kde created with the first test, and copying back everything but 
one or the other of those two dirs, and checking again.

Repeat the procedure, each time splitting the test space in half (if it's 
found in the config dir, test half the files in it, then half of the bad 
half, then half of that), until you get down to a specific file.  At that 
point you can continue within the file using a text editor if desired, or 
simply delete that file and reconfigure whatever it was that it set.

This procedure is rather brute force and does take some patience, but 
it's pretty good at finding the problem, at least if it's a single file 
triggering it.  Of course if the problem's complex, with two or more 
triggers, it doesn't work as well, but that's seldom enough the problem 
that the bisect method is an amazingly effective troubleshooting tool to 
have at your disposal.

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