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

List:       kde-devel
Subject:    Re: [Bug 111915] no crystalsvg key_enter.png available in 32x32
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2008-05-08 4:34:01
Message-ID: 482282B9.1060603 () acm ! org
[Download RAW message or body]

Kevin Kofler wrote:
> On Thursday 08 May 2008, James Richard Tyrer wrote:
>> kdeartwork-4.0.3-3.fc9.i386.rpm 
>> crystalsvg-icon-theme-4.0.3-3.fc9.i386.rpm
> 
> Those 2 packages are both built from kdeartwork-4.0.3-3.fc9.src.rpm.
> We have split crystalsvg-icon-theme into its own subpackage so
> kdelibs3 can require it.
> 
> We could easily build crystalsvg-icon-theme from kdelibs3 instead (or
> just put it back into the kdelibs3 package itself), but that would
> mean we won't have a version with the KDE 4 names at all.

You don't have a CrystalSVG version with KDE-4 names.

>>> This doesn't work when packaging. When packaging, we do one RPM
>>> from the kdelibs 3 sources and one from the kdeartwork 4 sources,
>>> and the RPMs are not allowed to have conflicting files.
>> This is obviously not true.  What is true is that when that happens
>> and an update is performed that the files from the newer RPM
>> overwrite the files from the older rpm.  There is no problem with
>> the old and new icon names because the new name will not overwrite
>> the old name.
> 
> That's what happens if we ship only one crystalsvg-icon-theme. But if
> you drop support for KDE 3 apps from the KDE 4 version, we'll have to
> either ship 2 of them and deal with conflicts, or ship only the KDE 3
> version.

There aren't any conflicts in the crystalsvg-icon-theme because with all
of the icons in the package where there is a difference, the package has
the KDE-3 names (with only a few < 10 exceptions).

>> However, I still think that since this is not an issue if you build
>> from source that this is just a packaging issue.
> 
> I disagree. Most of your users will not build KDE from source,

That isn't the point.

> they will be using somebody's packages. While making things easy to
> build from source is a worthwhile goal, IMHO making things easy to
> package is much more important.

Yes, it would probably be better for KDE to address this issue rather 
then every distro doing it houseparents.  OTOH, every distro might want 
to do it their way.

>> If KDE needs to support this, we need to provide a script and data
>> to make the symbolic links in whatever icon theme the script is
>> pointed at.
> 
> IMHO that would be the ideal solution, it would also make it easy to
> use other KDE 4 icon themes with KDE 3 apps.
> 
>> It is not a question of CrystalSVG being the default for KDE-3
>> since if you install KDE-4 then the default theme is Oxygen and the
>> KDE-3 apps are finding the CrystalSVG icons because they have the
>> old names.
> 
> The real issue is not that it's the default, but that it's the
> fallback, i.e. the last resort, in which icons have to be if we don't
> want them to show up as broken.
> 
Actually, Hi-Color is the fallback.  CrystalSVG only works due to what I 
regard as a bug.

IAC, nobody is going to remove the CrystalSVG icons with the KDE-3 names 
from SVN so you will always be able to obtain them.  AFAIK, CrystalSVG 
is basically unmaintained except for the "index.theme" file.  There are 
very few changes to the icons.  Well, yes I did make one this week, but 
that is an exception.

-- 
JRT


-- 
JRT
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]