Those property features don't seem to be in use anywhere.
They are redundant since the docs cover the same information
and more. They also created unnecessary translation work.
Closes#4904
Drop support for the org.gnome.Sysprof3.Profiler
D-Bus interface. It is not really used, and if
we don't expose it, we can simplify our profiler
infrastructure.
Drop apis and code related to appmenus from
both GtkApplication and GtkApplicationWindow.
We still keep the menubar support, since it
is needed for system integration on OS X.
Fixes: #2731
Before this commit, adding GtkWidgetAction to class private data would
require copying the actions to each subclass as they were built or
modified. This was convenient in that it is a sort of "copy on write"
semantic.
However, due to the way that GTypeInstance works with base _init()
functions, the "g_class" pointer in GTypeInstance is updated as each
_init() function is called. That means you cannot access the subclasses
class private data, but only the parent class private data.
If instead we use a singly linked list of GtkWidgetAction, each subclass
has their own "head" yet all subclasses share the tail of the
GtkWidgetAction chain.
This creates one bit of complexity though. You need a stable way to know
which "bit" is the "enabled" bit of the action so we can track enabled
GAction state. That is easily solved by calculating the distance to the
end of the chain for a given action so that base classes sort ahead of
subclasses. Since the parent class always knows its parent's actions, the
position is stable.
A new dynamic bitarray helper also helps us avoid allocations in all the
current cases (up to 64 actions per widget) and dynamically switches to
malloc if that is to ever be exceeded.
These don't take a duration, instead they call g_get_monotonic_time() to
and subtract the start time for it.
Almost all our calls are like this, and this makes the callsites clearer
and avoids inlining the clock call into the call site.
When we use if (GDK_PROFILER_IS_RUNNING) this means we get an
inlined if (FALSE) when the compiler support is not compiled in, which
gets rid of all the related code completely.
We also expand to G_UNLIKELY(gdk_profiler_is_running ()) in the supported
case which might cause somewhat better code generation.
usec is the scale of the monotonic timer which is where we get almost
all the times from. The only actual source of nsec is the opengl
GPU time (but who knows what the actual resulution of that is).
Changing this to usec allows us to get rid of " * 1000" in a *lot* of
places all over the codebase, which are ugly and confusing.
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
