Icons theme is part of KEXI by design, since its ultimate goal is being a builder for self-contained apps not requiring Plasma. 
Uniform default look and predictable alternative look and feel is the goal. Think of similarity to https://develop.kde.org/ - this web page does not get the in-page icons replaced by, say, GNOME or XFCE icons but maintain the design by keeping the icons as designed.

Historically we implemented this by private resource but since then per request we started to re-use existing resource file if available. 
That is, on Unix and other targets that supply packaging of icons we re-use the KDE's resource. If unavailable, KEXI shall be distributed with own copy of the resource.

Look and feel of KEXI-generated apps (not just KEXI environment) is meant to be plugin based. Contributors who want to deliver other looks can do so by delivering and maintaining separate plugin packaged outside of KEXI (but it can be part of the repo of course). To extend the look and feel one needs to extend given QStyle as well -- the look isn't limited to just icons. Accepting all themes costed KEXI development days of work which never paid back. There's still lots of conditions in the source code we would like to remove.

This is from my memory and how I see it.

That's all good and nice, but the problem still is that kexi depends on the .rcc on buildtime and on runtime even on Linux/KDE where the icons should be available by the breeze icon theme anyway.

Currently kexi just fails to start if the .rcc is not installed. (and it fails to build either, if it's not there)

At least on openSUSE, we tried to get rid of the burden of building the .rcc as well. It was split out to a separate package just for kexi back then.

Maybe it would be possible at least to have a way to build it without that dependency, perhaps by a cmake option?

(In reply to Wolfgang Bauer from comment #2)
> Maybe it would be possible at least to have a way to build it without that
> dependency, perhaps by a cmake option?
Although, on second thought a cmake option might not even be necessary.
Maybe just use the standard icons if the .rcc is not available on build time?

Thanks for the bigger picture Wolfgang. IIRC back when we lacked the build-time check we had situations when KEXI was distributed without the dependency. Would you see a universal replacement technique to ensure declared run time dependencies are met? (other than mention in README.PACKAGERS that depends on human nature)

First thing we added was the runtime check. Before that missing icons was confusing to the user. Not it is confusing too, but at least we can warn in a message that the KEXI software isn't 100% properly distributed.

> Maybe just use the standard icons if the .rcc is not available on build time?

That is the central issue. Standard icons do not include icons that KEXI requires. So the software looks random and unfinished.
That's the cost of centralization (having a central icon project in KDE while we can't control "central" desktop environment).

(In reply to Jarosław Staniek from comment #4)
> Thanks for the bigger picture Wolfgang. IIRC back when we lacked the
> build-time check we had situations when KEXI was distributed without the
> dependency. Would you see a universal replacement technique to ensure
> declared run time dependencies are met? (other than mention in
> README.PACKAGERS that depends on human nature)

Not really, no.
Except that it would be possible to specify the runtime dependency in the cmake files, but that might get overlooked too...

> First thing we added was the runtime check. Before that missing icons was
> confusing to the user. Not it is confusing too, but at least we can warn in
> a message that the KEXI software isn't 100% properly distributed.

Well, it is not a warning, but an error.

Currently, Kexi just quits if the .rcc is not installed, even if the icons are available because the breeze icon theme is installed.

> > Maybe just use the standard icons if the .rcc is not available on build time?
> 
> That is the central issue. Standard icons do not include icons that KEXI
> requires. So the software looks random and unfinished.
> That's the cost of centralization (having a central icon project in KDE
> while we can't control "central" desktop environment).

Ok, you probably have a point there.
That was just a thought.

So maybe add a cmake option to build without the .rcc dependency, disabled by default? (or the opposite, have a cmake option to build with the .rcc dependency that is enabled by default)

Maybe @Fabian could make a suggestion as well here though.

> Well, it is not a warning, but an error.

Yes, the intent was such a verbose exit, which, for the branding reason at least, we see as better choice.

> Currently, Kexi just quits if the .rcc is not installed, even if the icons are available because the breeze icon theme is installed.

If I remember correctly the idea was to keep the logic as simple as possible (it's already hell of conditions) - not allowing secondary way to deliver icons, which itself users can override or have fall back (IIRC by testing some non-Plasma installations). Also IIRC, and to summarize, checking just icon theme name was not enough.

> So maybe add a cmake option to build without the .rcc dependency

Do you mean build-time dependency only? That would be possible to add because *you* on openSUSE know what you're doing so you're not going to abuse it. If someone would break things that's not our trouble...

(In reply to Jarosław Staniek from comment #6)
> > So maybe add a cmake option to build without the .rcc dependency
> 
> Do you mean build-time dependency only? That would be possible to add
> because *you* on openSUSE know what you're doing so you're not going to
> abuse it. If someone would break things that's not our trouble...

I actually mean a build time option to remove the .rcc dependency on buildtime *and* on runtime.
As you say, if we enable that option we know what we are doing and we know that we should add a runtime dependency on the breeze icon theme then...;-) (which we actually already have)

But of course that would also mean that kexi would then use the system's icon theme. (via KIconTheme or QIcon, I suppose)

TBH, I'm not sure how this is currently handled...

I've observed ugly fall back to hi color icons on XFCE for example :( So depending on fall back will leave us with bug reports like "Apps look ugly, how to bring consistent icons back" - something that is of worse to handle because solutions would be distro-dependent.

FWICT there's no effective difference between opening a breeze-icons.rcc from the system during runtime vs. using the "breeze" icon theme if installed. So using the Breeze system theme as fallback if the rcc file doesn't exist should work in pretty much all cases.

> (In reply to Jarosław Staniek from comment #9)
> I've observed ugly fall back to hi color icons on XFCE for example :( So
> depending on fall back will leave us with bug reports like "Apps look ugly,
> how to bring consistent icons back" - something that is of worse to handle
> because solutions would be distro-dependent.

Do you have some more info about those issues? Fallback should only happen if the icon wasn't found in breeze, but then it would be missing with breeze-icons.rcc as well.

Currently we 're 100% sure that KEXI runs when we have access to breeze-icons.rcc. So we do not have a situation when we mix e.g. GNOME and Breeze icons in one GUI. In the future when we have more KEXI-compatible themes (superset of some icon themes) fall back between themes will be possible. All what the general icon runtime can offer is fall back at individial icon level, what is exactly the source for look and feel inconsistency.

(In reply to Wolfgang Bauer from comment #8)
> But of course that would also mean that kexi would then use the system's
> icon theme. (via KIconTheme or QIcon, I suppose)
> 
> TBH, I'm not sure how this is currently handled...

Not necessarily, it does:

inline void setupBreezeIconTheme()
{
#ifdef QT_GUI_LIB
    QIcon::setThemeSearchPaths(QStringList() << QStringLiteral(":/icons"));
    QIcon::setThemeName(QStringLiteral("breeze"));
#endif
}

That should put it at the top of the list.

(In reply to Jarosław Staniek from comment #9)
> I've observed ugly fall back to hi color icons on XFCE for example :( So
> depending on fall back will leave us with bug reports like "Apps look ugly,
> how to bring consistent icons back" - something that is of worse to handle
> because solutions would be distro-dependent.

That shouldn't happen. Is this reproducible?

Yes, IIRC e.g. "table" icon was hi-color or gnome-like when some esoteric icon theme is set.

For the record, while I remember now: major reason towards using the rcc system came from the fact that it's resource-superior. On Windows our apps install much faster when we do not add hundreds of small icons files. This is actually good choice for any embedded / mobile system as well (even if you can't spot such KEXI versions in the public).

I also liked how the rcc based icon theme has precedence over whatever (possible outdated) icon theme is installed. Especially on Windows when someone managed to somehow install a traditional file-based icon theme I would find it hard to force "own" KEXI version to be used.

(In reply to Fabian Vogt from comment #12)
> (In reply to Wolfgang Bauer from comment #8)
> > But of course that would also mean that kexi would then use the system's
> > icon theme. (via KIconTheme or QIcon, I suppose)
> > 
> > TBH, I'm not sure how this is currently handled...
> 
> Not necessarily, it does:
> 
> inline void setupBreezeIconTheme()
> {
> #ifdef QT_GUI_LIB
>     QIcon::setThemeSearchPaths(QStringList() << QStringLiteral(":/icons"));
>     QIcon::setThemeName(QStringLiteral("breeze"));
> #endif
> }
> 
> That should put it at the top of the list.

If I understand that correctly, kexi should already use the breeze icon theme (when installed), even if the user selected a different one (or uses a different desktop than Plasma).

So then IMHO it should be sufficient to just remove the check for the .rcc, on Linux at least (or, as suggested, if some cmake option is enabled/disabled).

Yes for build time. So such option marked "for those who know what they are doing" would be a good help indeed. 

At run time, as I suggested the QIcon::setThemeName(QStringLiteral("breeze")) only declares a desire to use breeze, the only currently consistent theme. No way to validate what's really available at run time as long as we don't have package dependency kexi==>breeze-icons. 

I hope it's explained sufficiently...

(In reply to Jarosław Staniek from comment #15)
> At run time, as I suggested the
> QIcon::setThemeName(QStringLiteral("breeze")) only declares a desire to use
> breeze, the only currently consistent theme. No way to validate what's
> really available at run time as long as we don't have package dependency
> kexi==>breeze-icons. 
We as packagers can declare that dependency though, i.e. make the kexi package require breeze-icons.

So if you add a cmake option that's disabled by default (call it "YESIAMAPACKAGERANDIDIDADDABREEZERUNTIMEDEPENDENCYTOMYKEXIPACKAGE" if you want ;-) ), that would help already IMO.

If our kexi package requires breeze5-icons (that's how it is called in openSUSE) on a package level, a user cannot install kexi without the breeze theme.
Same as we currently have to make it require breeze5-icons-rcc (which contains the breeze-icons.rcc file).

Yes, once we have the option you can depend on either breeze5-icons or breeze5-icons-rcc. I guess for Linux you'll pick the former.
I would add these notes to the option's docs.

Thanks for the good chat, Wolfgang.

Changed the summary then

"Add build-time option to disable KEXI dependcy on breeze-icons.rcc"

(useful for distributions that properly set dependency on Breeze at package level)