[feature request] opacity-exclude

[SmilingHorse]

First off, Thanks for compton ! It's great to have some eye-candy without the monstrous overhead the other compositors have. Right now, everything works great with the latest compton-richardgv branch! I actually came by the dev branch after having the top left tearing issues with xcompmgr but those are no more with this latest build. In fact, I have had zero problems with it whatsoever; though I do use only a few features and my workstation is a little too mature and mid-end to tell any minor performance issues (q6600 \ gfx 460 nvidia 304.48 \ 4gb ram \ openbox + tint2 + compton \ x64 debian wheezy beta).

Only issue I have now is one of functionality: I could use an opacity-exclude array setting that acts like the shadow-exclude but to transparency. The problem is whenever I'm working with multi-window applications (gimp or a few open gvim \ mlterm sessions), I need to keep all the windows clearly visible and so I can't use the inactive effect(which I like to keep for just about everything else).

Thanks again!

P.s. Finally conky works like it should. It's passing through the right-click-openbox-menu while remaining transparent and not casting any shadows.

[richardgv]

First off, Thanks for compton ! It's great to have some eye-candy without the monstrous overhead the other compositors have. Right now, everything works great with the latest compton-richardgv branch! I actually came by the dev branch after having the top left tearing issues with xcompmgr but those are no more with this latest build. In fact, I have had zero problems with it whatsoever; though I do use only a few features and my workstation is a little too mature and mid-end to tell any minor performance issues (q6600 \ gfx 460 nvidia 304.48 \ 4gb ram \ openbox + tint2 + compton \ x64 debian wheezy beta).

Ah, thanks for your support. I'm glad things are working pretty well on your side. :-)

Only issue I have now is one of functionality: I could use an opacity-exclude array setting that acts like the shadow-exclude but to transparency. The problem is whenever I'm working with multi-window applications (gimp or a few open gvim \ mlterm sessions), I need to keep all the windows clearly visible and so I can't use the inactive effect(which I like to keep for just about everything else).

1. The first thing I would like to say is: Please don't expect a software developer to add whatever feature you want:
   • The desire of humans is endless, and users will ask you to satisfy the weirdest need they could ever think of, even though it's a feature useless for the 99% others. A part of human nature, I assume, it is. Hmm, sorry if this is offending, I'm a pretty straightforward person.
   • Have you heard the joke about how the CEO of Dropbox committed suicide? (As far as I can remember, "the CEO of Dropbox committed suicide yesterday, because some users asked for a feature of recovering deleted files, then some other users asked for permanently deleting a file without the possibility of recovery, then some asked for recovering permanently deleted files, then some asked for deleting a file really permanently without the possibility of recovering permanently deleted files...) The joke does show what will happen if a developer blindly accepts feature requests from users.
   • I've also stated which direction things will go if I just accept all those feature requests in a reply to #64:

He asked for giving active window deeper shadow opacity, and I said: People will then ask me for inactive window shadow radius, active window shadow radius, inactive window shadow color, active window shadow color, inactive window shadow offset, active window shadow offset, inactive window fading speed, active window fading speed, inactive window frame opacity, active window frame opacity... Seriously, I'm a bit worried about how I should answer if somebody asks for those. :-D

• Add a single feature will not make compton bloated too much, but please consider what will happen if people ask for all the features that they need but 99.9% others don't, as what I listed above.
  2. Now let's look into what you are asking for. As I see it, you are effectively talking about two different things:
• Considering the GIMP toolbox windows focused, too, if the main window is focused. In which case, the toolbox windows is an auxiliary window of the main window. I will consider adding recognition for such cases by reading WM_TRANSIENT_FOR, WM_CLIENT_LEADER, and/or _NET_WM_PID into compton.
• Considering your gVim and mlterm focused at the same time. Different gVim windows, or gVim windows and mlterm windows, have literally no relationship in between, except for in your own mind. What you are looking for is a tool to organize your windows into groups, then, an "Important" group and an "Others" group -- which is not compton's business. We are glad to obey the rules of a few popular window group tools when determining whether a window is focused, though -- if I know any.
  3. My advices:
• A quick and dirty fix for your GIMP issue is to enable single-windowed mode of GIMP, added in GIMP 2.8. That's the mode I always use.
• You may plainly use :split, :vsplit, or :tabnew for gVim, so all your work stay in a single window.
• You may increase the opacity of inactive windows, or choose the milder --inactive-dim.
• You may write a script, with shell, Perl, or Python, that sets window opacity (_NET_WM_OPACITY) in the way you desire. Xcb bindings exist for Perl and Python 2, while the binding for Python 3 is said to be untested.
• You may use a program that could group some windows together into a single window. I heard some window managers have the feature.
• You may choose a window manager that has a more intelligent focused window opacity feature than what compton has -- it's easier for a window manager to recognize the relationships between windows than compton. I heard Awesome has the feature.
• You may use virtual desktop / workspace feature of your window manager to manage your windows instead.
• If you insist, I could provide you a patch to add --inactive-exclude feature, like what I did for #63. But keep in mind:
• I truly doubt whether this will do what you want. We could force some windows to be considered focused, but this means all windows in this group will always be opaque, even when the focus gets out of those windows -- say, all GIMP windows will be forever opaque regardless of what you are doing. And it may not be possible to match the windows you want exactly, if you want to make some gVim window always opaque while some gVim windows stay normal.
• I don't think the feature will ever get into the repo.
• The patch may or may not be updated when it could no longer be cleanly applied due to changes in compton.
• You could wait until I add auxiliary window detection, but this is only a fix for your GIMP window issue, and I'm currently busy on preparation of my forthcoming exam and my other projects (that have money inside :-D ).
• You could wait until I add the external socket feature, the ultimate solution to everything one would need, mentioned in #16, if it eventually comes in the distant future. I would say it will not arrive until the end of the world (December 21st, 2012), at least. :-D

P.s. Finally conky works like it should. It's passing through the right-click-openbox-menu while remaining transparent and not casting any shadows.`

Ah, I never thought setting own_window_type normal in .conkyrc could let fvwm right-click menu pass through! Thanks for the hint! :-D

[SmilingHorse]

Wow! Thanks for quick and thorough reply. I've come to expect a simple "no" to my requests in the past so it's nice to be pleasantly surprised once in a while. :)

