Sorry for chiming in the discussion since I also have some related questions:
> Now let's see how we handle Windows and macOS: We patch a bit and ensure > we have a bundeled Breeze icons set as lib, enforce our icon engine and > enforce the Breeze style, as even with the latest native styles various > parts of Kate look bad. Isn't the reason we do this because FDO icon theme spec is not available on Windows (and maybe also macOS)? Qt 6.7's QIconEngine implementations introduced some polyfill to allow us access to the native icon libraries on both Windows and macOS, enforcing Breeze icon theme might not be that necessary for apps that only use a subset of icons. > We patch a bit While working on something related [1], I also found we did this by applying patches instead of doing it directly in the upstream source repo, are there any related documentation or discussion why it's in a "patch" form? Such resource might also benefit apps that are using KF but not using Craft as its build system. For example, you can see Kate on MSYS2's repo which also have similar icon issue, or see the discussion at [1]. [1] https://invent.kde.org/utilities/kcharselect/-/merge_requests/20 > First thing that is broken, is the re-coloring. Did we do the recoloring in KIconEngine? If so, maybe enforcing Breeze icon theme and style are not enough (i.e. we also need to enforcing the use of KIconEngine)? And, does it also need to be a patch? > And we provide still a way to overwrite that for the user IMHO we might want to provide the ability whatever we decided to enforce Breeze style or icon theme or not. It could be something similar to the current KColorSchemeMenu::createMenu() API but for icon theme or application style. - Gary
