[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kdelibs 3/kdebase 4 co-installable ?
From:       David Faure <faure () kde ! org>
Date:       2007-10-15 23:03:38
Message-ID: 200710160103.40070.faure () kde ! org
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]