oxygen icon name clasheroo

Jonathan Riddell jr at jriddell.org
Mon Mar 28 10:49:55 UTC 2016


I'm coming across more of these clashes.  Just had one in Calligra.
So yes I think it's a good idea to move the frameworks Oxygen icons to
a new path.

Jonathan


On 21 March 2016 at 08:30, Harald Sitter <sitter at kde.org> 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
>
>> 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. What we could do is make
> oxygen-base a standalone theme and link "oxygen" with "oxygen-base"
> through inheritance.
> That's not quite as good though because we want to override
> application icons through the actual theme. So what we would need is
> "oxygen-base" to be the selected theme and then inherit "oxygen"
> (where apps install icons) to be the fallback. Since the uid of a
> theme is its folder name and we can't feasibly change that without
> breaking something that's not really useful either.
>
> That said, we could go down the two theme route and simply accept that
> applications that install to "oxygen" will be overriding consistent
> theme icons from "oxygen-base". I'd rather deal with the directories
> approach outlined above.
>
> HS
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


More information about the Kde-frameworks-devel mailing list