kdelibs 3/kdebase 4 co-installable ?

David Faure faure at kde.org
Tue Oct 16 00:03:38 BST 2007


On Monday 15 October 2007, Sune Vuorela wrote:
> On 2007-10-13, Armin Berres <trigger at space-based.de> 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 at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




More information about the kde-core-devel mailing list