Transparency?

[LaloHao]

I tried using xcompmgr + devilspie but failed. Do you have any configuration working with compton or any other?

--------------------------- EDIT: what i tried so far ~/.xprofile

xcompmgr &
devilspie &

~/.devilspie/opacity.ds

(if (or (is (application_name) "screenkey")
        (is (application_name) "terminator")
            (begin
               (spawn_async (str "transset-df -i " (window_xid) " 0.85"))
            )
    )

Terminator does get transparency set but screenkey does not. Also, when i manually set transset-df -i XID 0.85 where XID is the window id i get using command xprop it does get the transparency but it

--------------------------- EDIT2: Running screenkey --persistent and xbindkeys allowed me to change any window transparency with Alt + up or down (Scroll wheel)

~/.xbindkeysrc

"transset-df -p --inc 0.2"
Alt + Alt_L + b:4

"transset-df -p --min 0.2 --dec 0.2"
Alt + Alt_L + b:5

[wavexx]

On 11/08/15 21:10, Eduardo Vazquez wrote:

I tried using xcompmgr + devilspie but failed. Do you have any configuration working with compton or any other?

Just running compton without any argument works for me. I didn't try xcompmgr in a long time.

[wavexx]

I now saw your edits (unfortunately those are not sent by email).

note that screenkey sets transparency by default already to 0.8, so none of this should be required.

[LaloHao]

When i ran compton all my windows indiscriminately got transparency except for screenkey even when i had this on my config

opacity_rule = ["80:class_g = 'screenkey'"];

Unfortunately for me screenkey doesn't get any transparency out of the bat so maybe if someone has the same problem it'll work out like above

[wavexx]

On 12/08/15 20:05, Eduardo Vazquez wrote:

When i ran compton all my windows indiscriminately got transparency except for screenkey even when i had this on my config

|opacity_rule = ["80:class_g = 'screenkey'"]; |

Unfortunately for me screenkey doesn't get any transparency out of the bat so maybe if someone has the same problem it'll work out like above

It's really weird. Could you maybe xprop the window and see if some attributes are missing?

You'll need to use --persistent to be able to click on it as you saw.

[wavexx]

Which distribution/DE are you using?

[LaloHao]

I'm using arch linux. Here's xprop info with no --persist flag

_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_STICK
_NET_WM_DESKTOP(CARDINAL) = 4294967295
_NET_WM_STATE(ATOM) = _NET_WM_STATE_STICKY, _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_ABOVE
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 0
WM_STATE(WM_STATE):
        window state: Normal
        icon window: 0xd6b18600
WM_HINTS(WM_HINTS):
        Client accepts input or input focus: False
        Initial state is Normal State.
        window id # of group leader: 0x4000001
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 67108908
_NET_WM_WINDOW_OPACITY(CARDINAL) = 3006477106
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_UTILITY
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x400002b
WM_CLIENT_LEADER(WINDOW): window id # 0x4000001
_NET_WM_PID(CARDINAL) = 1762
WM_LOCALE_NAME(STRING) = "es_MX.utf8"
WM_CLIENT_MACHINE(STRING) = "arch"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
        program specified location: 0, 0
        program specified minimum size: 53 by 70
        window gravity: Center
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "screenkey", "Screenkey"
WM_ICON_NAME(STRING) = "screenkey"
_NET_WM_ICON_NAME(UTF8_STRING) = "screenkey"
WM_NAME(STRING) = "screenkey"
_NET_WM_NAME(UTF8_STRING) = "screenkey"

and heres xprop with --persist flag

_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 0
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_STICK
WM_STATE(WM_STATE):
        window state: Normal
        icon window: 0xd6b18600
_NET_WM_DESKTOP(CARDINAL) = 4294967295
_NET_WM_STATE(ATOM) = _NET_WM_STATE_STICKY, _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_ABOVE
WM_HINTS(WM_HINTS):
        Client accepts input or input focus: False
        Initial state is Normal State.
        window id # of group leader: 0x5200001
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 85983265
_NET_WM_WINDOW_OPACITY(CARDINAL) = 3006477106
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_UTILITY
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x5200020
WM_CLIENT_LEADER(WINDOW): window id # 0x5200001
_NET_WM_PID(CARDINAL) = 2122
WM_LOCALE_NAME(STRING) = "es_MX.utf8"
WM_CLIENT_MACHINE(STRING) = "arch"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
        program specified minimum size: 26 by 70
        window gravity: Center
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "screenkey", "Screenkey"
WM_ICON_NAME(STRING) = "screenkey"
_NET_WM_ICON_NAME(UTF8_STRING) = "screenkey"
WM_NAME(STRING) = "screenkey"
_NET_WM_NAME(UTF8_STRING) = "screenkey"

They're completely the same i think

[wavexx]

Yes, they should be the same. --persist is only to make using "xprop" easier in this case. The OPACITY is also set, which is what I was looking for.

I'll try with a live cd and see.

[wavexx]

I tried on the latest archbang live cd just to be sure. I just needed to install pygtk and run xcompmngr. When starting screenkey afterwards, the window is correctly transparent.

[wavexx]

One last thing that I can think of: which window manager are you using?

[LaloHao]

Im using xfce4 DE which uses xfwm4 as WM

[wavexx]

On 24/08/15 22:21, Eduardo Vazquez wrote:

Im using xfce4 DE which uses xfwm4 as WM

Well, seems to work correctly also when using xfwm4's built-in compositor.

I just installed xfce4 on archbang, (all packages) and run a new session with the defaults, I didn't need to run anything else.

[LaloHao]

It didn't work for me, i liked the solution of xbindkeys tho, we can close this if you want

[wavexx]

On 10/09/15 19:27, Eduardo Vazquez wrote:

It didn't work for me, i liked the solution of xbindkeys tho, we can close this if you want

We can leave this open, there's clearly some issue, even though I couldn't reproduce it.

Strictly speaking, screenkey doesn't do anything magical here. Just sets the opacity atom for the window. It should work. This requires cooperation between the window manager and the compositor. If it doesn't work, it would suggest a bug in either the window manager or the compositor, not in screenkey.

There are work-arounds to fake opacity, but I'd rather not go that route. Composition is not "new".

So far, all the combinations I tried do work as intended. From spectrwm+compton to KDE4/unity. There's probably something unique in your configuration that causes that to happen.

I would recommend to try a live cd (using qemu, for example), and trying with the default configuration, then install the same packages you have, trying to run screenkey at each step to see where the problem is. I tried with archbang+xfce, but the built-in compositor/wm work just fine.

If you can reproduce the problem, then I can help investigate. Otherwise you'd have to give in and debug screenkey yourself.

[wavexx]

Closing this. Transparency with compositors do work as intended, and I couldn't reproduce the issue.