14 Nov
2011
14 Nov
'11
9:31 a.m.
I'm testing my 3.5.13 packages. I'm running Slackware 13.1 in a virtual machine.
Full stock installation.
KDE 4 is installed. All KDE 3.5.10 packages have been removed.
Every time I started Trinity the Akonadi server dialog appeared, the desktop changed to
KDE 4 Desktop View, and the KDE 4 file indexer started.
Long story short: I traced the problem to the Trinity startkde script.
The default 3.5.13 Trinity startkde script incorrectly sets the $KDEDIRS environment
variable and includes the /usr directory. That means KDE 4 apps start when starting
Trinity.
The $KDEDIRS environment variable is intended to be a user defined variable and should not
be set globally.
Further review of startkde shows duplication of code and some code in the KDEHOME section
that makes no sense.
Even if somebody explains why $KDEDIRS should be set in startkde, somebody still needs to
explain why /usr is in that path.
I will file a bug report. Before I do that I would appreciate comments and observations
from other people regarding startkde. Other people must be running into this same problem.
:)
Thanks!
Darrell
Darrell
14 Nov
14 Nov
3:05 p.m.
New subject: [trinity-devel] 3.5.13 Usability -- KDE 4 Takes Over
Le Sun, 13 Nov 2011 18:31:42 -0800 (PST),
Darrell Anderson <humanreadable(a)yahoo.com> a écrit :
I'm testing my 3.5.13 packages. I'm running
Slackware 13.1 in a
virtual machine. Full stock installation.
KDE 4 is installed. All KDE 3.5.10 packages have been removed.
Every time I started Trinity the Akonadi server dialog appeared, the
desktop changed to KDE 4 Desktop View, and the KDE 4 file indexer
started.
Long story short: I traced the problem to the Trinity startkde script.
The default 3.5.13 Trinity startkde script incorrectly sets the
$KDEDIRS environment variable and includes the /usr directory. That
means KDE 4 apps start when starting Trinity.
The $KDEDIRS environment variable is intended to be a user defined
variable and should not be set globally.
Further review of startkde shows duplication of code and some code in
the KDEHOME section that makes no sense.
Even if somebody explains why $KDEDIRS should be set in startkde,
somebody still needs to explain why /usr is in that path.
I will file a bug report. Before I do that I would appreciate
comments and observations from other people regarding startkde. Other
people must be running into this same problem. :)
If you use the
kdeetc3-3.5.13-noarch-1.tgz package I already sent to
the list, there is the /etc/profile.d/kde3.sh script which sets the
KDEDIR (without the 'S') variable to /opt/kde3 (just adapt it
to your actual Trinity installation prefix).
You can then prevent Plasma from loading by
$ unset KDEDIRS
before running /opt/kde3/bin/startkde: it is set by the KDE4 Slackware
packages in /etc/profile.d/kde.sh. Trinity will then use the KDEDIR
variable that is set, in my case, to /opt/kde3.
(in fact if you keep this KDEDIRS variable you will also have other
issues, such as broken Konqueror home page and half-broken
translations because the KDE4 ones will be used)
But the KDE4 autostart files (and then, kmix and akonadi)
in /usr/share/autostart will still load, it's a known problem.
As a final note, the /etc/profile.d/kde.sh script will not break KDE4
since KDEDIRS has precedence over KDEDIR.
Thanks!
Darrell
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
8:10 p.m.
New subject: [trinity-devel] 3.5.13 Usability -- KDE 4 Takes Over
If you use the kdeetc3-3.5.13-noarch-1.tgz package I
already sent to
the list, there is the /etc/profile.d/kde3.sh script which
sets the
KDEDIR (without the 'S') variable to /opt/kde3 (just adapt
it
to your actual Trinity installation prefix).
You can then prevent Plasma from loading by
$ unset KDEDIRS
before running /opt/kde3/bin/startkde: it is set by the
KDE4 Slackware
packages in /etc/profile.d/kde.sh. Trinity will then use
the KDEDIR
variable that is set, in my case, to /opt/kde3.
(in fact if you keep this KDEDIRS variable you will also
have other
issues, such as broken Konqueror home page and half-broken
translations because the KDE4 ones will be used)
But the KDE4 autostart files (and then, kmix and akonadi)
in /usr/share/autostart will still load, it's a known
problem.
As a final note, the /etc/profile.d/kde.sh script will not
break KDE4
since KDEDIRS has precedence over KDEDIR.
I understand what you are explaining.
Background: I already had disabled the Slackware kde.sh (KDE4) script. I was starting X
from run level 3 and before starting X with startx I confirmed KDEDIRS was not set. The
problem is the way the Trinity startkde script is written. That environment variable is
supposed to be user defined and not globally defined. The Trinity startkde script adds
/usr to the KDEDIRS path, which causes the KDE 4 problems.
I have been using KDEDIRS with 3.5.10 for several years to store local changes I prefer
that always take precedence over any upstream changes from KDE or Slackware. Now that the
Trinity startkde script is modifying that variable I don't know what other effects
that will have.
If having the Trinity startkde script set KDEDIRS is a hack to create a compatible
environment with KDE 4, then I think this is the wrong approach. With that said, I will
modify the Trinity startkde script one way or another. Unsetting KDEDIRS is wrong because
if end users want to define that variable the Trinity startkde script will be negating any
such effort.
I stopped having problems with KDE 4 apps starting after I deleted the startkde code
setting KDEDIRS.
Darrell
8:26 p.m.
New subject: [trinity-devel] 3.5.13 Usability -- KDE 4 Takes Over
Le Mon, 14 Nov 2011 05:10:44 -0800 (PST),
Darrell Anderson <humanreadable(a)yahoo.com> a écrit :
I did this in my .xinitrc (I launch X manually) so the
unsetting of
KDEDIRS was local in my case.
If you use the
kdeetc3-3.5.13-noarch-1.tgz package I
already sent to
the list, there is the /etc/profile.d/kde3.sh script which
sets the
KDEDIR (without the 'S') variable to /opt/kde3 (just adapt
it
to your actual Trinity installation prefix).
You can then prevent Plasma from loading by
$ unset KDEDIRS
before running /opt/kde3/bin/startkde: it is set by the
KDE4 Slackware
packages in /etc/profile.d/kde.sh. Trinity will then use
the KDEDIR
variable that is set, in my case, to /opt/kde3.
(in fact if you keep this KDEDIRS variable you will also
have other
issues, such as broken Konqueror home page and half-broken
translations because the KDE4 ones will be used)
But the KDE4 autostart files (and then, kmix and akonadi)
in /usr/share/autostart will still load, it's a known
problem.
As a final note, the /etc/profile.d/kde.sh script will not
break KDE4
since KDEDIRS has precedence over KDEDIR.
I understand what you are explaining.
Background: I already had disabled the Slackware kde.sh (KDE4)
script. I was starting X from run level 3 and before starting X with
startx I confirmed KDEDIRS was not set. The problem is the way the
Trinity startkde script is written. That environment variable is
supposed to be user defined and not globally defined. The Trinity
startkde script adds /usr to the KDEDIRS path, which causes the KDE 4
problems.
I have been using KDEDIRS with 3.5.10 for several years to store
local changes I prefer that always take precedence over any upstream
changes from KDE or Slackware. Now that the Trinity startkde script
is modifying that variable I don't know what other effects that will
have.
If having the Trinity startkde script set KDEDIRS is a hack to create
a compatible environment with KDE 4, then I think this is the wrong
approach. With that said, I will modify the Trinity startkde script
one way or another. Unsetting KDEDIRS is wrong because if end users
want to define that variable the Trinity startkde script will be
negating any such effort.
I stopped having problems with KDE 4 apps starting after I deleted
the startkde code setting KDEDIRS.
Do the KDE4 kmix and akonadi still start on
Trinity launch ? The
startkde code never set KDEDIRS for me since I use the /opt/kde3
prefix, and the /usr/share/autostart files are still interpreted by
Trinity.
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
8:54 p.m.
New subject: [trinity-devel] 3.5.13 Usability -- KDE 4 Takes Over
I did this in my .xinitrc (I launch X manually) so
the
unsetting of
KDEDIRS was local in my case.
I was using a separate /etc/profile.d script. Same effect. :)
Do the KDE4 kmix and akonadi still start on Trinity
launch
? The
startkde code never set KDEDIRS for me since I use the
/opt/kde3
prefix, and the /usr/share/autostart files are still
interpreted by
Trinity.
Neither starts anymore after I edited the Trinity startkde. Looking at my process list in
konsole indicates no KDE 4 apps running.
Darrell
4827
days inactive
4827
days old
4 comments
2 participants
participants (2)
-
/dev/ammo42 -
Darrell Anderson