9 Commits

Author	SHA1	Message	Date
Olivier Fourdan	1546989845	xwayland: Add MetaWindowXwayland ... MetaWindowXwayland derives from MetaWindowX11 to allow for some Xwayland specific vfunc that wouldn't apply to plain X11 windows, such as shortcut inhibit routines. https://bugzilla.gnome.org/show_bug.cgi?id=783342	2017-12-18 13:15:09 +01:00
Jasper St. Pierre	39357fc242	window-props: Don't make another round-trip to fetch the opaque region ... We already have the property value from our property fetching.	2014-07-13 22:51:25 -04:00
Jasper St. Pierre	a7b7213017	window-props: Use the standard property type system for _NET_WM_WINDOW_TYPE	2014-07-10 15:05:40 -04:00
Jasper St. Pierre	031154a400	window-props: Use the standard property type system for WM_WINDOW_ROLE ... There seems to be no reason we can't just use this.	2014-07-10 14:56:23 -04:00
Jasper St. Pierre	3c0fae74f1	window: Move get_toplevel_xwindow to window-x11	2014-06-16 18:29:38 -04:00
Jasper St. Pierre	5b7dff7a57	window: Move constructors to the respective header files	2014-05-20 15:59:17 -04:00
Jasper St. Pierre	2101c8357b	Move sync_request_* handling mostly to window-x11	2014-04-29 17:58:23 -04:00
Jasper St. Pierre	7bf0c77193	window: Move _NET_WM_ALLOWED_ACTIONS setting to window-x11 as well	2014-04-29 17:58:21 -04:00
Jasper St. Pierre	8f151842fb	Start moving X11 implementation to its own subdirectory ... This is specifically about managing X11 windows, not necessarily running as an X11 compositor. By that I mean that this code is still used for XWayland windows, and event handling is still and modesetting / monitor management is still in core/. This is also a fairly conservative move. We don't move anything like screen.c or bell.c in here, even though those are really only for X11 clients.	2014-03-18 15:44:11 -04:00