oxygen icon name clasheroo

[Harald Sitter]

On Thu, Mar 31, 2016 at 9:47 AM, David Faure <faure at kde.org> wrote:
> On Monday 21 March 2016 09:30:02 Harald Sitter wrote:
>> On Sun, Mar 20, 2016 at 10:08 AM, David Faure <faure at kde.org> wrote:
>> > On Wednesday 16 March 2016 15:57:45 Harald Sitter wrote:
>> >> Hola!
>> >>
>> >> Our most awesome icon maintainers wanted to carry over icon symlinking
>> >> from breeze to oxygen, alas that turned up a whole slew of
>> >> compatibility problems.
>> >>
>> >> examples:
>> >> https://bugs.kde.org/show_bug.cgi?id=360605
>> >> https://bugs.kde.org/show_bug.cgi?id=360510
>> >>
>> >> # Problem
>> >> In kde4 software people used oxygen as the standard icon set and
>> >> installed their own icons there. Since breeze covers all icons ever,
>> >> replicating its coverage into oxygen means we have a million conflicts
>> >> with (older?) tarballs of existing software that also install icons
>> >> into oxygen under the same name.
>> >>
>> >> # Proposal
>> >> We could get rid of this and all future conflicts if we shift the
>> >> default oxygen icons into a subdirectory.
>> >>
>> >> So, we install the default icons to
>> >>
>> >> $prefix/share/icons/oxygen/base/22x22
>> >> $prefix/share/icons/oxygen/base/32x32
>> >> $prefix/share/icons/oxygen/base/...
>> >>
>> >> applications can thus continue to install to
>> >>
>> >> $prefix/share/icons/oxygen/22x22
>> >> $prefix/share/icons/oxygen/32x32
>> >> $prefix/share/icons/oxygen/...
>> >>
>> >> without conflicting with our base files what so ever.
>> >>
>> >> Downside of this is that the index.theme basically needs to list
>> >> everything twice (once for base and once for main directory), which
>> >> unfortunately incurs a bit of a runtime overhead. This is a bit of a
>> >> crap situation we are in and I can't think of another solution to
>> >> this.
>> >
>> > This doesn't sound like it matches the freedesktop.org icon theme spec.
>>
>> How so?
>> https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
>>
>> Directories
>> list of subdirectories for this theme. For every subdirectory there
>> must be a section in the index.theme file describing that directory.
>>
>> e.g. Directories=base/32x32/actions,32x32/actions
>>
>> and then Table 2. Per-Directory Keys
>>
>> [base/32x32/actions]
>> Size=32
>> Context=Actions
>>
>> [32x32/actions]
>> Size=32
>> Context=Actions
>
> Ah, OK, I didn't know the spec allowed such things.
>
>> > But if you rename oxygen/base/ to oxygen, and oxygen/ to hicolor, then it does, AFAIK....
>>
>> We can't really change oxygen/ at all, that's kind of the problem.
>> Since existing apps install stuff into oxygen/ and expect it to be
>> used by default in a kdelibs4 context.
>
> Right. I think we're still paying the price for an earlier mistake.
> Apps should have kept installing their icons into hicolor rather than oxygen.

Yes, absolutely. This should resolve with KF5 porting though.

> AFAIU it's what the spec intended. But then when KDE switched to oxygen
> the apps did the same, and this is what put us in the mess we're in right now.
> I just wonder if we shouldn't pick a solution that transitions back into
> something sane, where all apps (made by KDE or not) install into hicolor again.
>
> It makes no sense to have no icon for KDE apps in an environment which doesn't
> use the oxygen icon theme...
>
> But yeah this is more long term thinking. Short term your solution sounds like
> it would work. I just worry that long term it only makes things worse. Every 5 years
> we add another layer of complexity
> (hicolor, then hicolor+oxygen, then hicolor+oxygen+breeze, now hicolor+oxygen+oxygen-base+breeze)

Ah! We've learned though. Breeze does not actually inherit from Oxygen
anymore. Breeze is a completely standalone theme at this point and
only inherits from hicolor.
The VDG purposefully made the breeze theme have 99.9% coverage across
pretty much all our applications (and third party ones), it fully
themes all icons we had in kdelibs4 times (regardless of whether they
were in oxygen or the applications). So we'd have to continue
compatibility for Oxygen, but it ends there.

> Now some apps will start installing some stuff into breeze, right? ;)
> And in 5 years we'll add another layer on top, and we'll have to keep all of these existing 4 layers
> for compatibility, because apps will start to install stuff into any of these 4.....

Moving forward we could be pro-active WRT this. I am thinking:
1) Make ECMInstallIcons have a hardcoded list of cmake projects that
may install to breeze (namely: breeze-icons). CMake warn vigorously if
a project that isn't one of those hardcoded ones wants to install to
breeze.
2) Have build.kde.org check installed files and make sure nothing is
installed to share/icons/breeze either.

This way we could discourage everyone from doing it and double sure
that we don't do it in our own applications.

Right now I have no app that actually installs to breeze at all, so
perhaps we have a globally better understanding of how to install
icons properly already.

HS