#248 PekWM support for setting NET_WM_WINDOW_OPACITY hint

Reported by: wallex Assigned to: pekdon
Phase: release-0.1.13 Component: windowmanager
Type: enhancement Status: closed
Priority: 3: Medium



This patch (against git-HEAD, 12.03.2010) implements support for setting the opacity hint to windows under various conditions. This hint enables true transparency of windows when a composite manager (eg: xcompmgr) is running alongside PekWM.

Opacity is set in two places: in the autoproperties file (for general windows) and in the config file (for the harbour, menus and workspace indicator).

In the autoproperties file, the property takes the format of: Opacity = "focus, unfocused" (eg: Opacity = "1.0, 0.5").

In the config file, it is defined like this:

In the Screen section, WorkspaceIndicatorOpacity = "value"

In the Harbour section, Opacity = "value"

In the Menu section, FocusOpacity = "value" and UnfocusOpacity = "value" are used.

I know it seems a bit inconsistent, but my original idea was to use a single entry to specify the opacity (ie: like in the autoproperties), however this didn't prove to be the best approach for the config related settings.

Also, all the code is protected by the define OPACITY. I don't know how to mess with configure files, but there needs be added the config option "--enable-opacity" which should define OPACITY when compiling to get it enabled (currently I just manually add the define in pekwm.hh :/).

I can further change this if the requests are sensible :)

PS: Please add a patch to this task, as I can't do it and the pastebin link will expire in a month.




23:44:28 changed from open to closed



Nevermind my previous comment, you ninja-posted me ¬¬

Anyway, I took a look at the updated code, and gave it a test-run, it seems that all is working correctly now. I have no qualms with the state of the code neither. Thanks and good job!

PS: If you want, the only thing missing is to remove all "#ifdef OPACITY" defines.


I wonder if the opacity variables are best left as "unsigned int" or "uint32_t," the later is "precise" according to the EWMH specification, whereas the former is more in style to Pekwm (since using the latter types require inclusion of <stdint.h>).

@Io: Also, I thought you wanted to get rid of floating-point arithmetic? You left Config::parseOpacity(double value) with floating point math! I updated that function to be:

uint32_t Config::parseOpacity(int value)  {

    if (value >= 100) {

         return EWMH_OPAQUE_WINDOW;      }

    if (value <= 0) {
        return 0;
    return (uint32_t)(value*(EWMH_OPAQUE_WINDOW/100));


Which isn't exact, but gives a very good approximate conversion, still avoiding floating point math.


Okay, I pushed some patches that should allow for the 0-100 range and the patch for the documentation. Please check if the configuration options work as expected now.


Pekwm uses the range 0-100 for font opacity in themes, so probably should use the same. It should be more than enough fine grained.

Also, if we want to handle named opacities we probably could setup pre-defined variables such as $OPACITY_50 etc, but I think 0-100 should be sufficient.


Thank you for the documentation patch. I commit it when the range issue is settled.

Atm I favour to expose the complete range to the user directly. I think that's the easiest way and it is not that you edit your config every day. We can give some examples like 0x0 for 0%, 0x55555555 for ~33%, 0x7FFFFFFF for ~50%, 0xAAAAAAAA for 66% and 0xFFFFFFFF for 100%. This way pekwm doesn't have to do any conversion and the user can utilize the complete range.



Here's the documentation patch for the introduced features. I assumed the maximum value for opacity is 100.


Duplicate work ¬¬ I just finished a patch that does the same xD


Anyway, I thought leaving the Opacity range to 0~100 would make the most sense user-wise. The only thing I don't like about the current state of the code is how variables like _harbour_opacity are stored as [0..100], and each time you need to use them they must be converted with:

uint32_t long getHarbourOpacity(void) { return Config::parseOpacity(_harbour_opacity); }

But I wouldn't know how to get around that issue since the range is different, and CfgParserKeyNumeric doesn't allows a custom data transformation function.

Ah well, I suppose I can write some documentation.



Thanks for the offering! I did 1. and 2. already, but I highly welcome a patch for the documentation. Just look under doc/config for the xml files that generate the documentation and add the description of the new options there. Thanks in advance.


I also thought about removing some of the #ifdefs. Please look at #285 and tell me what you think about it.


On #ifdefs, I would go for removing all #ifdefs on features that does not have any extra build dependencies.


Hey, I am still alive, and can work on this. Replying to Io's comments...

1. I can change the unsigned long to "uint32_t" variables. I presume that a sensible range is 0~1000 (even though 0.0 to 1.0 allows as much precision as you can want...)

2. Hmm, PWinObj::setOpaque needs not be virtual, seeing how there's an implementation in PWinObj.cc :/ (hey, I haven't touched C++ in a long time, so I had to relearn a lot to get this thing working).

3. About opacity and the "toggle opacity" action, this came to be because of how I use Pekwm. For instance, I may like having some default transparency value for most windows, but at particular times (eg: browsing a site like deviantArt) I need to disable the transparency to properly appreciate the site, before turning it back on. It is true that letting the user specify the actual new transparency value would be possible and perhaps more potent, but to me this ended up being more cumbersome than a toggle. In the end, it is a design decision based on user's patterns (and we'd need feedback from more users before knowing what is 'best').

