This is rarely what you want, so lets turn it off
by default.
Update the one place in our demos where we want to
draw a value, add support for this to gtk-builder-tool,
add a test and mention this change in the migration
guide.
Make these functions return FALSE if they did not
return the exact position that was requested.
Adapt tests.
Based on a patch by Sebastien Wilmet
Fixes: #506
Make sure that every object property in GTK has accessors for getting
its value (if the property is readable) or setting it (if it is
writable).
Since we are still missing accessors, the test is allowed to
fail for now. Sadly, mesons xfail support is busted, so we just
disable the test entirely :(
Based on initial work by Benjamin Otte.
Related: #2440
GtkBuildable's get_name()/set_name() methods may shadow
GtkWidget's methods. Avoid that by renaming the API to
get_buildable_id()/set_buildable_id(), which also reflects
the name of the XML attribute the API refers to.
https://gitlab.gnome.org/GNOME/gtk/-/issues/3191
A radiobutton without indicator is really just a togglebutton with a
group.
A radiobutton with indicator is really just a checkbutton with a group.
Make checkbutton its own widget not inheriting from GtkButton.
GtkRadioButton could be removed but it stays for now.
Radiobutton && !draw-indicator => Togglebutton
Checkbutton && !draw-indicator => Togglebutton
Radiobutton && draw-indicator => CheckButton + group
GTK will not up front know how to correctly calculate a size, since it
will not be able to reliably predict the constraints that may exist
where it will be mapped.
Thus, to handle this, calculate the size of the toplevel by having GDK
emitting a signal called 'compute-size' that will contain information
needed for computing a toplevel window size.
This signal may be emitted at any time, e.g. during
gdk_toplevel_present(), or spontaneously if constraints change.
This also drops the max size from the toplevel layout, while moving the
min size from the toplevel layout struct to the struct passed via the
signal,
This needs changes to a test case where we make sure we process
GDK_CONFIGURE etc, which means we also needs to show the window and
process all pending events in the test-focus-chain test case.
It's not a portable API, so remove it. The corresponding backend
specific functions are still available, if they were implemented, e.g.
gdk_macos_monitor_get_workarea() and gdk_x11_monitor_get_workarea().
Make GdkEvents hold a single GdkDevice. This device is closer to
the logical device conceptually, although it must be sufficient for
device checks (i.e. GdkInputSource), which makes it similar to the
physical devices.
Make the logical devices have a more accurate GdkInputSource where
needed, and conflate the event devices altogether.
We don't pay attention to item-type anymore, so
drop the item-type property and the _for_item_type()
constructor, and allow passing NULL to the regular
constructor.
We don't make this constructor transfer-full, since
the selection filter model is not a wrapping model
like the others. It is more like fork than a wrap.
This is for consistency with other wrapping list constructors.
We want them all to be transfer full, allow-none.
Also make the constructor return GtkMultiSelection *.
Update all callers.
Make gtk_tree_list_model_new() take the root model
as first argument, and make it transfer full, for
consistency with other wrapping list constructors.
Update all callers.
Still missing here: Make the model property writable,
and allow passing NULL in the constructor.
Some widgets have different roles after they are constructed, so we need
to allow changing the role defined by the class. We should still avoid
setting a role after the GtkATContext has been created.
To build a better world sometimes means having to tear the old one down.
-- Alexander Pierce, "Captain America: The Winter Soldier"
ATK served us well for nearly 20 years, but the world has changed, and
GTK has changed with it. Now ATK is mostly a hindrance towards improving
the accessibility stack:
- it maps to a very specific implementation, AT-SPI, which is Linux and
Unix specific
- it requires implementing the same functionality in three different
layers of the stack: AT-SPI, ATK, and GTK
- only GTK uses it; every other Linux and Unix toolkit and application
talks to AT-SPI directly, including assistive technologies
Sadly, we cannot incrementally port GTK to a new accessibility stack;
since ATK insulates us entirely from the underlying implementation, we
cannot replace it piecemeal. Instead, we're going to remove everything
and then incrementally build on a clean slate:
- add an "accessible" interface, implemented by GTK objects directly,
which describe the accessible role and state changes for every UI
element
- add an "assistive technology context" to proxy a native accessibility
API, and assign it to every widget
- implement the AT context depending on the platform
For more information, see: https://gitlab.gnome.org/GNOME/gtk/-/issues/2833