In D21076#676560, @rjvbb wrote:

You must be right about the greyscale effect; I don't see any actual calculation of the intensity (from the RGB values) in the code that gets installed. And that code is JavaScript (aka QtScript); up to you to determine if your effect could be implemented in that language...

I have no idea how it works, but I imagine you create the build locally, possibly with the help of kpackagetool, and then upload it to some KDE server.

In the end, try to update KDE itself. I'm sure glitches were worse when I was using KDE 5.14. KDE 5.17 is definitely better

In D21076#676555, @rjvbb wrote:

As I understand 3rdparty binary effects are harder to install, very unpopular and it will take 100 years to get it packaged in all distros...

It should be possible to package this as an add-on desktop effect that people can install at will:

In D21076#676552, @rjvbb wrote:

That's with the translucency effect for menus set just 1 tick non-opaque. The effect gets less the more opaque menus are made, but it seems wrong. My widget style and colour palette specify a white menu background and my colour correction profile clearly doesn't affect white noticeably.

Are you sure you applied the newer patch? One with the tex *= modulation line in icc.frag? Also are you sure you installed the resulting libkwin4_effect_builtins.so correctly?

I got this one: https://github.com/vitalif/kwin/commit/83d69c928574de388d8f27ec6948f307b4eab3f2.patch following the link to your github repo you posted earlier, but I see no occurence of that modulation pattern in that commit. In fact, I now see that it looks like an old commit - so where is that newer one?

It doesn't work either for me with KWin 5.15.5 and that doesn't seem to be because of one of the other few effects I have activated.

still doesn't seem to work together with KWin's translucency-when-moving effect for me (with KWin 5.13.3; patch applies cleanly except for the inexistent effects kcm). And after a few KWin restarts the correction has either "stuck" or isn't being applied anymore.

Updated for 5.17.5 + added "modulation" usage

I like solutions that work right here right now. Waiting for all apps to do color correction on their own is utopism. Sometimes I just turn the effect off when I don't need it.
I'm not "working" on color correction, I mean it's not a continuous process :) I don't have much time to develop it further, make it fit guidelines or patterns.
I NEEDED full-screen color correction and I solved my problem with this effect. I use it 24/7.
Sometimes there are glitches, for example sometimes the taskbar flickers and so on, but these are always there with KWin as I understand so they don't bother me much.
By the way, I've updated the patch for KDE 5.17 + fixed it to work with translucency effects correctly (I didn't use "modulation" in the previous version of the patch).
It's on github: https://github.com/vitalif/kwin ... OK I'll upload it here too ...

How to wrap it into a custom deleter? It's an internal pointer type of LCMS... Even a custom class with destructor seems simpler...

So, can you merge it? :)

It being impossible would certainly be a very compelling reason to do it at this layer instead. I would support something along these lines if that's the case.

Though your comment doesn't match the docs I've seen on the colord site. I'll poke a Mutter dev and see what they're doing.

If we are going to do all windows, what does this offer over xcalib?

Yes, I know. I even tested it 5 or 6 years ago. I think that implementation was really clunky because it depended on Oyranos which is unavailable in most distros, and instead of being implemented as an effect it was patching shader code of other effects before compiling them. There was a whole 2 or 3 screen long function that was doing it. My implementation is much simpler and it only depends on LCMS2.

Removed translation, commented code and curly braces style

Thanks! :) OK, I'll remove translated text