Fix compton-trans -c

[ghost]

The pipeline used to retrieve the WID of the active window returns a bad WID because xprop returns several hex numbers and "." in the sed regex is greedy. For instance, running xprop -root -notype _NET_ACTIVE_WINDOW gives me:
_NET_ACTIVE_WINDOW: window id # 0x1a0003d, 0x0
Filtering this output with the sed substitution then gives 0x0, since the first "." matches everything up to the last hex number.

The fix is simply to grep hex numbers instead of using a sed substitution, and then choose the first one.

[richardgv]

Thanks for the patch! I merged it just now.

The EWMH standard says, _NET_ACTIVE_WINDOW represents "the window ID of the currently active window or None if no window has the focus" -- not "the windows IDs". I suppose a WM should NOT attempt to place a 0x0 at the end of the property. Would you mind telling us what WM you are using?

An issue is grep -o is NOT defined in the POSIX standard (as far as I could see). That's not a problem for recent versions of GNU grep and BSD grep. Maybe the option is missing in HP-UX, but... We shall see if there's anybody complaing about this. 😄

By the way, using a more descriptive title (such as "compton-trans: Fix focused window detection when _NET_ACTIVE_WINDOW contains more than one value" or "compton-trans: Tighten the parsing logic of _NET_ACTIVE_WINDOW") would give the reader a better idea of what the commit is about when browsing the history.

[ghost]

You're welcome, always a pleasure to share :)

My WM is Xfce 4.12, to be honest I didn't check the EWMH standard but I was indeed a bit surprised of such an obvious bug, if Xfce is not compliant with EWMH it may explain this mess!

I had a doubt about grep -o being standard, at some point I thought about using grep -P but it's definitely not standard xD The problem being here that without grep -o it's just a pain, neither sed nor regular grep support non-greedy quantifiers; you could use awk though (or obviously Perl but it adds another dependency...). It's a shame that xprop doesn't have an option for a less verbose output, parsing this kind of output is always a bit fragile...

About the commit message, well I have mixed feelings, the summary is supposed to be less than 72 characters (optimally about 50 characters), and I'm often struggling to fit in this limit so for once I was happy to find a short message :p But you're probably right, being a bit more specific wouldn't have hurt.