"Please don't expect a software developer...Seriously, I'm a bit worried about how I should answer if somebody asks for those. :-D"

A simple "no" would have sufficed :D I should probably have made it clearer, but it's not a feature request as much as it is a feature suggestion (of what I thought would be useful to have and easy to implement). That's to say, I "want" it; But I don't "need" it.

"You may increase the opacity of inactive windows"

That's my partial workaround which suffices. Most of the time...

"You may write a script, with shell, Perl, or Python, that sets window opacity"

If I was about to write some code, I would have picked up my dusty K&R and hacked around the code myself. Thing is, I haven't done any C in years (and I never done it properly). Besides, I figured it might be generic enough for me to get someone more competent interested. I suppose no harm in trying :D

"I will consider adding recognition for such cases by reading WM_TRANSIENT_FOR, WM_CLIENT_LEADER, and/or _NET_WM_PID into compton."

That's very reasonable. One case scenario solved and in a much more elegant and useful manor than what I had in mind too. Very nice.

"Considering your gVim and mlterm focused at the same time."

I meant that despite not being focused, I wanted the windows to be non+opaque like if they were focused. Here is a somewhat common scenario I think you might be familiar with: You have one terminal running the program with the trace; another with dbg since tmux gets in the way of the trace; and a third with the code on vi. This is a somewhat common usage scenario for me and what I thought was for many. I can even throw in an extra window with firefox\abiword with an API \ specs \ whatever help file I happen to need. Why, right now I even have a kvm spice session running windows for cross-platform debugging on another desktop but that is really unusual (Stupid threading in python doesn't work the same in linux and windows... Damn it I just might need to relearn C regardless).

Anyhow, What I'm saying is that I figured the simplest solution would be to just exclude the executables by their names (or whatever semi-unique identifier X supports) with a simple "if not (x.name is in window_array):" check inside the loop that sets the opacity. Since the shadow-exclude was acting much the same way and I wasn't sure if it's some callback or some X related voodoo, I just went the specifications route and described the end result behaviour I expected: A setting in the config file specifying which process will not become opaque regardless of it's focus state.

"a program that could group some windows together into a single window"

Interesting... That might be useful regardless. I never heard of X being capable of that let alone a program that can do that. I look into that if push comes to shove and I won't be able to pick C again (I was never good enough to begin with so...).

"I heard Awesome has the feature."

I played around Awesome for some time but it has it's own set of issues. Suffice to say it didn't work for me which is a shame since, indeed, it's an awesome WM :) Maybe I just might revisit it in the future since it seems it picked up quite the following since the last time I tried it so the problems might have been resolved.

"use virtual desktop / workspace"

I'm presently using 4. Once I'm pulling over 16 windows, it all become a little too disorienting without them. Especially when two of them include over 20 open firefox tabs and way too much buffers and splits... I was actually using eclipse in the past but it became very sluggish for my (inefficient) multi-tasking style of work. Writing crappy code also doesn't help :8ball:

"I could provide you a patch to add...don't think the feature will ever get into the repo...may or may not be updated"

Absolutely not! If it's not useful for other people than I'll figure out what everyone else is doing and do that instead. Last thing I want is to maintain a code base no one else uses. It's precisely why I refuse to write small scripts any more: If most people can be productive without it than it's the user's(me) fault and I should just do what they do to get the work done even if it's inconvenient.

"wait until I add auxiliary window detection"

No rush. Like I said, compton does almost everything I want it to do and this small request\suggestion won't keep me from using it. I've already binded a toggle script through xbindkey that closes and opens compton when I hit one of my (otherwise useless) multimedia keys so it's all good here :)

"until I add the external socket feature"

So you're working on a generic plugin system of sorts ? You should have started with that :) Would have saved you and me a whole lot of reading\writing :D

"I never thought setting own_window_type normal in .conkyrc could let fvwm right-click menu pass through! "

I'll have my config files up here in a minute... Better keep them in the next comment to make this already too long reply manageable.

[SmilingHorse]

Screenshot

• note that conky is transparent on my desktop despite it not showing properly in the screenshot...
• I'm right-clicking on it and the openbox menu gets open.

Tint2

# Tint2 config file
# Generated by tintwizard (http://code.google.com/p/tintwizard/)
# For information on manually configuring tint2 see http://code.google.com/p/tint2/wiki/Configure
# To use this as default tint2 config: save as $HOME/.config/tint2/tint2rc
# Background definitions
# ID 1
rounded = 2
border_width = 1
background_color = #000000 22
border_color = #FFFFFF 0
# ID 2
rounded = 2
border_width = 0
background_color = #000000 0
border_color = #FFFFFF 22
# ID 3
rounded = 2
border_width = 1
background_color = #FFFFFF 0
border_color = #FFFFFF 36
# ID 4
rounded = 0
border_width = 0
background_color = #000000 0
border_color = #000000 0
# ID 5
rounded = 1
border_width = 1
background_color = #FFFFFF 30
border_color = #FFFFFF 0
# Panel
panel_monitor = all
panel_position = center left vertical
panel_size = 0 2%
panel_margin = 0 8
panel_padding = 1 2 20
panel_dock = 0
wm_menu = 1
panel_layer = top
panel_background_id = 1
panel_items = LTSC
# Panel Autohide
autohide = 0
autohide_show_timeout = 0.0
autohide_hide_timeout = 0.0
autohide_height = 0
strut_policy = follow_size
# Launcher Bar
launcher_background_id = 0
launcher_tooltip = 1
launcher_icon_size = 0
launcher_icon_theme = launcher_icon_theme
launcher_padding = 2 1 1
launcher_icon_asb = 100 0 0
# Launchers
launcher_item_app = /usr/share/applications/Thunar.desktop
launcher_item_app = /usr/share/applications/iceweasel.desktop
launcher_item_app = /usr/share/applications/deadbeef.desktop
launcher_item_app = /home/luser/.local/share/applications/eclipse.desktop
# Taskbar
taskbar_mode = multi_desktop
taskbar_padding = 1 0 0
taskbar_background_id = 0
taskbar_active_background_id = 3
taskbar_name = 1
askbar_name_padding = 2
taskbar_name_background_id = 0
taskbar_name_active_background_id = 5
taskbar_name_font = Visitor TT1 BRK 9
taskbar_name_font_color = #FFFFFF 80
taskbar_name_active_font_color = #FFFFFF 100
# Tasks
urgent_nb_of_blink = 7
task_icon = 1
task_text = 0
task_centered = 1
task_maximum_size = 200 32
task_padding = 5 3
task_background_id = 2
task_active_background_id = 5
task_urgent_background_id = 0
task_iconified_background_id = 0
# Task Icons
task_icon_asb = 100 0 0
task_active_icon_asb = 100 0 20
task_urgent_icon_asb = 100 0 0
task_iconified_icon_asb = 70 -20 0
# Fonts
task_font = Visitor TT1 BRK 8
task_font_color = #FFFFFF 65
task_active_font_color = #FFFFFF 80
task_urgent_font_color = #FFFFFF 100
task_iconified_font_color = #FFFFFF 100
font_shadow = 0
# System Tray
systray_padding = 4 3 4
systray_sort = ascending
systray_background_id = 0
systray_icon_size = 0
systray_icon_asb = 100 0 0
# Clock
time1_format = %b.%d
time1_font = Visitor TT1 BRK 7
time2_format = %Y%n%H:%M
time2_font = Visitor TT1 BRK 10
clock_font_color = #FFFFFF 73
clock_tooltip = %A %d %B
clock_padding = 2 1
clock_background_id = 0
time1_timezone = 
time2_timezone = 
clock_tooltip_timezone = 
clock_lclick_command = gsimplecal
clock_rclick_command = gsimplecal
# Tooltips
tooltip = 0
tooltip_padding = 0 0
tooltip_show_timeout = 0
tooltip_hide_timeout = 0
tooltip_background_id = 0
tooltip_font = Sans 12
tooltip_font_color = #FFFFFF 100
# Mouse
mouse_middle = close
mouse_right = none
mouse_scroll_up = toggle_iconify
mouse_scroll_down = toggle_iconify
# Battery
battery_low_status = 20
battery_low_cmd = notify-send "battery low"
battery_hide = 90
bat1_font = Visitor TT1 BRK 8
bat2_font = Visitor TT1 BRK 8
battery_font_color = #FFFFFF 100
battery_padding = 0 0
battery_background_id = 0
# End of config

Compton

# Shadow
shadow = true;
no-dnd-shadow = true;
no-dock-shadow = true;
clear-shadow = true;
shadow-radius = 7;
shadow-offset-x = -7;
shadow-offset-y = -7;
# shadow-opacity = 0.7;
# shadow-red = 0.0;
# shadow-green = 0.0;
# shadow-blue = 0.0;
shadow-exclude = [ "n:e:Notification", "g:e:Conky", "n:e:mplayer2"];
shadow-ignore-shaped = true; 
# Opacity
menu-opacity = 0.95;
inactive-opacity = 0.8;
frame-opacity = 0.7;
inactive-opacity-override = true; 
alpha-step = 0.06;
# Fading
fading = true;
# fade-delta = 30;
fade-in-step = 0.03;
fade-out-step = 0.03;
# no-fading-openclose = true;
# Other
mark-wmwin-focused = true;
mark-ovredir-focused = true;
use-ewmh-active-win = false;
detect-rounded-corners = true;
detect-client-opacity = true;
refresh-rate = 0;
vsync = "none";
dbe = false;
paint-on-overlay = false;
sw-opti = false;
unredir-if-possible = false;
# Window type settings
wintypes:
{
  tooltip = { fade = true; shadow = false; opacity = 0.75; };
};

Conky

background yes
use_xft yes
xftfont Sans:size=11
xftalpha 1
update_interval 2
total_run_times 0
own_window yes
own_window_transparent yes
own_window_type normal 
own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager
own_window_argb_visual yes
double_buffer yes
minimum_size 400
maximum_width 400
draw_shades no
draw_outline no
draw_borders no
draw_graph_borders yes
default_color white
default_shade_color black
default_outline_color white
alignment top_right
gap_x 12
gap_y 12
no_buffers yes
uppercase no
cpu_avg_samples 2
override_utf8_locale no
#colour
default_color white
# white
color1 FFFFFF
# orange
color2 FC8820
TEXT
${offset -5}${font Ubuntu:pixelsize=95}${time %H}${color2}:${color1}${time %M}${font}
${voffset 10}${time %A} ${color2}| ${color1}${time %d} ${time  %B} ${time %Y}${font}
${font sans-serif:bold:size=10}SYSTEM ${color2}${hr 2}${color1}
${font sans-serif:normal:size=10}$sysname $kernel $alignr $machine
Host:$alignr$nodename
Uptime:$alignr$uptime
IP address:$alignr${addr eth0}
${font sans-serif:bold:size=10}PROCESSORS ${color2}${hr 2}${color1}
${cpugraph cpu1}${offset -235}${voffset -15}${font sans-serif:normal:size=10}CPU1: ${cpu cpu1}%
${cpugraph cpu2}${offset -235}${voffset -15}${font sans-serif:normal:size=10}CPU2: ${cpu cpu2}%
${cpugraph cpu3}${offset -235}${voffset -15}${font sans-serif:normal:size=10}CPU3: ${cpu cpu3}%
${cpugraph cpu4}${offset -235}${voffset -15}${font sans-serif:normal:size=10}CPU4: ${cpu cpu4}%
$font${top name 1}${alignr}${top cpu 1} %
$font${top name 2}${alignr}${top cpu 2} %
$font${top name 3}${alignr}${top cpu 3} %
$font${top name 4}${alignr}${top cpu 4} %
$font${top name 5}${alignr}${top cpu 5} %
${font sans-serif:bold:size=10}MEMORY ${color2}${hr 2}${color1}
${font sans-serif:normal:size=10}RAM $alignc $mem / $memmax $alignr $memperc%
$membar
SWAP $alignc ${swap} / ${swapmax} $alignr ${swapperc}%
${swapbar}
$font${top_mem name 1}${alignr}${top_mem mem 1} %
$font${top_mem name 2}${alignr}${top_mem mem 2} %
$font${top_mem name 3}${alignr}${top_mem mem 3} %
$font${top_mem name 4}${alignr}${top_mem mem 4} %
$font${top_mem name 5}${alignr}${top_mem mem 5} %
${font sans-serif:bold:size=10}STORAGE ${color2}${hr 2}${color1}
${font sans-serif:normal:size=10}/ $alignc ${fs_used /} / ${fs_size /} $alignr ${fs_used_perc /}%
${fs_bar /}
${font sans-serif:normal:size=10}sda1 $alignc ${fs_used /mnt/sda1} / ${fs_size /mnt/sda1} $alignr ${fs_used_perc /mnt/sda1}%
${fs_bar /mnt/sda1}
${font sans-serif:normal:size=10}sdb1 $alignc ${fs_used /mnt/sdb1} / ${fs_size /mnt/sdb1} $alignr ${fs_used_perc /mnt/sdb1}%
${fs_bar /mnt/sdb1}
${font sans-serif:normal:size=10}sdc1 $alignc ${fs_used /mnt/sdc1} / ${fs_size /mnt/sdc1} $alignr ${fs_used_perc /mnt/sdc1}%
${fs_bar /mnt/sdc1}
${font sans-serif:bold:size=10}NETWORK ${color2}${hr 2}${color1}
${downspeedgraph eth0}
DLS:${downspeed eth0} kb/s $alignr total: ${totaldown eth0}
${upspeedgraph eth0}
ULS:${upspeed eth0} kb/s $alignr total: ${totalup eth0}

[richardgv]

Huh, I'm sorry, SmilingHorse. I was a bit out of luck yesterday: My life was filled with the things I don't want to do but have to do, and my whole afternoon after the test was occupied by them, then the electricity went out, taking a bunch of my work together...

Anyway, the most important part in my unfinished reply is:

1. Thanks for your support. :-)
2. I still don't like your --focus-include, but I will start working on it, for I thought about some other possible uses of it. I don't know when I will finish the thing. I'm getting severely overloaded with the works I don't enjoy, pretty sleep-deprived and always making typos, forcing me to check my words for many times...
3. The socket thing is not easy. I have to decide whether I should invent a new language or somehow use an existing language when talking via the socket. I have no experience designing IPC-related things. Do you have any suggestions?

