Adding Andreas as cc:, given he semi-maintains the oxygen icons.

Am Freitag, 9. Februar 2018, 17:49:54 CET schrieb René J. V. Bertin:
> Friedrich W. H. Kossebau wrote:
> > Am Freitag, 9. Februar 2018, 10:07:35 CET schrieb René J.V. Bertin:
> > > Two questions arise:
> > > - why are they there so many more than there are png icons (= what are
> > > they
> > > used for)?

Too focussed on the second question, I missed this one. Hm, doing a quick 
incomplete ls -1 | wc -l on some categories I would rather see more PNG files 
per size than SVG files.

IIRC the scalable folder simply contains the raw data/sources used to generate 
the PNG versions, kept there as source material for any further icons or 
modification of existing ones.

Andreas should know actually :)

> > > - where are the instructions on how to install (only) the
> > > scalable version?
> > SVG versions no longer need handcrafted substitutes) that would not really
> > be recommended, so no-one has yet added support for that.
> I actually discovered the existence of the scalable icons because of
> "oxygen- icons5-scalable" packages provided by Fedora and Arch.

That is a decision of downstream then, compare e.g. the custom code to install 
the SVGZ icon data done for Arch:

Possibly something to discuss with them, either their decision to also provide 
the scalable icons to the user makes sense, if the rendered results are 
acceptable, or something to ask them to revert, if the rendered result results 
in visual glitches and leaves a bad impression of Oxygen/KDE.
(From what I tested, the latter seems more sane to me, but needs full 
investigation by someone using the stuff in reality)

Given you seem a user of Arch or Fedora as you found those packages, you might 
want to pick up this task?
Andreas, what would do you think about those downstream approach to the Oxygen 
SVG files?

> Can we assume that QIcon will use the bitmap version if it exists for a
> given size?

If the implementation of the QIconEngine deployed (e.g. by the Plasma 
integration QPlatformTheme) correctly implements the algorithm as defined by
then yes.

> If so, installing the scalable versions as well shouldn't hurt
> the smaller icons on normal resolution screens, while still given the best
> quality where even on those screens a large/huge/humongous icon size is
> used (think application icons in the app switcher on Mac).

"Best quality" deoends on the capabilities of the SVG renderer deployed by the 
QIconTheme. As you found yourself, chance is that not.

> > indeed at least QSvg seems to fail on some icons by a quick test, so that
> > might be the reason.
> Yeah, I also thought it might be a work-in-progress; I noticed some of those
> too:
> view-list-tree.svg
> qt.svg: link use5411 hasn't been detected!
> qt.svg: tab-close.svg:6352: Could not resolve property: radialGradient3709
> qt.svg: document-new.svg:602:58: Could not resolve property:
> linearGradient5167 qt.svg: document-open.svg:4290: Could not resolve
> property: pattern5614 qt.svg: document-open.svg:4290: Could not resolve
> property: pattern5626 qt.svg: document-open-folder.svg:4224: Could not
> resolve property: pattern5614 qt.svg: document-open-folder.svg:4224: Could
> not resolve property: pattern5626

IIRC it is less work-in-progress, but simply due to mismatch of SVG features 
used to do the Oxygen icons and of what the deployed SVG runtime renderer, 
i.e. typically the QSvg* one, officially supports.

"Qt supports the static features of SVG 1.2 Tiny."

While the Oxygen icons make use of more SVG features to achieve the desired 
look. That's why even the higher sizes are installed pre-rendered as PNGs.

So unless someone works on deploying a more powerful runtime SVG renderer or 
someone works on trying to port all the SVG features used in the Oxygen icons 
to SVG 1.2 Tiny (might not be even feasible), this situation is simply a given 

> Inkscape only complains about document-new.svg ("unknown type: ns:sfw").

Which version of inkscape?


Reply via email to