Detailed dependencies of frameworks on external resources like icons

[Friedrich W. H. Kossebau]

Hi,

are there any plans to document which external resources like icons are 
exactly needed by the individual framework modules?

Problem:
Imagine a developer planning to use KDE frameworks to write a program for a 
platform with no proper package system, so all deps of the program need to be 
co-packaged with the program.
How can that developer know which icons (and in which sizes) need to be 
packaged as well, given the frameworks used by the program?

Simply saying "all of oxygen icons" might not be the best, if you look e.g. at 
the sizes of openSUSE's Tubleweed packages of the Oxygen icons:
 oxygen-icon-theme-4.13.3-4.1.noarch.rpm          PNG, no 128x128     9.7M
 oxygen-icon-theme-large-4.13.3-4.1.noarch.rpm    PNG, all 128x128   19M
 oxygen-icon-theme-scalable-4.13.3-4.1.noarch.rpm SVG               234M
With high resolutions getting fancy, this will blow up the size of the package 
to rather non-acceptable sizes.


Partial solution in Calligra:
Two years ago, to fight the number of "unknown" icons appearing in the UI and 
reducing duplicated icons in the Calligra repo itself, some macros have been 
introduced in Calligra, to tag all icon name ids being used in the program, so 
automatic extraction and processing is possible, using gettext:
https://projects.kde.org/projects/calligra/repository/revisions/master/entry/KoIcon.h

Using these macros needs discipline, because nothing (as in: compiler) 
enforces the use of them. But so far it worked out, unkwown icons are seldomly 
seen now, and lots of icons duplicated from the Oxygen iconset could be 
removed. The script for checking duplicates, unused or unknown icons is 
https://projects.kde.org/projects/calligra/repository/revisions/master/entry/devtools/iconcheck/iconcheck.py

Just, this did not help with finding those icons used directly from kdelibs. 
So the single installer Windows packages created for Krita have been larger 
then needed, due to playing safe and shipping more or less also the complete 
Oxygen icons.

For mobile platforms with limited resources in bandwith and storage size not 
really acceptable.


Has this been discussed before? What would you propose how to deal with this 
problem? Would such macros make sense for frameworks for the described 
problem? How to collect the info which sizes of the icons might be only 
needed?

While talking about that at Akademy, Patrick von Reth had the good idea that 
this macro could also be used to alternatively resolve to qrc:/ resource 
links, to automatically support program variants where icons are stored 
internally, without a need to rewrite any reference. So someone packaging an 
app X could compile the used and co-packaged frameworks with some proper flag 
to tune the macro resolution to what would be needed.

Cheers
Friedrich