The API encouraged wrong usage - most of the users were indeed wrong.
Use the correct version instead:
gtk_icon_theme_get_for_display (gtk_widget_get_display ())
Add a facility to register and install actions
at class init time. The intended use for these
actions is for
a) context and other model-based menus
b) key bindings
Most of these actions are going to be stateless,
so add separate apis for the simple and stateful
cases.
We avoid creating an action group for these by
teaching the action muxer about these actions.
The action muxer also maintains the enabled
state for these actions.
Similar to previous removals of g_cclosure_marshal_VOID__VOID we can remove
other marshallers for which are a simple G_TYPE_NONE with single parameter.
In those cases, GLib will setup both a c_marshaller and va_marshaller for
us. Before this commit, we would not get a va_marshaller because the
c_marshaller is set.
Related to GNOME/Initiatives#10
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.
It just gets overridden to do something else, as the 1st GtkWidget’s
class_init() adds it as a binding to toggle tooltips with the keyboard.
The last entity to hook it (& return TRUE) is the only one who gets it.
So, worse: If users needed to manually set accels for a ShortcutsWindow,
coincidentally waited until after the 1st GtkWidget init() to do it, &
copied what GtkApplication said in an attempt to be good & consistent —
they inadvertently broke the keyboard tooltips (except for users with a
GDK_KEY_KP_F1 – whatever that is) as their handler blocked GtkWidget’s.
So, one side has to drop this accelerator, and it seems clear that being
able to open tooltips with the keyboard is more important than having a
second accel for the help-overlay. We can make up a replacement later.
https://gitlab.gnome.org/GNOME/gtk/issues/626
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