I will see if I have time to finish the full reply tonight, but today I have a pile of annoying things on my schedule, too.

[smlx]

FWIW, I really don't like the idea of 2 or 3.:

2. This functionality really belongs in the WM. It's trivial in Awesome; if your WM doesn't have the feature please switch to one which does. The compositor really shouldn't try to filter based on executable name or other brittle method.
3. What problem will this solve? I can't imagine a scenario where it would be useful. #16 seems like it could be handled by --shadow-exclude with PCRE regex.

I have found compton an excellent lightweight compositor - I was amazed to see that it consisted of a single .c file. IMHO it really doesn't need a custom scripting language, or to communicate with external processes via sockets...

[SmilingHorse]

To @richardgv :

"I still don't like your --focus-include, but I will start working on it, "

Neither do I. I'm just not familiar enough with X to figure out another way to make windows stay non-opaque. smix also mentioned this should be part of the WM and he brought up the awesome example as well so maybe it would best to leave it off for now ? I should really give awesome another try and see how it's being addressed there...

"The socket thing is not easy..."

I'm only somewhat experienced with slow ipc \ high latency stuff: I wrote clients in python to a few Berkeley socket's RPCs from the GET PUSH level on a few occasions but I never wrote the server side. I suppose there's the multi threading \ processing stuff I've done that had message queueing and that sort of stuff but it was really like passing variables down to a function since I was already working on an abstracted layer and wasn't even dealing with the locks and such which you would be doing on C.

