A number of applications want to track the state of the screensaver.
Make this information available as a boolean property. We only listen
for state changes when ::register-session is set to TRUE.
This is implemented for unsandboxed D-Bus access by talking
directly to org.gnome.ScreenSaver or org.freedesktop.ScreenSaver,
and for sandboxed D-Bus by using a (new) portal API.
A Quartz implementation is missing.
When a remote instance of a GTK application implementing the Startup
Notification protocol gets spawned it will pass the startup sequence
ID as "platform data" to the main instance. Thus, we need to make sure
that the startup sequence gets completed in that case, since the remote
instance won't do it by itself, since it won't map any top level window.
Checking for this "platform data" in the implementation of the after_emit()
virtual method in the primary instance should be a good place to do so, since
the existence of such data proves that a remote instance has been spawned.
https://gitlab.gnome.org/GNOME/gtk/issues/1084
The DESKTOP_STARTUP_ID gets cleared early after the process is spawned,
meaning that it's too late at add_platform_data() to pick it up and send
it over to the primary instance, as it will be always unset at that point.
To solve this, we use the new gdk_display_get_startup_notification_id()
method to pull the startup notification ID for the application, if present,
out of the display and pass it over to that primary instance.
https://gitlab.gnome.org/GNOME/gtk/issues/1084
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
GDK has a lock to mark critical sections inside the backends.
Additionally, code that would re-enter into the GTK main loop was
supposed to hold the lock.
Back in the Good Old Days™ this was guaranteed to kind of work only on
the X11 backend, and would cause a neat explosion on any other GDK
backend.
During GTK+ 3.x we deprecated the API to enter and leave the critical
sections, and now we can remove all the internal uses of the lock, since
external API that uses GTK+ 4.x won't be able to hold the GDK lock.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
This function returns global session state that may
not be available to applications (e.g. in sandboxed
environments), and is not needed by applications,
so just drop it, instead of keeping a function around
that can't be guaranteed to work.
g_resources_enumerate_children expects the path to end
in a '/' (even though thats not stated in the docs), and
will copy it if that isn't the case. Avoid the copy
by putting a '/' there to begin with.
This has several benefits:
- Less code in GtkApplication. The accels handling is something
self-contained, and GtkApplication now delegates the work.
- For the accels functions, there is now a distinction between static
functions and functions in the gtkapplicationaccelsprivate.h header,
which makes the code easier to understand, because we have a good
overview just by reading the header.
- The struct _GtkApplicationPrivate is now easier to find instead of
being in the middle of the file.
https://bugzilla.gnome.org/show_bug.cgi?id=764879
These will become the functions present in the
gtkapplicationaccelsprivate.h header.
The gtk_application_accels functions deal with detailed_action_name's
instead of action_and_target's. action_and_target is an implementation
detail of Accels.
The added function prototype is temporary, it'll be removed in a later
commit.
https://bugzilla.gnome.org/show_bug.cgi?id=764879
Presently, Gtk will only send a startup notification completion message
for the first window that is shown. This is not good for the case of
GtkApplication, where we are expected to participate in
startup-notification for all windows.
We have avoided this problem by manually emitting the startup complete
message from after_emit in GtkApplication.
Unfortunately, this causes problems for windows that are shown with a
delay. It is also a dirty hack.
The reason for the original behaviour is simple: there is a static
boolean in gtkwindow.c which controls it. We remove this.
Instead, clear the startup notification ID stored in GDK when sending
the completion message. GtkApplication will re-set this the next time
an event comes in which needs startup-notification handling. In the
non-GtkApplication case, newly shown windows will still not send the
message, since the cookie will have been cleared.
Finally, we remove the hack from GtkApplication's after_emit.
This will probably cause some regressions in terms of lingering startup
notification messages. The correct solution here is to always use
gtk_window_present(), including when merely opening a new document (with
a new tab, for example).
https://bugzilla.gnome.org/show_bug.cgi?id=690791
When the $(resource_prefix)/gtk/help-overlay.ui resource exists,
load a GtkShortcutsWindow from it for each GtkApplicationWindow,
and set up a win.show-help-overlay action with accels <Primary>F1
and <Primary>? to show it.
gtk_application_shutdown clears the impl member, so all
callbacks, signal handlers, etc that might still be triggered
between a shutdown call and the return from the mainloop
better be prepared to deal with impl being NULL.
It can apparently happen that we get focus in events
on windows after gtk_application_shutdown() has been
called. Avoid an unnecessary crash in this case.
See
https://bugzilla.redhat.com/show_bug.cgi?id=1176339
