We were leaking the GBytes for the image memory, which is a
noticeable memleak to anyone who's casually running a memory monitor.
Go KDE users!
Closes#1200
The min size on the oriented axis used to come from style props with
default values in the source file, used if the theme did not provide a
min size in CSS. When the style props were removed, so was any notion of
a minimal size for proressbars' main axis, meaning that now progressbars
without expand or any other source of min size were just tiny specks.
The right place to do that was always the theme, so in our themes now,
fix that by copying the old default values for the style properties; see:
https://gitlab.gnome.org/GNOME/gtk/issues/1191#note_259393https://gitlab.gnome.org/GNOME/gtk/blob/gtk-3-24/gtk/gtkprogressbar.c#L92
The result should be the same in that (A) the min size is now what it is
in GTK+ 3 & (B) an app/user can override the theme exactly the same way.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1192
7733f646d6 renamed GdkDragContext to
GdkDrag, which broke the docs, as a reference to
gdk_drag_context_get_type() still exists. This commit renames the type
accordingly and adds GdkDrop.
(A) Put a space in "scrolled window" like the other doc comments
(B) Say "i.e." rather than "ie."
(C) Fix grammar from "makes [...] exactly reaches" to "exactly reach"
Rename gdkdnd.h to gdkdrag.h, to go along with gdkdrop.h
This commit includes the necessary updates to the X11, Wayland
and Broadway backends. Other backends have to be updated separately.
This is to go along with the newly introduced GdkDrop.
This commit includes the necessary updates to the X11, Wayland
and Broadway backends. Other backends have to be updated separately.
It looks like this got dropped during the move from autotools and never
restored. I can see why, since making it work wasn't a hugely fun task!
Notes on some less then obvious details:
* PlacesSidebar is private now and didn't seem to be to be particularly
easy to adapt to, so this moves to checking for it by name, not TYPE.
I couldn't find a (fast) better way; if you know how, please clean up
* added 2 casts to avoid warnings from the new type-propagating ref()
* GdkClipboard and GdkContentProvider need some properties dodged
* GtkToolItemGroup is gone
* fixed indentation and used TypeName:property-name syntax in a print()
Also update the cursor surfaces of every seat when an output changes
scale. This could for example happen when a monitor scale is changed via
Settings.
If we check it too early, we will not unset priv->draw_neeeded, which
will then cause queue_draw() calls to not have an effect later. And that
causes changes in opacity to not register.
Closes#1180
The comment above explains neatly why subclassing GtkButton for
GtkColorButton was a bad idea. Nowadays it's a GtkWidget subclass
containing a GtkButton so let's remove the special case here.
Binds this property to the button's label, allowing a model button to
have text with markup.
This will be convenient for buttons like 'Online Accounts <sup>↗</sup>'.
When deciding whether or not to emulate a press event, we're translating
the last event coordinates and mutating the given event structure
unconditionally.
We should modify the newly created GdkEvent copy, since it's what we're
going to use when emitting the press event.
This avoids mutating a constant GdkEvent and global state, and also
avoids a compiler warning.
The idea is that GTK+ 4 will be an epoch, API-wise.
Everything that was around for 4.0 has been there
since the beginning of the epoch and doesn't need
markers.
If the parent get_preedit_string implementation returns a nonnull
zero-length string, then we ignore it, which is almost fine. We have to
free it, though.
Fixes#1174
