I’ve cleaned up a patch to allow semi transparent windows with juce.
[attachment=1]argb32.png[/attachment]
At the time, i’ve only implemented a more organic way to obtain 32bit argb Visuals if they are present (if there is a composition manager like compiz, xcompmgr, or metacity compositing running) thru the Xrender extension. If not, or a window is not translucent, the fallback mode of 24/16it is preserved. Actually this feature is enabled only if XSHM extension is enabled: it should be possible to use ARGB32 images with XPutImage too (and not only in companion with XSHM), but from my tests i was getting a huge load of BadMatch in trying to do so. So for now the patch is available only if you are using XSHM.
the only drawback is that we will lose the transparent background of the window if we overwrite it with a translucent one repeatedly (like the drag-me-to-desktop-translucent-component in the jucedemo):
[attachment=0]argb32_bad.png[/attachment]
If you look at the desktop component, it leaves trails of the old paint (but it is translucent). Maybe it’s a problem of premultiplying the alpha before blitting ? I don’t know here. Probably i should take care of introducing the Xcomposite extension in the field, so to have a better control over composition of old window background and the new translucent one.
And no other linking library (all is done transparently).
Since this is extremely experimental, i need people to test this over more distros as possible and report feedback, and if anyone would like to contribute with code it will be appreciated cause translucent windows is possible on linux, we only need to teach juce to do so !
the idea is only to obtain a 32bit Visual from X11 and use that for all subsequent drawing operation, instead of forcing the use of 24/16 bit visuals.
the problem is that we need to get the window backing store and clear the actual content of the window, probably using XRenderComposite with an operation of PictOpSrc (the destination pixels should be replaced with the source pixels) or getting the window back pixmap with XCompositeNameWindowPixmap and clear that (but i don’t know if it will work simply clearing it).
There is some more info here, i will try some options and see what i come up with when i have some time .
to ease the test you can enable metacity composition by doing like this, instead of installing a complex composition manager like compiz, or using xcompmgr.
Filelist of package libxcomposite-dev in etch of architecture i386
/usr/include/X11/extensions/Xcomposite.h
/usr/lib/libXcomposite.a
/usr/lib/libXcomposite.so
/usr/lib/pkgconfig/xcomposite.pc
/usr/share/doc/libxcomposite-dev/changelog.Debian.gz
/usr/share/doc/libxcomposite-dev/copyright
i’ve tried some options, it seems it is dependent on the window manager on how to treat the window, based on window hints.
i’ve read carefully the detailed description here, but i’m still trying to figure out the correct hints to give to temporary windows ( _NET_WM_WINDOW_TYPE ):
no there is nothing about a shadow hint. typically window managers ignore the drop shadow for _NET_WM_WINDOW_TYPE_NOTIFICATION type windows (_NET_WM_WINDOW_TYPE), but there is nothing sure out there (they can even ignore it) . also making those window ignore the taskbar with _NET_WM_STATE_SKIP_TASKBAR as _NET_WM_STATE_SKIP_TASKBAR may be of help… but i always failed, sometimes it always put the shadow, some other times the wm do not.
How about _NET_WM_WINDOW_TYPE_COMBO ? I’ve never seen a combo box type with a drop shadow, as it might cover the initial edit box.
While I say this, I’ve never tested this.
I’ve looked at Enlightenment window manager, and clearly the test to enable shadow is:
if (window is shaped or window doesn’t have a border) then disable shadow.
So either you set a 0 pixel border or you set the shape of the window (with XShape and a single rectangle in the list: XShapeCombineRectangles)
yes you are right, actually it works pretty good apart that when i drag the jucedemo’s transparent widget to the desktop it has the drop shadow 2 times out of 5… probably we should play with window type and state to make it work like we need.
[quote=“X-Ryl669”]I’ve looked at Enlightenment window manager, and clearly the test to enable shadow is:
if (window is shaped or window doesn’t have a border) then disable shadow.
So either you set a 0 pixel border or you set the shape of the window (with XShape and a single rectangle in the list: XShapeCombineRectangles)[/quote]
you spotted the right path, i’ve double checked metacity and its compositor checks for shaped windows and for specially typed windows that are not menus or drag and drop.
[quote=“X-Ryl669”]I’ve looked at Enlightenment window manager, and clearly the test to enable shadow is:
if (window is shaped or window doesn’t have a border) then disable shadow.
So either you set a 0 pixel border or you set the shape of the window (with XShape and a single rectangle in the list: XShapeCombineRectangles)[/quote]
hey i was totally wrong. you spotted the right path, i’ve double checked metacity and its compositor checks for shaped windows and for specially typed windows that are not menus or drag and drop.
