The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
Split X11 specific parts into MetaX11Display. This also required
changing MetaScreen to stop listening to any signals by itself, but
instead relying on MetaDisplay forwarding them. This was to ensure the
ordering. MetaDisplay listens to both the internal and external
monitors-changed signal so that it can pass the external one via the
redundant MetaDisplay(prev MetaScreen)::monitors-changed.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
They are X11 specific functions, used for X11 code. They have been
improved per jadahl's suggestion to use gdk_x11_lookup_xdisplay and
gdk_x11_display_error_trap_* functions, instead of current code.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
- Moved xdisplay, name and various atoms from MetaDisplay
- Moved xroot, screen_name, default_depth and default_xvisual
from MetaScreen
- Moved some X11 specific functions from screen.c and display.c
to meta-x11-display.c
https://bugzilla.gnome.org/show_bug.cgi?id=759538
The libsn API provides its timestamps in the "Time" X11 type, which is
usually is a typedef for "unsigned long". The type of the "timestamp"
parameter of StartupNotificationSequence is a signed 64 bit integer.
When building on an architecture where a "unsigned long" is not 64 bit,
we'd then pass a 32 bit unsigned integer via a va_list where a signed 64
bit integer is expected causing va_arg to read past the passed 32 bit
unsigned integer.
Fix this by ensuring that we always pass the expected type via the
va_list. Also change the internal timestamp type from time_t (which
size is undefined) to gint64, to avoid any potential overflow issues.
https://bugzilla.gnome.org/show_bug.cgi?id=762763
This is kind of in a middle ground at the moment. Even though it
handles sequences not coming from libsn, they're added nowhere at
the moment, we'll rely on the app launch context being in the x11
side at the moment.
Also, even though we do create internal sequence objects, we keep
exposing SnStartupSequences to make gnome-shell happy, we could
consider making this object "public" (and the sequence objects with
it), things stay private at the moment.
https://bugzilla.gnome.org/show_bug.cgi?id=762268