• Like everyone who ever worked a *nix console, I know my share about pipes and forks. But, I'm afraid I've got nothing when it comes to even higher performance solutions.
• I can say this much: dbus felt really slow so I would stay away from it :) If I had to choose I would have gone with semaphore or even shared memory but that's mostly because I've been doing a LOT of threading and multi processing lately so I'm biased towards what I feel is best in long run...
• From what I know other people do, named pipes are really popular. I'm not sure why but that's what I've heard :D

"should invent a new language"

Definitely stay away from that. Unless you're a freaking genius inventing new hardware in the basement or something, there's no utility to yet one more computing language. If you're describing a server side RPC than like I said before, it's slow...

To @smlx :

"This functionality really belongs in the WM." Agreed. I think you're right but when I saw the shadow-exclude I deduced a "filter based on executable name" wouldn't be so unusual. Since that's two people now that mention how awesome is addressing this without the compositor, I'm really not so confident or happy about suggesting it in the first place... Just remember I'm not that familiar with X so I can't be sure what should be implemented where... I know it can be done in compton so I suggested that... But if people familiar with X say it should be in the WM than I'll go harass the openbox guys instead :D

"What problem will this solve? I can't imagine"

One in particular. I've described it plenty of times but my "discomfort" as of now is that I need two or more different windows that are spawned by either the same or different executables to not become transparent. This can be text viewers or editors that need to be kept side by side - like in awesome - and readable. Since compton makes inactive windows lose focus, I'm presently forced to close it off while working. My thought was that the simplest thing to do was to exclude this executables from the effect. But since you all say there should be a way to "group" windows in a way that will keep them focused inside the WM, I'm starting to think you're right and it's not a compton "problem" but an openbox one.

