| Summary: | Ksplash/ML installation problem | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Osei Poku <bomdigi> |
| Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
| Status: | VERIFIED LATER | ||
| Severity: | minor | CC: | bryn.davies, davidslists, tawesley |
| Priority: | High | ||
| Version: | 1.2 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Osei Poku
2002-08-15 07:51:23 UTC
It's not just ksplash. It's kile, too. cf. http://bugs.gentoo.org/show_bug.cgi?id=6728 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 Default. 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. ;-)
-- Bryn.
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 kde@gentoo.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... |
