![]() Registered Member ![]()
|
Hello,
I am rolling out KDE to a large group of users. We are currently on CentOS5.4, and so using KDE 3.4. As such we want to keep each users KDE related stuff in ~/.kde3.4 However after setting KDEHOME to ~/.kde3.4 for each user, Kmail still seems to create a .kde/share/config/emaildefaults file. I have checked a number of test users, and kmail is the only program using this directory, which makes me think it's not respecting the KDEHOME variable. Everything else seems happy to use ~/.kde3.4 Does anyone know if this is correct? Are there any work-arounds? Thanks Nick |
![]() Administrator ![]()
|
KDE 3.4 is a *very* old release. You should update to KDE 3.5, and use KDE PIM from the Enterprise3 branch.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
![]() KDE Developer ![]()
|
Hmm, strange, all uses of KDE config are usually going through the same mechanism.
Can you check that it does that when you run KMail from a shell that has the correct environment? Make sure that no KMail process is running, otherwise it will just reactivate the running one. Cheers, _
anda_skoa, proud to be a member of KDE forums since 2008-Oct.
|
![]() Registered Member ![]()
|
Hi Anda_skoa,
When you say the correct environment, I assume you mean with the various KDE ENV's pointed to their correct locations. The interesting thing is our users don't use Kmail at all, we use Thunderbird or Exchange Webmail. Just the fact of logging in using KDE seems to create the ~/.kde/share/config/emaildefaults file Nick |
![]() KDE Developer ![]()
|
Right. Sometimes applications run in a different shell environment than one would expect. For example KMail starts only once, every further invocation just activated the already running instance. So only the environment variables encountered by the first instance matter. Another common mistake is to set variables "too late", e.g. in shell config files that are only ready be interactive shells. When checking their value in, for example a Konsole window, they seem to be correct, but startkde is not running in an interactive when started through a login manager and thus has a different environment. One easy way to check is ALT+F2 env > /tmp/kdeenv and then checking this file Cheers, _
anda_skoa, proud to be a member of KDE forums since 2008-Oct.
|
![]() Registered Member ![]()
|
Ah ok, so none of the KDE dirs are set if I go to the text console using Alt + F2
so that could be the issue. I just thought it was strange that KMail was the only app doing this. I imagined other apps would also start around the same time as it so would also have the same problem, but they don't seem to. I guess I could always prevent kmail starting up considering we don't use it. Cheers Nick |
Registered users: Bing [Bot], Evergrowing, Google [Bot], ourcraft