"was amazed to see that it consisted of a single .c file"

And 30 lines main() ! That's just crazy :D

[SmilingHorse]

Hold on, I think I found how it should work "officially": This awesome wiki entry http://awesome.naquadah.org/wiki/Transparency#Using_built-in_transparency_support makes a mention of WM_CLASS and WM_NAME being used to blacklist certain windows by the internal compositor.

• So it's essentially being handled like I originally thought. xprop is also mentioned and the man page http://www.xfree86.org/current/xprop.1.html mention "-set property-name value" which should make it possible to change a given window name and class.

So, I'm back thinking that compton should have an exclusion value. But, I think that either the WM or a second application should front-end xprop and allow a click-to-exclude functionality where the window class is changed into something like "exclude_transparency" or "exclude_shadow" or "exclude_both", and than the compositor follows up from there and doesn't draw the window with those effects. I'm not sure WM_CLASS is inherited by child windows so it will probably still be necessary to implement a bool that verifies that children are also excluded...

Does any of this makes sense to you ? :P

[smlx]

@SmilingHorse I still think you are muddling the line between compositor and WM.

The default Awesome config has this:

client.add_signal("unfocus", function(c)
    c.border_color = beautiful.border_normal
    c.opacity = 0.9
end)

I can force my terminals to remain opaque upon losing focus with this code:

client.add_signal("unfocus", function(c)
    c.border_color = beautiful.border_normal
    if not awful.client.property.get(c,"class") == "URxvt" then
        c.opacity = 0.9
    end
end)

As you can see, it's much simpler to have the WM making the decisions about window focus/opacity, rather than trying to push this logic into the compositor.

In fact, I've personally run into a bug (#58) where (through my own lack of understanding of compton options) compton's logic for choosing which windows became transparent directly clashed with and broke the WM's logic.

I honestly can't think of a use-case where this kind of logic isn't better implemented in the WM.

There is a good explanation of the properties the WM can use to recognise specific X clients here: http://awesome.naquadah.org/wiki/Understanding_Rules#Window_Properties

[SmilingHorse]

"As you can see, it's much simpler to have the WM making the decisions"

It sure looks nice :) But isn't it only possible because of Awesome's integrated compositor ? I'm only guessing based on the function name "add_signal" (assuming it's a function...), but doesn't this statement adds a condition in the drawing eventloop to exclude a given WM_CLASS from the effect much like what I'm suggesting ?

"There is a good explanation of the properties the WM can use to recognise specific X clients here: http://awesome.naquadah.org/wiki/Understanding_Rules#Window_Properties"

I see... And WM_CLASS is immutable so it would mean back to the more detailed exclusion array...

The problem I'm seeing is that the WM role is too loose: Looking here: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html I'm very confused. it seems to say that _NET_WM_STATE_FOCUSED should only be handled by the WM ( "Clients MUST regard it as a read-only hint" ) and that it's generally true that only one window should be focused with the exception of "strong association with the active window and will be considered as a unit with it by the user". So the focus can't be used for different applications.

The other option I'm seeing is _NET_WM_ACTION_SHADE in _NET_WM_ALLOWED_ACTIONS that look like the atom for the job. But I can't make sense of the statement: "An implementation MAY add new atoms to this list. Implementations without extensions MUST ignore any unknown atoms, effectively removing them from the list". It looks like the WM is free to implement the means to shade\unshade (opaque in out more modern usage ?) or add more atoms specific to the task but those aren't standardized ?! So since the compositor cannot rely on a WM to set _NET_WM_ACTION_SHADE, the compositor is forced to either give up and only shade the obvious non-focused windows or handle it on it's own by ugly-hacking an exception (like my suggestion).

Ah... I give up. It's obvious the standard either completely ignores compositors needs or expects the WMs to be coded in conjunction with the compositors. Either way, the "right" solution here would be to get Openbox to add functionality like "sticky" but only for shade \ opaque. The "wrong" solution when you can't get the WM to do it is to do what I suggested. But that's is just wrong.

Boo Hoo... :D

Well, no matter. I'll just try make do. I'm sure I'll find a more agreeable solution sooner or later :)

Thanks !

[richardgv]

@SmilingHorse:

I'm truly sorry for letting you wait for 5 days for a pretty minor new feature. Anyway, your wish is granted, and please clone from richardgv-dev branch and test whether --focus-exclude is sufficient for you. Beware this commit changes many others things, and I can't predict how many bugs it probably introduces.

In spite of the fact that I added the feature, it does not imply I consider this feature very agreeable. But my time is still extremely limited recently, giving me even no time to carefully read what you guys said, sorry. Well, if I have a single day free, a single day! Anyway, I'm afraid you have to wait for quite some time before I could look into all your suggestions.

