This means applications developed with Qt and KDE Frameworks that integrate well with the KDE Plasma desktop but are not restricted to it.
Many of this applications not just aim to work well on Linux & BSD or other open source operating systems but are ported and working well on the rather different Windows and macOS desktop. Some even are successful since years in the official Windows Store.
The above applications are part of the KDE Gear releases, but the described issues and solutions naturally are not restricted to stuff released with that.
What most of these applications have in common is that they rely on rather large parts of our Frameworks.
With that they depend at least indirectly on an icon set that covers large parts of what our default icon set Breeze provides.
Even if you use no icons from that icon set yourself in your application, just using the standard actions or many widgets/dialogs from Frameworks will rely on some subset of Breeze.
Below a screenshot of Kate 24.02 running on Plasma 6. All icons are there, they are properly re-colored for the dark theme, too, including not just the used Breeze icons but for example the small Git icons in the left sidebar that Kate has bundled.
After covering Plasma and the two large closed-source desktop operating systems, as a small excursion, look how Kate (the KF5 based version) looks if installed on [Haiku](https://www.haiku-os.org/) with the package they provide.
I was unable to trigger Kate or Okular to adjust to the dark mode GNOME provides, therefore I can not test if we end up with black on black icons there, but it is likely, as the fallback is just Breeze.
Just unreadable icons, beside out own Git icon and the few colored ones.
## Summary: What's up with Icons today
The icons in KDE applications do look perfect on KDE Plasma.
That should be no real surprise as many people working on these applications will test them there and KDE Frameworks and Qt are well tested on Plasma, too.
The icons look fine on Windows and macOS, too, at least for applications that got properly ported, but only thanks to patches we do in Craft.
If you just grab e.g. Kate's and the needed frameworks sources from our normal repositories, you don't get that.
If the maintainers of the port for some OS do care, like the Haiku people, KDE applications can look fine there.
On other desktop environments it doesn't look that great out of the box.
Unlike for the other operating systems, there the same packages without extra patches are running.
Whereas that works perfect on Plasma, we rely too much that the desktop environment running provides an icon set that has a similar coverage and naming as Breeze. As we don't hard depend on the Breeze icons for our applications, it can even happen that just no fitting icons are there per default.
Even if that can be solved with some better package dependencies, you still end up with a patchwork look and without a Qt platform theme plugin that handles the needed recoloring to make dark mode feasible.
We have more or less all needed parts to fix the situation, we did already fix it during [the porting to Windows and macOS](https://kate-editor.org/post/2021/2021-03-07-cross-platform-light-dark-themes-and-icons/).
* We have the Breeze icon set as Qt resource inside a library and link with that. That makes them a hard build and runtime dependency and easy to deploy.
* We ensure the icon engine we have in our KIconThemes framework is there and used.
* We enforce the Breeze Qt style. (this is not really icon related, but ensures an usable look'n'feel, too)
The first and the last thing are easy to do on Linux and Co., too, even with still allowing the user to override the icon set and style, but still defaulting to Breeze.
The second point is harder, as that requires at the moment a few hacks and is not 100% as good as going the Qt platform theme plugin route we use inside Plasma.
For KDE Frameworks 6.3 we worked to get that done.
See our [meta issue on our GitLab instance](https://invent.kde.org/frameworks/kiconthemes/-/issues/3) covering that topic.
All is not perfect, we will need to get some Qt API to fully do that, but the current state is already usable.
Here a comparison with the state as we have it now in our released software compared to with the state in the current master branch on an Cinnamon desktop.
* trigger initialisation of proper application style
*/
KStyleManager::initStyle();
#else
/**
* For Windows and macOS: use Breeze if available
* Of all tested styles that works the best for us
*/
#if defined(Q_OS_MACOS) || defined(Q_OS_WIN)
QApplication::setStyle(QStringLiteral("breeze"));
#endif
#endif
...
}
```
In the long run, once 6.3 is the minimal version the application depends on, this is just:
```cpp
#include <KIconTheme>
#include <KStyleManager>
int main(...)
{
/**
* trigger initialisation of proper icon theme
*/
KIconTheme::initTheme();
QApplication yourAppInstance(...);
/**
* trigger initialisation of proper application style
*/
KStyleManager::initStyle();
...
}
```
At the moment KIconTheme::initTheme() is still a bit hacky until we have proper Qt API, but that is not visible for the API user.
If we get this properly done in our applications, that will not just solve the current issue for running them in other desktop environments.
With that API in use and the now already upstreamed patches, one can build vanilla Frameworks and Kate on Windows and macOS and the icons will just work in the resulting application bundles and you get an usable style out of the box if Breeze is there.
## Help Wanted!
We have now some API to help our applications to be more usable on non-Plasma installations and Windows and macOS.
We still need to make use of it and we need to improve the implementation and upstream to Qt the needed extra API to make it a real 100% replacement to what we do with the Plasma integration plugin.
If you have time to help us, show up on [our meta issue](https://invent.kde.org/frameworks/kiconthemes/-/issues/3).
Not just coding is needed, we for example have still a few icons that [don't recolor well](https://invent.kde.org/frameworks/breeze-icons/-/issues/17), help to fix that is wanted, too.
