Calling gtk_menu_item_get_label on a GtkSeparatorMenuItem would
otherwise create a GtkLabel child, increasing the vertical size request
to that of the child label.
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.
Avoid the ugly priv->tool_box==NULL check in ::add (and ::remove) by
just not using template xml for this small class. Also, make sure the
GtkBin child is properly set and implement remove to also properly
remove it. Remove the manual widget margins and add some CSS for it.
Also switch to simply using a GtkCenterBox.
GdkContentFormatsBuilder is currently not introspectable, as it does not
have a GType. We can turn it into a boxed type, but we need to implement
memory management for it.
The current gdk_content_formats_builder_free() function returns a newly
constructed value, so we cannot use it as a GBoxedFreeFunc; additionally
copying a GdkContentFormatsBuilder contents would make it a bit odd, as
you could get multiple identical GdkContentFormats out of the copies.
A simple approach is to model the GdkContentFormatsBuilder API to follow
the GBytes one: use reference counting for memory management, and have
a function to release a reference, return a GdkContentFormats, and reset
the GdkContentFormatsBuilder state.
For language bindings, we can provide a get_formats() function that
returns the GdkContentFormats instance and resets the builder instance,
leaving the reference count untouched.
For C convenience we can keep gdk_content_formats_builder_free(), and
make it a wrapper around gdk_content_formats_builder_get_formats(), with
the guarantee that it'll free the builder instance regardless of its
current reference count.
https://bugzilla.gnome.org/show_bug.cgi?id=793097https://blogs.gnome.org/otte/2018/02/03/builders/
The result won't be visible anyway. This also prevents problems with
widgets that create some resource the size of the widget, like
GtkGLArea. It also keeps us from snapshotting revealers with
size 0.
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
The main GDK thread lock is not portable and deprecated.
The only reason why gdk_threads_add_timeout() and
gdk_threads_add_timeout_full() exist is to allow invoking a callback
with the GDK lock held, in case 3rd party libraries still use the
deprecated gdk_threads_enter()/gdk_threads_leave() API.
Since we're removing the GDK lock, and we're releasing a new major API,
such code cannot exist any more; this means we can use the GLib API for
installing timeout callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
The main GDK thread lock is not portable and deprecated.
The only reason why gdk_threads_add_idle() and
gdk_threads_add_idle_full() exist is to allow invoking a callback with
the GDK lock held, in case 3rd party libraries still use the deprecated
gdk_threads_enter()/gdk_threads_leave() API.
Since we're removing the GDK lock, and we're releasing a new major API,
such code cannot exist any more; this means we can use the GLib API for
installing idle callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
We need to have two lists: one, with the list of sources that need to be
introspected; and one with the list of sources that contain only private
symbols.
This reduces the amount of source files that the introspection scanner
needs to traverse, and thus the build time.
After commit ffef28a7e8,
gtk-icon-browser was spewing critical warnings when
changing sections. Avoid that by respecting the return
value of gtk_tree_model_get_iter.
GtkGesture is a GtkEventController. gtk_event_controller_dispose() calls
_gtk_widget_remove_controller(). That NULLs the pointer-to-Controller in
our EventControllerData but does not delete said ECData from our GList.
Subsequently, if that same Widget gets unparent()ed, that method calls
unset_state_flags(), which leads to doing reset_controllers() if we are
insensitive. Now, unlike most most other loops over the GList of ECData,
reset_controllers() does not skip nodes whose pointer-to-Controller is
NULL. So, we call gtk_event_controller_reset(NULL) and get a CRITICAL.
This surfaced in a gtkmm program. The Gesture is destroyed before the
Widget. The Widget then gets dispose()d, which calls unparent()… boom.
I didn’t find an MCVE yet but would hope this logic is correct anyway:
The simplest fix is to make the loop in gtk_widget_reset_controllers()
skip GList nodes with a NULL Controller pointer, like most other such
loops, so we avoid passing the NULL to gtk_event_controller_reset().
In other, live cases, _gtk_widget_run_controllers() loops over the GList
and removes/frees nodes having NULL Controllers, so that should suffice.
But this clearly was not getting a chance to happen in the failing case.
https://bugzilla.gnome.org/show_bug.cgi?id=792624
Otherwise, gtk_widget_get_window returns NULL and we can't successfully
perform a grab via the later gdk_set_grab call. This fixes the entry
completion in the file chooser not working.
Filter models rely on views taking a ref on every node
they care about. GtkIconView was not doing that. Amazingly,
this has never shown up in a bug so far, until I spotted
the fallout in gnome-font-viewer.
This was causing us to leak, in the following scenario:
1) gtk_widget_destroy is called on a GL area
2) dispose is run and clears the context
3) the GL area is unrealized, but the context is already cleared,
so we leak all the GL buffers
Handle the situation that a GL texture might remain
in use (e.g. by a slow frame, or by the recorder)
In that case, we can't modify it but must use a
new one. Keep a pool of GL textures for this eventuality.
g_list_model_get_item is transfer full, so we need
to drop the references we get from it. This was showing
up while testing the GL texture cache in GtkGLArea.
We already check right before this one whether child->pack != packing
and if so, we continue to the next iteration. So, no need to check again
whether the inverted condition child->pack == packing is true, because
it is.
For the one update_layout_width call in size_allocate, we can just use
the passed-in allocation width instead of a separate (relatively slow)
gtk_widget_get_width call.
Just append a texture node.
Note that this is not 100% done yet. The GL area really
needs to keep a pool of textures, and only reuse them
once the GdkTexture object is gone.
We were failing to change the sort order for the
default sort column in some cases. Fix that, and
add a testcase for this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=792459
Add a testcase for the previous fix
We no longer emit this signal. You can use various gestures
and event controllers instead. If you need to catch raw
motion events, use the generic ::event signal.
This replaces the use of ::button-press-event. There's two
issues with this commit:
1) We don't have a good way to do the equivalent of
gdk_event_triggers_context_menu with gestures
2) We have to defer to and idle to avoid ordering
issues with the treeviews own gestures
This function is misnamed - it is only ever relevant for
windows. And with the ::hide-on-delete property , it is
no longer necessary to use the signal for this simple case.
These signals are no longer used in GTK+ and have a (not quite
perfect yet) replacement with GtkEventControllerMotion.
If you need to catch the raw events, the generic ::event
signal still works.
This lets us replace the ::enter/leave-notify-event handlers.
Not that there is a FIXME here - we currently can't get the
crossing mode from the event controller, so we have to fall
back to gtk_get_current_event().
This lets us replace the ::enter/leave-notify-event handlers.
Not that there is a FIXME here - we currently can't get the
crossing mode from the event controller, so we have to fall
back to gtk_get_current_event().
This signal is unused in GTK+ and configure events are handled
internally by GtkWindow.
If you need to catch configure events, the generic ::event
signal still works.
This signal is not used in GTK+, and has a suitable
replacement with GtkGesture and its subclasses.
If you need to catch the raw touch events, the generic ::event
signal still works, too.
This signal is not used in GTK+, and has a suitable
replacement with GtkEventControllerScroll.
If you need to catch these events, the generic ::event
signal still works, too.
The event is not useful at all, so we are better off
with a signal that doesn't have it, and it is only
relevant on toplevel windows, so we don't need it on
GtkWidget.
With this commit, delete events no longer go through the
::event, ::delete-event, ::event-after widget signals,
but just cause the ::close-request signal on GtkWindow to be
emitted.
I don't think there is a way to get a delete event
on this popup - there's no window decorations, no close
button, etc. So no need to handle ::delete-event.
These functions are entirely trivial, their documentation
is much longer than their implementation, and it contains
an example that is annotated as "don't do this"...
Add a way to toggle debug output on and off
from the inspector. For now, we don't add a
log viewer here, since that has the risk of
deadlock until we've the logging completely
separated by display, and also requires us
to install a log writer function, which
libraries are not supposed to do.
As far as possible, use per-display debug flags.
This will minimize the debug spew that we get from
the inspector if it is running on a separate display.
Since gtk_widget_get_allocation doesn't return x/y values relative to
the GdkWindow anymore, we need to manually translate the widget
coordinates here.
Using get_preferred_size here does not work since it computes the
minimum height for the minimum width, but we want to know the minimum
height for the current width.
event_widget is not modified anymore after the assignment from
handle_pointing event and we need the event's user data set for the
_gtk_window_check_handle_wm_event call.
So the slider does not overlap the value label. Since the value label is
allocated at the widget edge in gtk3, the correct fix here would
probably be to remove the 12px padding we apply to the entire scale and
instead apply it only to the trough.
This is a bit of filechooser internals that gets shared with
nautilus, which is fine, but it shouldn't be part of our
public API. There are no other users than nautilus.
When the toolbar style is both-horiz, and the item
is not important, we were not centering the icon in the
same way as in gtk3. The reason is that we overlooked
the expand child property being set to TRUE in this case.
We should not tie the sensitivity of the select button
to the tweak action, since there may be fonts which are
selectable, but not tweakable.
Instead, enable the select button when a font is selected,
as it should be.
These can't be returned as part of the font description,
so we need new api for them. For now, this is just readonly
properties. Maybe these should be writable too, eventually.
Add a button the dialog's header bar that lets us
switch to a second page where we can customize
the selected font.
Make the font chooser widget export an action that the
dialog can use for the button. This has some advantages:
- we can export not just the toggle state, but also enabled
- we can reuse the same enabled state to make the select
button insensitive when no font is selected
To determine whether a font is selected, listen to changes
of the list selection. And ensure that the font chooser is
in an initial state when mapped, even if we close the dialog
from the tweak page.
Both GtkWidget and GtkContainer had similar docs regarding hfw/wfh
geometry management. Move these just to GtkWidget. Also make sure the
examples compile, port everything from gtk_preferred_* to measure and
replace some occurrences of "container" with "widget" where container
was just used to refer to a widget with child widgets.