oxygen icon name clasheroo

[David Faure]

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.
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)
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.....

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5