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