kmms (media-sound/kmms) now works with kde3. I only tested with kde3. kmms should work with kde2 as well, but I didn't know how to say that in the ebuild, so this ebuild won't work for kde2 without the "need-kde" bit being changed. I also added some text about needing to copy the Skins manually. Hopefully that's clear.
Created attachment 4927 [details] ebuild for kmms-0.8beta1
Created attachment 4928 [details, diff] patch removes the need to manually copy the skins Okay, this patch removes the need to manually copy the skin to ~/.kmms/Skin. Users can still override the default by copying a new skin to ~/.kde/share/apps/kmms/Skin.
Created attachment 4929 [details] new ebuild to go with above patch This is an updated ebuild which applies the above patch and no longer prints the message about having to copy the skin. This obsoletes attachment 4927 [details]. Bugzilla won't let me obsolete it myself though.
After talking with Luiz Paulo, the current maintainer of kmms, I have realised that my patch breaks backwards-compatibility for any user who already has a non-default skin installed --- they would have to copy their skin somewhere else, and the change is not documented. However, I still think the patch is not without some merit, because it does give you a working kmms straight away, without intervention on behalf of each user. If you think this is a good thing, I can change the patch so that it provides the fix while preserving backwards compatibility.
Hmm.... I'll install your ebuild and play with it. I'm afraid of the two options regarding skins tho--I want kmms to handle them automatically (the descriptions of what is going on both here and at the kmms page, http://luizpaulo.virtualave.net/kmms/ , are not that clear to me), and I want kmms not to choke when my skin is non-default at the start. So that places me in the category of people who would (perhaps?) value your proposed patch? It allows auto-skin configuration *and* allowing the non-default start skin? !! Thanks for the RFC...
Ah! Got it working. But... the skin doesn't match my xmms skin, unless of course I used the default xmms skin... Ahhhhh.... looking at your patch, it is more clear to me now. Your patch does a one-time copy of the default skin to the user's ~/.kmms/Skin dir, but that copying/updating does not occur when xmms changes *its* skin. Wonder if there is an api (like the one that kmms hooks into already to control xmms) that can listen for a skin change event? Hmm.... Wish I had more time to put into this... "works for me" now. Final note: at the state of the patch supplied, you'll have a working kmms but with only one skin in it; you'll have to update the skin yourself manaully whenever you change xmms's skin (uuugh). Cool, well, still a needed and awesome patch! Thanks for getting us going smoothly with gentoo + kde 3.1 + xmms + kmms :)
That's not quite what happens. The patch uses KDE's builtin stuff to find the skins . . . as I understand it at the moment, it will search first in ~/.kde/share/apps/kmms/Skin, then it will look in /usr/kde/3/share/apps/kmms/Skin. If you currently have a skin installed in ~/.kmms/Skin, you will need to make a link from ~/.kde/share/apps/kmms/Skin to there. Now probably the best way to go at this stage would be to add ~/.kmms/Skin to the search path in order to maintain compatibility with the "official" kmms. Luiz Paulo (the current maintainer of kmms) is planning on adding some kind of skin browser which would look in the following paths: xMMS main folder)/Skins (HOME)/.xmms/Skins (KMMS KStandardDir)/Skin (HOME)/.kmms/Skin Once he does this, my patch will become obsolete . . . given that it's a stop-gap measure I should really change it to keep the compatibility (although I think ~/.kde/share/apps/kmms is a more appropriate directory). I've got exams coming up though, and my kmms works for me, so it's a low priority at the moment. On the other hand it should be easy to do, so you never know . . .
Created attachment 5361 [details, diff] replaces previous patch, keeps backwards compatibility Okay, this obsoletes patch 4928. It allows kmms to work properly first time with no user intervention, AND it keeps compatibility with the main KMMS tree by enabling the user to put their own skin in ~/.kmms/Skin.
Chris, regarding what you were saying with regards to keeping the kmms skin in sync with the xmms one . . . xmmsctrl.h has the following: gchar *xmms_remote_get_skin(gint session); Some kind of "sync skin to xmms" option in the kmms setup might be appropriate. But that's beyond the scope of this bug. :)
Created attachment 6182 [details] latest ebuild stuff for kmms This ebuild incorporates the above features, but adds another patch to fix a nasty memory leak which occurs because xmms allocates memory for the track title, but kmms previously never freed that memory. I forwarded the patch to the kmms maintainer last week, but have not yet heard back from him.
I'm sorry it took me so long to get to this ebuild. It's just that new ebuilds and updates were on low priority for a long time, first because of the stability freeze, then because of the kde 3.1 release. You've done a great job with kmms here. Nothing left for me to do except test things :-) I've committed the latest ebuild + patches with a ~x86 keyword. Please look at it and tell me if anything still needs doing. I changed your ebuild somewhat. In particular I removed the KDEBASE setting. Here it works very nicely when installed into /usr, like the other kde apps. What problem did you have with that? (This is kde 3.1rc5, haven't tested with kde 3.0.x yet, but should be ok there as well.) We don't need to add kde2 support to new ebuilds, noone really wants it anyway AFAIK. Also I added a dependancy on xmms.
Dan, I'm running kdelibs-3.0.4-r1 and kdebase-3.0.4-r2, and with your ebuild, kmms doesn't show up in the Add->Applet menu when I right click on the panel. If I add 'export KDEBASE="true"' to your ebuild, then I can load xmms through this menu.
Setting KDEBASE makes it install into the KDEDIR not into /usr. Which is against general Gentoo policy,a dn I see no valid raeson to make this an exceptio. Anyway, it works for me from /usr :-) You probably need to run kbuildsycoca, or restart kde or something of the kind, to make it see the kmms applet and add it to kicker's menu. (I had to, too.) Please try again if you haven't yet made sure it's not a cache/per-run config problem.
Created attachment 6418 [details] kmms broke and my panel looks like this Okay, I re-emerged with your ebuild, and then after logging out of KDE and coming back in, I had kmms in the menu. Now I have a new problem. When I add kmms to the panel, it doesn't paint anything. I just have a blank space on the left hand side of the klipper icon. I will look into this further and report back. The only difference I can think of is that I upgraded to gcc 3.2.1 last night (from 3.2). But I assume you're using 3.2.1 as well . . .
Hmm . . . I tried using my old ebuild and that doesn't work either (not that I expected it to). Perhaps the problem is due to the fact that between the last (working) kmms and this new one I upgraded to QT 3.1? I know it's supposed to be compatible but . . . I may try re-emerging kdelibs and kdebase 3.0.4. It's tempting to go to 3.1-rc5, but that won't really tell us how to fix the problem I'm having now.
Update: I've re-emerged kdebase and kmms and that hasn't fixed my problem. I'll try re-emerging kdelibs and maybe xmms, but really this is just easter egging . . . do you know what the best way to debug this would be?
Grr . . . I've re-emerged xmms and kdelibs, still no good. Dan, did you compile this with gcc 3.2 or 3.2.1? Have you heard of QT 3.1 breaking any other kicker applets? I don't know what else it could be.
I'm using qt 3.1 and gcc 3.2.1 (for some time now, so everything here is compiled with it, but that shouldn't really matter?) and the kmms applet works in both kde 3.1rc5 and 3.0.4. You can run a kicker applet independant of the panel itself by running 'appletproxy kmms.desktop'. See if that gives any output. If not, try compiling kmms with debug info and trace the appletproxy run and see what it's doing. Oh and xmms itself does work, right? :-) (A silly question but one never knows)
Ah, that helps. I get: toojays@hiro$ appletproxy kmms.desktop kdecore (KLibLoader): WARNING: library=libkmms: file=/usr/kde/3/lib/libkmms.la: /usr/kde/3/lib/libkmms.so.1: cannot open shared object file: No such file or directory appletproxy: WARNING: cannot open extension: libkmms because of /usr/kde/3/lib/libkmms.so.1: cannot open shared object file: No such file or directory appletproxy: ERROR: Failed to load applet DSO: libkmms On further inspection, it seems that my old install wasn't unmerged properly---as you can see, libkmms.la is still in /usr/kde/3/lib. The .so file is not there (i.e. it was unmerged properly). I deleted /usr/kde/3/lib/libkmms.la, and now it is finding the correct libs in /usr/lib. It works fine now :) Thanks Dan.
OK, then this can be closed. kmms is in ~x86 profile now, will be moved to stable in time.
