Hello Harald,
The breeze-icons.rcc file comes from breeze-icons.git when option(BINARY_ICONS_RESOURCE "Install a Qt binary resource file, containing breeze icons") is ON.

It's officially supported. Intended approach for packagers shall be to package the single file separately from the 3 times bigger archive with 5100 SVG files and let app developers to choose.
(2 times more if also Dark variant is installed but that's another matter, Dark variant should not exist if we eventually have colorizing).

Furthermore, another matter is what icon themes are supported by Kexi 3's style. It's only Breeze for now, by design, on any OS. I am not hiding this fact and am open for contributions of missing icons for other styles.

What does file count have to do with anything though? Everything but kexi uses the theme files, so the rcc is a waste on top of that. The rcc simply makes no sense in a platform scenario as we have on Linux. The entire platform uses one single thing, only kexi is the odd one out and needs its own thing. Hell, even if that wasn't the case from a platform perspective we always need to ship the SVG icons unless KIconLoder and QIcon learn to resolve via the rcc as through the present APIs we are implicitly bound to supply XDG icon theme resolution.

I do not see the link between only breeze being supported and the rcc file. You can coerce a specific icon theme inside the application by telling KIconLoader/QIcon which theme you want.

That's another discussion, I offered a space for contributions. The project does not support theming in version 3.0.

The .rcc resources is official approach supported for Qt apps, truly cross platform (eventually it works on Windows and Mac without "simulating" Linux environment) and Kexi is more a Qt app since version 3 than it was before. We have no KDE apps anymore as we say from time to time as well.

I also believe the summary of this report is a bit misleading because Kexi does not duplicate anything, it uses official option for graphical resources. It also adds very own files in its private resource file and uses that in an official way via the icon loader.

"I do not see the link between only breeze being supported and the rcc file. You can coerce a specific icon theme inside the application by telling KIconLoader/QIcon which theme you want."

The rcc file allowed the control and it's a consistent approach to other platforms so the effort is smaller. Also 3 kexi-derived libraries in separate repos (kdb, kreport, kproperty) all use or will ultimately use the same approch to avoid requiring 2*5100+ extra files at runtime by a 200KiB lib.

We need a linux-only patch and a whole testing effort before it's safe to believe that things you mention work 100% works on Linux environments, not only on Plasma 5. *Without* integration plugins. I think you agree that the inconvenience you're reporting, while I see it as valid, is of lesser importance than having actually running and usable app with icons as designed.

Thanks for understanding.

The Qt way is to ship the rcc with your app. Do that and I probably wouldn't even care.

"The Qt way is to ship the rcc with your app. Do that and I probably wouldn't even care." 

I did in version 2.90 but in the meantime good thing happened, the rcc file is generated by KF5 so  I don't need to.

Is shipping N copies of the rcc files with N variants of Kexi (or derivatives) better in your opinion that declaring a runtime dependency to one, always the same file?

Kexi should be using the system icon theme to begin with. Shipping a huge RCC file is a horrible idea, no matter what ships it.

Thanks for the opinion.

I think it was explained what appplication-defined icon theme is. Similar examples are: LibreOffice or Inkscape themes. System icons set don't include app icons set. Contributors are invited to add more sets to kexi and these can be supplied as supplementary packages.

KEXI does not ship global icons. Plugin system would come in 3.2.