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
Expanders used to be 16px high. With the move from the gtk2 rendering
to gtk3 rendering they shrunk to 12px, making them hard to see, because
it's now the icon which is 16px high and the icon contains transparent
borders.
This makes the HighContrast theme use 24px icons instead, to restore
16px expanders. This may expander some containers a bit.
Closes#1046
GtkTextHandle was neglected by whoever removed the ::draw signal,
leaving it entirely broken. Update to using GtkGizmo so we can
implement snapshot of text handles.
Input has received a revamp too, handling is done through a
GtkGestureDrag and coordinate calculations simplified by storing
the delta to the hotspot on ::begin instead of ::update, as this
value is constant throughout the gesture. Widget state management
on crossing events happens implicitly, so no longer needs to be
done here.
Last but not least, CSS has also been updated so handles are
rendered at the correct size and proportion, and with the padding
that code expects of it.
Set up a gesture on the sidebar rows to detect pointer clicks on
it. The row DnD management has been moved to the row widget itself,
it makes more sense even if the drag is began from the sidebar widget.
We still need a drag gesture both on front (capture) and back (bubble)
to handle dragging from both the GtkWindow widget and chrome in the
headerbar. But we can do it through 2 drag gestures, instead of special
event handling code.
This has been broken since we switched key event delivery to follow
the same semantics than pointer/touch. There, GTK+ grabs will influence
the topmost widget during event delivery, rendering the toplevel
unable to handle key navigation. The toplevel must handle those key
events in an explicit manner then.
We don't render the keyboard focus rectangle yet, but I assume that's
something else.
Use an event controller on GtkFontChooserDialog, a nice side effect
is that we can use gtk_event_controller_key_forward() and
gtk_search_entry_set_key_capture_widget() instead of passing events
around for dialog search.