[SmilingHorse]

WOW ! You actually went ahead, found the time, and coded it just when I was giving up :)

I've tested it out with two setups both working great:

• "focus-exclude = ["g:e:mlterm", "n:a:- GVIM", "n:a:- Iceweasel"]" excludes all the mlterm, gvim and iceweasel (firefox in debian) sessions without fault.
• "focus-exclude = ["n:a:- VIM", "n:a:- GVIM", "n:a:- Iceweasel"]" more limited to just when vim is running. allows other mlterm runs to stay opaque.

Overall, Flawless. From what 20 minutes of testing can tell, it all seems to work just like I wanted it to! I'll be adding and changing stuff like gdb and man as I go along so I might still get a chance to find bugs... But it all looks really solid from what I can tell.

Huge Thanks !

[richardgv]

@SmilingHorse:

Sorry, I definitely have forgotten to read all your replies... Yet I do remember one thing I've promised: Auxiliary window detection, here you go! Even though, it doesn't work as good as I expected. Please read the commit messsage in richardgv-dev for more details, and report to us if you find any bugs.

[SmilingHorse]

More features ? And such a major one to boot ? For me ? Thanks You ! :P

I'm sorry for the late response. Why, it's only by chance that I've even noticed your message as I rarely use my github account (since I don't maintain any code on it myself) nor do I forward the messages to my email... mea culpa :D

Anyhow, I've compiled and tested the new code and it's working just fine. Both gimp and xpad no longer lose opacity once shifting focus from one child window to the next. No bugs found for now nor do I notice the speed issues you warned about even after a few hours of usage. Mind you, it's still the same GeForce GTX 460 \ Intel Q6600 \ 4gb ram system I was running last time so I can't really tell the difference unless something goes horribly wrong...

By the way, since last we spoke I've gone through a couple of system reinstalls and am now mostly running Enlightenment instead of Openbox as I'm picking up the EFL as a gui kit for my own coding. Compton is actually working fine with E17 (6 month old Debina Sid version) but there are very compelling reasons to use the build-in compositor in Enlightenment mostly originating from the unique way E17 draws it's windows...

Regardless, I'm still going back and fourth from E17 to Openbox (about 50\50 give or take) and I'm getting plenty of "testing time". So, if I'll notice any bugs I'll be sure to let you know.

Again, Thank you. Even before this latest feature, you made Compton non-stop-usable for me, and now, it's not just usable, but also, comfortable. If there's anything you need testing be sure to let me know. I'll hopefully be checking up on my account on a weekly basis - usually nearing the weekend - so don't worry about me not answering immediately ;)

p.s. You might be interested to know that on Debian, the libGL development package for libgl is libgl1-mesa-dev.

[richardgv]

Huh, I still haven't gotten enough time to read the words you said in the past...

@SmilingHorse:

I'm sorry for the late response. Why, it's only by chance that I've even noticed your message as I rarely use my github account (since I don't maintain any code on it myself) nor do I forward the messages to my email... mea culpa :D

Yeah, I would recommend you to turn on Email notifications at least.

Anyhow, I've compiled and tested the new code and it's working just fine. Both gimp and xpad no longer lose opacity once shifting focus from one child window to the next. No bugs found for now nor do I notice the speed issues you warned about even after a few hours of usage.

Glad to see that. :-)

By the way, since last we spoke I've gone through a couple of system reinstalls and am now mostly running Enlightenment instead of Openbox as I'm picking up the EFL as a gui kit for my own coding. Compton is actually working fine with E17 (6 month old Debina Sid version) but there are very compelling reasons to use the build-in compositor in Enlightenment mostly originating from the unique way E17 draws it's windows...

Huh, I firstly tried E16 (e16-1.0.11). I love its appearance, but I hate how it sets _NET_WM_WINDOW_OPACITY on almost all windows to 0, which causes xcompmgr/compton to fail under it: It tells us almost all windows should have 0 opacity!

Later I tried E17 (0.17.0_beta1). It looks... Amazing. The _NET_WM_WINDOW_OPACITY bug is gone, so compton does work on E17 0.17.0_beta1, but the E17 composite module looks a lot more better than compton... It looks cooler than any sort of effects I could imagine, going beyond my wildest dreams...

In my brief test I didn't see compton having a problem under E17, nor do I know what your "unique way E17 draws it's windows" means. But say, who would use compton if E17's composite module is there?

Again, Thank you. Even before this latest feature, you made Compton non-stop-usable for me, and now, it's not just usable, but also, comfortable. If there's anything you need testing be sure to let me know. I'll hopefully be checking up on my account on a weekly basis - usually nearing the weekend - so don't worry about me not answering immediately ;)

Thanks! :-) Although I just found E17's composite module looks way better than compton indeed. compton is created by technicians, E17 comes from the real artists...

p.s. You might be interested to know that on Debian, the libGL development package for libgl is libgl1-mesa-dev.

Thank you for the info. :-) But, can't the packages of proprietary drivers also provide libGL.so?

[SmilingHorse]

"Yeah, I would recommend you to turn on Email notifications at least."

So you think I check my email daily... This days I have a big bookmark folder with the subscriptions and email accounts I keep and once a week I follow up on them with the exception of ongoing conversations which I keep at another folder. Hell, I still don't have a facebook account since it forces me to stay-in-touch when all I want to do is rest up on my time off.

"the E17 composite module looks a lot more better than compton..."

