*** Bug 1950 has been marked as a duplicate of this bug. ***

Some other ideas for use of composite:

- add drop shadows to *windows*, perhaps menus as well,
- make windows translucent when dragging and/or resizing them,
- set arbitrary transparency to windows via bindings
- mini window previews
- alt-tab (?)
- expose

Looking at Keith Packard's transset utility source, all it does is set an atom in the window: "_NET_WM_WINDOW_OPACITY", xcompmgr and likely beryl too does the rest. see http://webcvs.freedesktop.org/xapps/transset/

So a mouse or key command to change that, would not add new build requirements to openbox. an rc.xml entry like that wasnt too far away?

  <mousebind button="A-C-S-Up" action="Click">
    <action name="Opacity">
      <add>0.1</add>
    </action>
  </mousebind>
  <mousebind button="A-C-S-Down" action="Click">
    <action name="Opacity">
      <subtract>0.1</subtract>
    </action>
  </mousebind>

Peter

The _NET_WM_WINDOW_OPACITY hint seems to only work if you set it on the to level frame window, making the decorations transparent too.  I'm not sure that's what we want.  It's a mean-time type of solution, but it's kinda hacky and you can already  do it with transset. So I don't know..

xcompmgr also doesn't seem to catch the hint every time, somehow.

% xprop -frame |grep OPACITY
_NET_WM_WINDOW_OPACITY(CARDINAL) = 3865437797


% xprop -frame |grep OPACITY
_NET_WM_WINDOW_OPACITY(CARDINAL) = 3865437797


One is on a visually transparent window, and one isn't. It just didn't make the other one see-through.  And it appears completely random.

I think we'll leave this out for now, until we do it ourselves properly.

We could possibly use _NET_WM_WINDOW_OPACITY during move/resize, but that would break people's use of transset - or at least make race conditions.. hm..

some ideas from kwin4:
* present windows - this is just expose.
  * let you type to narrow down which windows are being presented.  maybe that's cool or maybe not.  maybe let you narrow it down with the action instead
* desktop grid - wonder if this would cause focus tracking issues
* alt-tab live thumbnails (meh..?)
* zooming in, and magnifying glass
  * action can specify the zoom multiplier and the size of the maginifier
* weird effects when a window maps/closes/iconifies/etc

(In reply to comment #7)
> some ideas from kwin4:

I have wanted this feature for quite some time and also looked at the code for xcompmgr and transset-df to see if it could be done (disclaimer: I am not a lib programmer). I was wondering if it would not make sense to start simple, i.e. simply merge in xcompmgr code to fire up the compositor if it is compiled in and provide menu.rc options that match those of xcompmgr and then use the _NET_WM_WINDOW_OPACITY (transset-df also does the same having been derived from transset) for every window opened (if specified in the config - start with only one allowable setting). 

That way you start with a known set of behaviours that work today and whose ouput is known and predictable, just that in this case openbox would provide the functionality.

For me, the most important part of compositing is fast window switching. There's a slight delay switching windows with certain programs, since they need to be redrawn (Thunderbird & Firefox especially). I would happily sacrifice a tiny bit of CPU overhead to have snappier performance.

I've tried xcompmgr to get around this, but xcompmgr is really slow switching workspaces for some reason.

And of course, all the usual full compositing stuff would be cool too :)

I know this is a really old thread, but I hope it happens some day.

I too hope that this will be done one day, because window compositing is required by some programs in order for them to work properly (as intended). Though it is not absolutely required, it would add a certain appeal to Openbox. I tried some compositing managers, including xcompmgr and cairo-compmgr, but none gave me entire satisfaction. Cairo-compmgr made my Gnome panels disappear (invisible), Xcompmgr's shadows leave sometimes ugly trails behind them.

This is not of critical importance (as xcompmgr without shadows seems to work fine), but would be great if implemented. :)

Most of the lag/performance stuff would be fixed by use of threading, where you simply display the last result until there is something new.  The sync extension allows this to be done well.

"Dropping xcompmgr in" would be non-trivial I think, and it is quite buggy and slow switching desktops etc, which is something I just won't accept inside openbox.  There is some code in various branches regarding this and I've been giving thought to picking it up again, but yeh.  nice to see people thinking about this as well.