search

santigimeno / node-ewmh

Implementation of the Extended Window Manager Hints (EWMH)
ISC License
18 stars 1 forks source link

make EMWH event emitter. Add 'ActiveWindowChange' event #1

Closed sidorares closed 11 years ago

sidorares commented 11 years ago

use case: http://stackoverflow.com/questions/19840459/linux-get-notification-on-focused-gui-window-change/19847998#19847998

sidorares commented 11 years ago

oops, did it in virtualbox's vim. sorry for inconsistent tabs. Will fix tomorrow

santigimeno commented 11 years ago

Hey, that was fast! Thanks for the PR.

I really like this feature but I don't know if it's going to work as it is. Let me explain my train of though, and correct me if I'm wrong:

I'm assuming this module is going to be used by a window manager implementation that's is going to pass the X client (and root window) when creating the emwh object. If we're depending on the event-mask set on the root window by this X client we can be in trouble anytime the window manager decides to modify this mask and may remove the PropertyChange value. I think we have 3 options: 1- Assume the window manager using this module is not going to remove the PropertyChange on the event-mask of the root window. 2- Make this module use a separate X client. 3- Don't implement anything that relies on events.

I think 1 is the better option but it should be documented somewhere.

What do you think? Does any of this make any sense to you?

Thanks

sidorares commented 11 years ago

EMWH is communication protocol between window managers and clients - I think we should cater both (e.i functions to check if window wants to have delete button and some functions to handle deletion sequence - WM_DELETE message etc)

Option 2 is not really good as there is restriction on maximum number of connections, and it's usually 512 ( http://unix.stackexchange.com/questions/25273/what-is-the-max-number-of-x-clients )

So I incline to 1 but yeah, I share your worries and 3 might be an option.

santigimeno commented 11 years ago

Thanks!

I've merged and then committed some style modifications.

I've been thinking about the handling of events and this is what I've come up with:

1 - We should no start listening to events unless there's a listener for 'ActiveWindowChange'. 2 - Once we detect a listener, 'monkey-patch' ChangeWindowAttributes so before calling the real ChangeWindowAttributes we can keep track of the event-mask the WindowManager wants for the root window and also add PropertyChange in case it's not included in that mask 3 - Once there are not listeners left, restore the event mask to the value stored in 2 and also restore ChangeWindowAttributes function.

@sidorares How does this sound to you?

santigimeno commented 11 years ago

@sidorares BTW, I have added you as a colaborator

sidorares commented 11 years ago

thanks!

1-3 sounds reasonable this is similar to what I do at https://github.com/sidorares/ntk/blob/master/lib/window.js#L83 except for ChangeWindowAttributes monkey-patching (in ntk I assume I'm the only user of this connection).