Not better. More like, custom tailored. It's sorta like having that bounce effect smart-phones use to let you know the scroll is finished; But on a pc: It just doesn't work well regardless of how well it works on a smart phone. With E17 especially, I've found I don't iconify anything and just manage a dozen virtual desktops instead. I also don't have any transparency effects since everything is so pretty and functional. Point is, Compton does what it does just as good as the E17 compositor does what it does ;) Just think about this way: Regardless of how good MS Surface's tile GUI is said to be, it's absolutely terrible in Windows 8.

"who would use compton if E17's composite module is there?"

I just wanted to test it out since I'm so happy with how compton is operating with openbox :P Since I'm using a rather old build from Debian Sid I wanted to see how it will work with a more complete compositor. It was quite interesting but ended up feeling too out-of-place. Next week E17 should see a major release so I'll hopefully be enjoying the real thing if I'm lucky enough to manage getting my dev env working right ;)

"compton is created by technicians, E17 comes from the real artists..."

Very little can compare to E17. Gnome, KDE, Unity... E17 is just better than anything else out there in just about every category except maturity. Even this is starting to change now that it's coming to fruition. The EFL alone should be capable of replacing all the gui kits out there alone. And still, one "niche" alternative is openbox (and compton + tint2) which is what the CrunchBang community is all about. I also that think for laptops, the battery usage is still a very big deal. Finally, this might be just memory leaks from the old build, but E17 uses over double the RAM compton + openbox + tint2 use. Even triple \ quadruple at times ! So, as far as I can tell, the openbox\compton\tint2 combo has a few more years of usefulness in it :) e.g. Just the other night I had to run dcraw over 250gb of raws into tiffs and pngs. So, I logged off E17 and used my openbox \ compton \ tint2 session instead until the run was over.

"But, can't the packages of proprietary drivers also provide libGL.so?"

They probably do but I prefer using the free stuff when possible. When I could I used the nouveau drivers but I had to give up on those for the sake of games :D Come to think of it, did you ever manage to fully isolate the top left tearing ? I never had those issues with compton (only with xcompmgr) but I always used the mesa libgl so maybe that's why...

[richardgv]

So you think I check my email daily... This days I have a big bookmark folder with the subscriptions and email accounts I keep and once a week I follow up on them with the exception of ongoing conversations which I keep at another folder. Hell, I still don't have a facebook account since it forces me to stay-in-touch when all I want to do is rest up on my time off.

Ah, I see. I don't really like Facebook, either, because of the huge amount of boring notification emails I've gotten from it.

Not better. More like, custom tailored. It's sorta like having that bounce effect smart-phones use to let you know the scroll is finished; But on a pc: It just doesn't work well regardless of how well it works on a smart phone. With E17 especially, I've found I don't iconify anything and just manage a dozen virtual desktops instead. I also don't have any transparency effects since everything is so pretty and functional. Point is, Compton does what it does just as good as the E17 compositor does what it does ;) Just think about this way: Regardless of how good MS Surface's tile GUI is said to be, it's absolutely terrible in Windows 8.

You are definitely right, and thanks for your support, but at least I love the bouncing effect myself. :-)

Very little can compare to E17. Gnome, KDE, Unity... E17 is just better than anything else out there in just about every category except maturity. Even this is starting to change now that it's coming to fruition. The EFL alone should be capable of replacing all the gui kits out there alone. And still, one "niche" alternative is openbox (and compton + tint2) which is what the CrunchBang community is all about. I also that think for laptops, the battery usage is still a very big deal. Finally, this might be just memory leaks from the old build, but E17 uses over double the RAM compton + openbox + tint2 use. Even triple \ quadruple at times ! So, as far as I can tell, the openbox\compton\tint2 combo has a few more years of usefulness in it :) e.g. Just the other night I had to run dcraw over 250gb of raws into tiffs and pngs. So, I logged off E17 and used my openbox \ compton \ tint2 session instead until the run was over.

14MB private bytes for fvwm, 12MB for compton (looks pretty huge...), 12MB for tint2, 46MB for E17 here. I don't think 20MB really matter on a modern system, though.

They probably do but I prefer using the free stuff when possible. When I could I used the nouveau drivers but I had to give up on those for the sake of games :D

Huh, you aren't talking about our wrong dependencies in CPackConfig.cmake and _CMakeLists.txt? I mean. so we have to depend on something like libgl1-mesa-dev || libgl1-nvidia-glx || libgl1-fglrx-glx on Debian? On Gentoo we have a virtual/opengl meta-package.

Come to think of it, did you ever manage to fully isolate the top left tearing ? I never had those issues with compton (only with xcompmgr) but I always used the mesa libgl so maybe that's why...

Not really sure what you meant. Well, the full discussion in #7. Quite many people are complaining it's still tearing even with my --vsync, and some of them are using the Mesa drivers, too. I heard there at least was a bug in xf86-video-intel that breaks VSync sometimes.

Now replies to some of your old replies I just read:

If I was about to write some code, I would have picked up my dusty K&R and hacked around the code myself. Thing is, I haven't done any C in years (and I never done it properly). Besides, I figured it might be generic enough for me to get someone more competent interested. I suppose no harm in trying :D

I imagine developing with Python/Perl is much faster than doing the same withg C. You just have too many things to worry about in C (types, and memory, for example).

I'm presently using 4. Once I'm pulling over 16 windows, it all become a little too disorienting without them. Especially when two of them include over 20 open firefox tabs and way too much buffers and splits... I was actually using eclipse in the past but it became very sluggish for my (inefficient) multi-tasking style of work. Writing crappy code also doesn't help :8ball:

Holy... My brain doesn't do multitasking well, and I generally keep a very limited number of windows.

By the way, maybe you should turn this off in your configuration file:

inactive-opacity-override = true;

It makes inactive opacity override the window's _NET_WM_WINDOW_OPACITY. I turned it on in default configuration by mistake. In general you won't like this thing.

