Had another stab at this here : http://cr.i3wm.org/patch/566
Special mentions:
In src/manage.c sending in NULL when "Defer setting focus after the
'new' event" is done feels wrong, but I'm frankly not sure if that
comment matches the con_set_urgency below it. It's resetting a urgency
flag here if one is "lost"? Maybe sending in WM_HINTS is the right
thing to do? Or maybe sending WM_HINTS/etc is generally stupid, and it
should be one reason called "window_event_change" and another one for
"focus_blocked"?
Disclaimer : I've been a dev for a long time, but I haven't done
anything in C for ages, so the code might be rubish. If I'm told that
and you decide to do this in a much cleaner way, I will not have my
feelings hurt ;)
Gonna have a stab at fixing the Xdummy stuff now.
On Sun, Jun 1, 2014 at 1:49 PM, Michael Stapelberg <michael@xxxxxxxx> wrote:
Hi Anders,
Anders Aagaard <aagaande@xxxxxxxxx> writes:
Alternately I could add some code to start sending events forI think adding an event for urgency with the reason sounds reasonable.
con_set_urgency (since focus request that fails now sets an urgency),
but it wouldn't be usable for my use case unless I also add a reason
for the urgency change. Which I guess could be
demands_attention/focus_request and wm_hints? Not sure about that last
one, where it's really coming from ;).
It'd be good to fix that. We call Xdummy with -config /dev/null which isI have the tests working with nvidia 331.67. Can you be more specific
about what breaks on your machine?
It's an issue with glx, I've got an nvidia optimus setup, so I'm not
terribly surprised. I could probably get it working fine by not
loading glx, but it was easier to setup a VM for it. (I should point
out it fails starting the X session, so it's not the test running part
that's broken).
supposed to not use the system X11 config at all. If that has changed,
it should be updated to continue running in an isolated-enough
environment.
--
Best regards,
Michael
