I am not sure where this can be fixed actually. If its a gentoo related bug or
if it is something the program author can fix. This is related to the files
installed by the ebuild. After building the files installed include
/usr/bin/ksplash. (this is expected. It is supposed to overwrite the old
ksplash executable). However apparently, on kde startup, the ksplash executable
in /usr/kde/3/bin/ksplash is the one that is run. So in effect, ksplash/ml
never really does anything. To fix this, I made a link to the /usr/bin/ksplash
from the /usr/kde/3/bin/ksplash. Version of ksplash-ml is 0.95.2. Resides in
It's not just ksplash. It's kile, too. cf.
Basically this bug is a result of the new kde-env system. If you install ksplashml or any
of the new theme engines for it (ie win2k or os X) on a bare system they will not work
at all since kde looks for splash screens in KDEDIR and not in the install prefix the
simpelest fix is to have the ksplash-ml and ksplash-ml-themes ebuilds install to KDEDIR
and not prefix.
It's always been a big bother that kde doesn't provide a way to use a custom
splashscreen without replacing the default ksplash binary.
I'm going to modify startkde so that instead of running ksplash, it runs
$KDESPLASH if defined. (Or something like that...) Then, ksplash-ml would
install into /usr and install an env.d file that would set
KDESPLASH=/usr/bin/ksplash. Of course, if we add another ksplash replacement to
portage, the user would have to shuffle the env.d files himself, or set his
preferred value in .bashrc.
How about it?
This only happens with the ebuild. If you get the original source package from the home page, the files get properly installed under /usr/kde/3. If everything related to kde goes under /usr/kde/3, I don't see as a good idea to keep installing KSplash/ML in /usr/bin and then use a KDESPLASH environment variable to start the right splash screen manager.
No no, you've got it all wrong.
Only the kde-base packages versions 3.0.x go in /usr/kde/3. Other versions go
into /usr/kde/$ver(major.minor) i.e. /usr/kde/3.1.
Everything _else_ that's kde-related, incl. kslpash-ml, goes in /usr so that it
is accessible to all the KDEs installed.
Naturally only the ebuild does that, on its own ksplash-ml wants to install
into the kdelibs dir.
*** Bug 8337 has been marked as a duplicate of this bug. ***
OK, solution ready. I'm committing a new kdebase-3.0.3-r1 that implements this
fix. It also requires the new revisions of ksplash-ml and ksplash-ml-themes I'm
committing. These are all masked for now, please test them.
I've also mailed the ksplash-ml author and the kde-devel mailing list and the
consensus seems to be that ksplash-ml will go into the kde cvs once the 3.1
tree is open, replacing the old ksplash. Which is definitely good news :-)
> Everything _else_ that's kde-related, incl. kslpash-ml,
> goes in /usr so that it is accessible to all the KDEs installed.
Can someone explain to me how the applnk stuff fits into all this? Should kde
also be looking in /usr/share/applnk? ( Because 3.0.X doesn't seem to )
-- Bryn / Curious
All the themes are listed twice, except Classic,
Default, Gentoo, XpLike, ksplash_gentoo.
If you select either Gentoo or ksplash_gentoo the theme you get is
Preview Theme does nothing
Ruskin's problems are solved btw, we discussed them on gentoo-dev. The
remaining one is the preview not working. This is because the ksplash kcontrol
module just runs "ksplash" and since KDEDIR comes before /usr in the path (so
set by startkde), the old ksplash is run which of course doesn't work.
The ksplash-ml source should be patched to run the ksplash that lives in the
same kde prefix as the kcontrol module. Only I've never written kde apps, so I
don't know how to do this the kde way. But I'll find someone to do it.
Bryn: kde 3.0.x _should_ be looking in /usr/share/applnk, definitely. Are you
sure it doesn't? (You say "doesn't seem to", so I'm asking you to find out :-).
Maybe run kbuildsycoca or something? Look at the value of $KDEDIRS in the kde
env (i.e. alt+f2 and "echo $KDEDIRS > myfile") and make sure it includes /usr.
> Bryn: kde 3.0.x _should_ be looking in /usr/share/applnk, definitely. Are you
> sure it doesn't? (You say "doesn't seem to", so I'm asking you to find out :-).
I will reinstall KDE tonight and check this out. :-)
( I was planning on going out anyway. ;-)
OK, I'm working on my bugs again, finally :-) I've mailed the ksplash-ml author asking about the Right Way (ie wrt kde coding conventions) to fix the preview issue. He'll probably want to include the fix upstream.
*** Bug 11403 has been marked as a duplicate of this bug. ***
I'm moving all bugs to firstname.lastname@example.org so all kde@gentoo developers can see them.
Oh and I didn't send that mail after all (I wrote this comment before actually doing so and then
didn't send it). Sorry for all this, I''ve been away from Gento matters for some time but am
now catching up and will try to resolve this issue at some point.
Note in passing, ksplash/ml was integrated some time ago into kde proper and will be part of
kde 3.2, replacing the old ksplash.
Closing this bug as it has been put into kde 3.2.
If someone has the strong desire to patch this program/ kde 3.1, then please reopen and
assign it to yourself.
Dead old bug left to close...