Re: Requesting feedback on the creation of a virtual package for icon themes

[Fernando Lemos <fernandotcl@gmail.com>]

On Mon, Mar 5, 2012 at 3:22 PM, Sune Vuorela <nospam@vuorela.dk> wrote:
> On 2012-03-05, Fernando Lemos <fernandotcl@gmail.com> wrote:
>> Assuming the faenza icon theme does adhere to the fd.o icon naming
>> spec, I think there's not much we can do about this. Most likely, the
>> DE itself requires icons that are not defined by the standard. This
>> virtual package would only benefit packages that depend only on the
>> subset of icons defined in the spec.
>
> No. it is not a matter of neither not following the spec. You can have
> around 8 icons in your icon theme and be icon spec compliant. It just
> makes it virtually impossible for the user to know what to do with the
> icons.
>
> the standard basically says that
> 'if a icon foo-bar-baz-quux is requested' try the following files:
> foo-bar-baz-quux.[extensions]
> foo-bar-baz.[extensions]
> foo-bar.[extensions]
> foo.[extensions]
>
> and as long as you just provide a foo.png for all values of foo, then
> you icon theme fulfils the spec.
>
> then imagine I use that theme and request foo-bar and foo-bar2 and
> foo-bar3 and use them for 3 different actions, and then it is good
> enough if the icon theme just has a foo.png, then I get 3 similar icons.
>
>
> That's not a issue in the desktop environment and also not in the icon
> theme, but still it is not a good fit together.

Ah yea, that makes sense. Thanks for the heads up.

I spent a few hours thinking about possible solutions, and I don't
think we can even solve it at all. The naming spec allows this
genericity and specifies the necessary mechanism to gracefully degrade
the desktop experience in case the icon theme doesn't fully specialize
some icons, so what you described is an effect of the naming spec
itself.

If modern desktops don't look good with icons that are too generic,
then perhaps the specification itself should be revised. As an
example, if audio-volume-{mute,low,medium,high} should be different in
order not to break the desktop experience, then perhaps they should be
renamed to audiovolume{mute,low,medium,high} (even though it looks
horrible). That way, complying icon themes are forced to specialize.

All solutions I could think of would impose a huge burden to
maintainers (things like checking exactly what icons a program
requires may not be trivial). If nobody objects, I'd like to consider
the issue you mention orthogonal to the problem we're trying to solve.

Thanks once again,