Commit Graph

25 Commits

Author SHA1 Message Date
Marco Trevisan (Treviño)
7a17e236f7 Use free_full on GSList's instead of foreach + free
GList's used in legacy code were free'd using a g_slist_foreach + g_slist_free,
while we can just use g_slist_free_full as per GLib 2.28.

So replace code where we were using this legacy codepath.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/576
2019-05-15 14:49:56 -05:00
Carlos Garnacho
3de6f7ebfe core: Emit MetaStartupNotification::changed on sequence completion
This way handlers that want to know the get_complete() status will be able
to do so without further delays.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/541
2019-04-17 18:42:09 +02:00
Carlos Garnacho
38ff01d6d0 core: Add MetaStartupSequence::complete signal
It was a vfunc so far, but we want things subscribing to it.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/541
2019-04-17 18:42:04 +02:00
Carlos Garnacho
40103d6f41 core: Account for completed sequences in feedback updates
The sequences may stay completed in the list (eg. pending a focus request),
it's then confusing to show the "wait" cursor icon until they are really
gone.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/541
2019-04-17 18:42:00 +02:00
Carlos Garnacho
ab7ef5f8bf core: Fix differing sequence timestamp precision expectations
Calculations were being done at places accounting on usec precision,
however those are still treated as having msec precision at places. Let's
consolidate for the latter since it requires less changes across the board
and usec precision doesn't buy us anything here.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/541
2019-04-17 18:41:13 +02:00
Carlos Garnacho
f0b9654deb core: Remove startup sequences after timeout
The complete/remove semantics were split to cater for presenting windows,
so we must now separately do both here.

Related: https://gitlab.gnome.org/GNOME/mutter/issues/501
2019-03-18 18:06:01 +00:00
Niels De Graef
1c6ea5d1db Use a consistent style for enum braces
https://gitlab.gnome.org/GNOME/mutter/merge_requests/361
2019-02-28 09:31:01 +01:00
Jonas Ådahl
ff507273d2 startup-notification: Silence warning
Warning in question:

../src/core/startup-notification.c:646:16: error: unused variable ‘display’ [-Werror=unused-variable]
2019-01-18 18:18:57 +01:00
Carlos Garnacho
f033d0e846 core: Add MetaLaunchContext
This is a GAppLaunchContext subclass meant to replace usage of
GdkAppLaunchContext in gnome-shell.

Launch contexts get created from the MetaStartupNotification as
they are closely related. The messaging underneath depends on
the availability of a X11 display, if there is one we go through
it (and libsn). If there is none, we still create startup sequences
manually for wayland clients.
2019-01-18 17:03:57 +00:00
Carlos Garnacho
4d92979b43 core: Make MetaStartupSequence/Notification public
This will be preferred over SnStartupNotification, as exposed
through MetaDisplay.
2018-11-23 12:27:13 +00:00
Carlos Garnacho
4a69a0d7f7 core: Shuffle startup notification object creation
Hook properly to MetaDisplay, instead of having it be a singleton.
2018-11-23 12:27:13 +00:00
Carlos Garnacho
91ce24d4b4 core: Add extra properties to MetaStartupSequence
Those that we use from SnStartupSequence over the place...
2018-11-23 12:27:13 +00:00
Carlos Garnacho
26fbd56a95 x11: Refactor the X11 startup notification bits into src/x11
Only one little bit left in MetaDisplay, because SnStartupSequence
is exposed in API there. These bits will be removed in future
commits.
2018-11-23 12:27:13 +00:00
Carlos Garnacho
576cd08088 core: Rename MetaStartupNotificationSequence to MetaStartupSequence
The name was excruciatingly long and not that much more descriptive.
2018-11-23 12:27:13 +00:00
Jonas Ådahl
2f4a68c8c3 Clean up include macros mess
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.
2018-11-06 17:17:36 +01:00
Armin Krezović
390314adfb Rename errors.[ch] to meta-x11-errors.[ch]
Also rename meta_error_trap_* to meta_x11_error_trap_* and
move meta-x11-errors.c to src/x11

https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:17 +02:00
Armin Krezović
9333a6da75 Make bell and libstartup-notification bits work without X11
https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:16 +02:00
Armin Krezović
1d5e37050d Stop using MetaScreen where it is unnecessary
https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:16 +02:00
Armin Krezović
cd8f4259be Move screen size and cursor setting to MetaDisplay
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
2018-07-06 19:47:16 +02:00
Armin Krezović
dacc041d0c Switch meta_error_trap functions to MetaX11Display
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
2018-07-06 19:47:16 +02:00
Armin Krezović
18779109de Start populating MetaX11Display
- 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
2018-07-06 19:47:16 +02:00
Jonas Ådahl
cd225c4e19 Always use the default screen
GDK doesn't support multiple screens, so effectively we don't either.
Lets stop pretending we do.

This fixes a few -Wdeprecated warnings.

https://bugzilla.gnome.org/show_bug.cgi?id=769070
2016-07-23 10:55:02 +08:00
Luca Bruno
c325a0bebf Fix string format in startup notification to be a gint64
https://bugzilla.gnome.org/show_bug.cgi?id=762407
2016-07-04 22:34:31 +02:00
Jonas Ådahl
0882bce989 startup-notification: Ensure provided timestamp is always a 64 bit integer
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
2016-03-07 11:19:08 +08:00
Carlos Garnacho
56beedf9f2 core: Refactor startup notification into a separate object
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
2016-02-19 17:41:03 +01:00