I'm only somewhat experienced with slow ipc \ high latency stuff: I wrote clients in python to a few Berkeley socket's RPCs from the GET PUSH level on a few occasions but I never wrote the server side. I suppose there's the multi threading \ processing stuff I've done that had message queueing and that sort of stuff but it was really like passing variables down to a function since I was already working on an abstracted layer and wasn't even dealing with the locks and such which you would be doing on C.

Thanks for all the info! :-) I'm more inclined to use dbus, though. What I want is an IPC library, that abstracts all IPC things for me, is flexible and could transfer data of different types without too much work on my side. Dbus looks like the de-facto standard, and its library can't be too bad, right?

And 30 lines main() ! That's just crazy :D

main() is short because the core is elsewhere. The initialization is in session_init(), main loop in session_run(), and session destruction in session_destroy(). The length of main() doesn't really affect anything.

[SmilingHorse]

"I don't think 20MB really matter on a modern system, though." I'm using the latest SVN (80135) right now and I'm looking at 150mb ram :D virt ram is around 600mb ! although this is mostly the icon caching, theme assets and backgrounds, turning it off isn't really an option since it will mean excessive file swapping and even cpu spikes on menu access. To be fair this is unavoidable unless you're willing to lose icons from the menu...

"I mean. so we have to depend on something like libgl1-mesa-dev || libgl1-nvidia-glx || libgl1-fglrx-glx on Debian?"

I use the Makefile so I wouldn't know... It's just a dependency I found hard to identify from missing header file error it gave when I first installed compton... It gave me something like libgl.h not found and googling it took a while since every distribution has it's own names for the mesa \ nvidia \ libgl stuff and they seems to be renamed ALOT :(

"and some of them are using the Mesa drivers"

I'm not sure but I think compiling with the mesa libgl doesn't mean you're using the mesa drivers... Anyhow, I'm running the nvidia drivers while compiling against the mesa libgl and aren't getting any tearing vsync on or off so I just thought it might be related. But if people were having it with the mesa drivers than it can't be right.

"Python/Perl is much faster"

yeah... you can't really hack code out with C. Everything requires careful planning and even the boilerplate needs more hands on attention in C. With python you can prototype stuff pretty fast... And it's not c++ \ java :)

"I generally keep a very limited number of windows."

From what I can tell the better you are at multi-tasking the worse you are at single tasking... The best programmer I know works with vi in bash and doesn't even run X... he get too distracted :) I really like coding stuff with him since the work divides evenly and both of us feel like the other guy got stuck with the hard \ boring stuff :D Only disadvantage is that my C skillz are rusted to oblivion...

"turn this off in your configuration file"

will do. Thanks for the heads up :P

"inclined to use dbus, though"

there's the low level dbus libs which are a nightmare and the glib (gtk) bindings... So it's probably a dependency or a lot of boilerplate... But you shouldn't be taking C advice from me... Ask someone else or give a try yourself. I'm just not a C programmer anymore.

"short because the core is elsewhere"

I was being sarcastic :D. it's 5000+ lines in a single source file so it's probably not very convenient for you to maintain :) should probably be fractured to 2-4 more files... But I suspect you're keeping it un-fractured to make the compile easy for end users. Not like the compiler minds...

[richardgv]

@SmilingHorse:

Huh, sorry for the latency. As my dad is at home watching me, I no longer have enough time to read your replies. Just a quick update today:

1. Yep, you are right, libdbus is a huge pain to use. But gdbus isn't fun, either: Too closely tied to glib, that I have to learn the whole glib thing to start using it, and I would have to link to so many extra libraries.
2. Another possibility is to embed a scripting language interpreter. Using another language as a bridge to dbus sounds too costly, so this language should be able to query X directly with a Xlib/XCB binding. I wish to embed Python 3, but seemingly no xlib/xcb binding exists for Python 3. (Managed to fix some syntax issues and configure script of xpyb to work under Python 3, but then I met a ton of C errors.) Perl has a XCB binding but looks pretty terrible.
3. I planned to work on #16 firstly. At least it will most likely not introduce new dependencies.

Seriously sleep-deprived I am...

[SmilingHorse]

"As my dad is at home watching me"

To be a kid again... But why are you trying so hard to quickly respond ? There are no open bugs or anything. Just take as much time as you like. It's not like you're on a deadline or anything :)

"so many extra libraries"

Yeah... I figured you knew that so I didn't mention it :) It looks to me like that aside from Gnome and EFL - which both are inappropriate since you're trying to target non-Gnome- and-E17 WMs, your easy dbus options are slim to none when it comes to C.

"embed a scripting language interpreter"

The reason you're not finding much of those is because C is binded to other languages, not the other way around. What people usually do is expose C structs and then write the bindings in the target language. e.g. Python's ctype: http://docs.python.org/dev/library/ctypes.html The other way around is very hard and most of the time just plain crazy since most language are written in C to begin with.

But why are skipping all the obvious C solutions? dBus is just sockets anyhow so if you're not going raw sockets, maybe you'd be better off with semaphores if you're only doing small messages, or maybe fifo for bigger ones ? Take a look at this: https://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_14.html Easy, reliable, standard; What more can you ask ? :D

You know, When you first mentioned an IPC I figured you wanted to have something like a GUI that can make compton change settings live so it will be easy to test settings and make adjustments to the settings file. Now, I'm starting to get the impression you want to extend compton beyond it's design limits. That is, add plugin support.

If you're serious about this and think a you can avoid reinventing the wheel, then I suggest you take a look here: https://projects.mini-dweeb.org/projects/unagi/repository/revisions/master/show/src This is awesome's compositor of choice, Unagi. Though I'm not a user of it or of awesome, and I find it a little over-engineered for the job, it's plugin api is definitely something you might want to look at. At the very least it should demonstrate what not to do :D