KIconThemes: some additional details about themes & icons on Mac & MSWin
ClosedPublic

Authored by rjvbb on Jun 21 2017, 8:21 AM.

Details

Summary

This clarifies a few details about icons and icon themes on Mac and MS Windows, calling attention to the fact that icon themes can be available as usual and that embedded icon resources are thus not the only way applications can have access to such themes.

While not directly related I think this would also be a good place to draw attention to the fact that the usual

app.setWindowIcon(QIcon::fromTheme(appName)));

can have the opposite effect on those systems and should thus be avoided or use the QIcon::fromTheme() fallback argument

app.setWindowIcon(QIcon::fromTheme(appName, app.windowIcon()));

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped
rjvbb created this revision.Jun 21 2017, 8:21 AM
tfry added a subscriber: tfry.Jun 21 2017, 10:03 AM

It's difficult to explain a confusing situation, clearly, but I don't think you succeeded. AFAIU, there are three distinct approaches:
a) embedded icons
b) QIcon::setThemeSearchPaths()
c) patched libs

From the current wording I'm not sure, whether you do or do not want to hint at c) at all. For a) and b), I suggest the following wording:

On other platforms such as Windows and Mac OS, icon themes are not regularly part of the system,
though they are available through package management systems (like MacPorts, Fink and
Cygwin).

The deployment strategy for creating standalone applications on those operations systems is to either a) make sure the required icon theme is installed in a suitable (system) location, and use call QIcon::setThemeSearchPaths(), or b) to embed icons as a binary resource as follows:
rjvbb updated this revision to Diff 15688.Jun 21 2017, 12:34 PM

To be honest I didn't even think of patched libs, certainly not Qt itself. What I *can* think of is a platform theme plugin like the one from plasma-integration, which can serve a comparable purpose (including making the the call to setThemeSearchPath()) even with fully autonomous, standalone applications (cf. my osx-integration project).

I've followed your rewrite, but elaborated on it, and removed the somewhat confusing wording that combines the concept of standalone applications with a (shared) icon theme in a (system) location. While technically possible such applications aren't truly standalone.

Side remark: AFAIK only breeze-icons provides the BINARY_ICONS_RESOURCE option, at least in v5.35.0 . It would probably make sense to move the generate_binary_resource() macro from breeze-icons to the ECM, and make a beginning with the implementation of a few other convenience features for building projects for standalone deployment (a predefined macro to indicate the icon theme rcc to embed, but also something like the APPLE_STANDALONE_APPBUNDLE option I've used elsewhere). Mostly beyond the current scope though such changes would affect the text we're discussing here.

rjvbb set the repository for this revision to R302 KIconThemes.Jun 21 2017, 12:34 PM
tfry added a comment.Jun 21 2017, 1:52 PM

Much clearer, now, IMO.

Your osx-integration plugin is what I was thinking of, when writing about "patched libs". See, that's how confused I am, I just can't seem to remember any of this...

How about adding that detail, too, e.g.:

... provided that the location is registered by calling QIcon::setThemeSearchPath(), or a suitable platform theme "integration" plugin is installed and loaded.
rjvbb updated this revision to Diff 15694.Jun 21 2017, 3:04 PM

In fact any kind of plugin can do this that is loaded sufficiently early, or even an initialisation procedure in an additional library you link with (but that is maybe TMI and somewhat self-evident). I don't mind propaganda for my integration plugin but maybe here's not the most appropriate place ;)

rjvbb set the repository for this revision to R302 KIconThemes.Jun 21 2017, 3:04 PM
tfry added a comment.Jun 22 2017, 7:17 PM

Looks good to me.

This place is talking about how to get icon themes working, and so it should list the most relevant approaches. Arguably, this is not the place where I would have looked for an answer to that question, first, but since it does provide an answer, it should try to answer it good.

rjvbb added a comment.EditedJun 23 2017, 8:14 AM

Well, somehow this wasn't closed automatically:
https://commits.kde.org/kiconthemes/ac5cbf6b4aa969542a780077213cb39a4c110fe6
Edit: you should have accepted the revision for that to work, I guess...

Arguably, this is not the place where I would have looked for an answer to that question, first, but since it does provide an answer, it should try to answer it good.

Evidently, that was also my intention.

Which makes me wonder: is it possible to deploy a stylesheet that tweaks a built-in style via an auto-loading plugin, and could such a plugin take care of setting an icon theme path?

This revision was automatically updated to reflect the committed changes.

As Phabricator does not host the repositories it polls them periodically based on activity in the repository. For KIconThemes this is about once an hour.
The system has now polled the repository and the hook has correspondingly been triggered.

Ben Cooksley wrote on 20170623::09:17:33 re: "D6309: KIconThemes: some additional details about themes & icons on Mac & MSWin"

The system has now polled the repository and the hook has correspondingly been triggered.

I see. Does that mean you have rolled something yourself and could technically make it trigger also on a more compact key that's more in line with the other keywords (and easier to remember, more resistant to typos)?

All the tooling and functionality i've described is provided by Phabricator itself. We don't have any control over that (without codebase changes, which i'm strongly against due to the speed of development of Phabricator)