From kde-core-devel Mon Oct 15 23:03:38 2007 From: David Faure Date: Mon, 15 Oct 2007 23:03:38 +0000 To: kde-core-devel Subject: Re: kdelibs 3/kdebase 4 co-installable ? Message-Id: <200710160103.40070.faure () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=119248965420919 On Monday 15 October 2007, Sune Vuorela wrote: > On 2007-10-13, Armin Berres wrote: > Some statistics based on a grep over a recent checkout of kde4. > > grep'ed as grep -r filename | grep -v \.svn > - emoticons used as filename in that case. > - kfile grep is piped thru | grep -v "#include" also > > > /usr/share/emoticons/Default/*.png > > appears to just be defined in: > kdelibs/kdecore/kernel/kstandarddirs.cpp Surely that can't be the only place... we have to install those emoticons too... Ah, there it is: kdeartwork/emoticons/set1/CMakeLists.txt:install( FILES [...] DESTINATION ${SHARE_INSTALL_PREFIX}/emoticons/tweakers.net ) Sounds like we need a cmake variable set by kdelibs for this stuff. But wait, how did the share/icons/* conflict get solved? AFAIK kdelibs3 and kdelibs4 + kdebase4-runtime all install into share/icons/*... Does this work simply because the default icon theme has changed? So the same fix cannot work for emoticons because the default theme is still, well, Default? The problem is: if we change the location of emoticons to, say, kde4/emoticons, then we have solved a small issue and we have introduced a much bigger one: existing emoticons themes (e.g. from kde-look) will not work anymore and will need to be updated... just because of this stupid "Default" theme conflict.... (A solution could be to have a shared package that both kdelibs3 and kdebase4-runtime depend on, but I can see how that makes the life of packagers complicated, for just some pngs... and it also assumes the default theme hasn't changed...) Ah there's the better solution: renaming the default theme to "kde4". Then it won't conflict, and it can coexist with existing themes from kde3 and kde-look. We just need to find the code which hardcodes "Default". I like this solution :) > > /usr/bin/imagetops > > seems to be used in a desktop and a xml file under > kdebase/runtime/kdeprint/filters/ > and in kdebase/runtime/kdeprint/kdeprintfax/faxfilters Hmmpf. This is part of the deprecated framework that is soon going to be removed from compilation I assume? (This isn't a question for you, but for the kdeprint guys :) > > /usr/bin/kcmshell > > used around 40-50 places in the code or so - and in a insane amount of > desktop files Yep. Fixed. > > /usr/bin/kfile > > can't any trace of this actually being used as a command anywhere? Yep, just an end-user tool. Renamed to kfile4; distros can always add a symlink when kdelibs3 is not installed I suppose (e.g. using the "alternatives" mechanism). > > /usr/bin/kdostartupconfig > seems to just be launched from different places inside kstartupconfig. > > /usr/bin/kstartupconfig > Seems to just be used in the startkde script. Yep. Renamed. > > /usr/bin/khotnewstuff > can't find any references to where this is used as a program. Thanks for checking, I wasn't sure. It's an end-user program then. Renamed. > > /usr/bin/ksvgtopng > > seems like not used at all? or is it actually something that could be > moved to -dev packages? Even though it is in kde4 in kdebase/runtime I have no clue about this. lxr says playground/multimedia/jukquiz/pics/Makefile.am was calling it, but that's it. So it sounds like an artist's tool; this is also what I thought when moving it to kdebase/runtime, but now I see your point, there's no -dev for a collection of helper binaries like kdebase/runtime :) Hmm, now what? Renaming it is the easy way out I guess. > > IMHO it is really really important to find a solution for this problem. > > I guess people would be quite annoyed when applications aren't ported to > > KDE4 yet, but they can't use the KDE3 applications. > > all in all, if I am correct, only thing looks hard is renaming kcmshell, > but if there is a script to mass-handle desktop files already, it should > actually be quite doable. There is a script already, it's called perl and grep :) > in general it at least looks easier than I expected. Yes it's easy ... when you don't do it yourself :-)) Hehe. -- David Faure, faure@kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).