4. The reason _opacity [focus/unfocused/current] is set in the PWinObj class rather than Client/Frame can be seen by searching for setOpacity: Harbours: The "DockApp" instances also need their opacity set. PMenu/WorkspaceIndicator: they need opacity set

Basically, since PWinObj is meant to be "an object that will be mapped to a window," it makes sense that the opacity data is there. The only cases where the values are "inherited" (and thus, your redundancy argument) are for the Harbour (DockApp's inherit from Harbour) and the Frame (Frame inherits from active Client). I am not sure there's a better design here, but I am open to suggestions.

5. How do I go about writing the documentation?

PS: I do prefer to leave the --enable-opacity configuration, not everybody may need this, and you also have things like --enable-jpeg and --enable-harbour, which you could also argue should be left built-in.

I'll get back with a patch when I apply the changes I agree with.


I'll push some cleaning up patches later, but in the meantime please look at #259 again.

08:48:36 changed from Andreas to Claes Nästén

There seems to be quite a few that uses a composition manager out there with great success, including xcompmgr. However, there are also alternatives to that such as Cairo Composite Manager.



I am not sure if we really want to encourage users to use xcompmgr at all. On my system (radeon opensource driver) xcompmgr causes graphical artifacts, sometimes a transparent window even disappears completely while dragging it, which makes it unusable for me. Does anyone know if it is still under active development?


I pushed this patch without much modification to get the original code in, and also as it's ifdefd it should disrupt the main code.

The patch have some other things are calculating the values on use and not on load.

But sure, if you want to keep this issue open until the issues below are resolved.

I'll remove the ifdefs.

16:38:28 changed from closed to open

I reopen the task, because I see some issues/questions with this patch:

Why does it use "unsigned long"? The proposal for _NET_WM_WINDOW_OPACITY specifies it as a 32bit value.

Also, I would prefer not to have floating point arithmetics. Restricting the configuration values to a lower integer range should suffice.

Why is PWinObj::setOpaque(bool) virtual?

If we have to have an action that affects the opacity (ACTION_STATE_OPAQUE), why not let the user specify the opacity value explicitly? But do we need that at all? I am for removal and leaving the settings to the autoproperties.

Can Opacity::focused and Opacity::unfocused be moved to Client and Opacity::current to Frame? Perhaps I overlook something, but it seems like there is some unnecessary data duplication atm.

Please no additional #ifdef/#endif. IMHO we should either support it or not.

And last but not least, there is not documentation for the new configuration options.



Close from commit: 9fcd34e062c1f9865a63e9aa3638130fedff1f65 by Claes Nästén

19:19:15 changed from new to closed
15:42:19 attached PEKWM-OPACITY-0.2-2010-06-07.PATCH

Attached updated patch to this issue.




This is an updated version of the patch. It applies cleanly to Pekwm 0.1.12, and I believe it also applies cleanly to GIT-HEAD.

It has two new features:

- Support for { Actions = "Toggle Opaque" } (so you can bind a key to turn off/on transparency on the active window).

- Support for the configure script (so now you can enable opacity without code changes, just configure with --enable-opacity).


22:34:45 attached PEKWM-OPACITY-0.1-2010-03-12.PATCH

Attached the patch from pastebin.



Oh, I should add the only pending work it has: reflecting changes upon a config reload. Currently you must restart PekWM.

I am not sure what would be the best way to update the changes, since it requires a broadcast to all active windows, the harbour elements, all menus and the workspace... @_@