This commit changes the behavior of window size computation and the
default size properties to:
* The default-width and default-height properties are updated to the
current window size unless the size is fixed by e.g. being maxmized,
tiled etc.
* The compute-size semantics are to just pick the default size, or if
not adequate, use the measured size, and consequently update the
default size, unless unresizable.
* gtk_window_get_size() is removed, what's more likely relevant is the
gtk_window_get_default_size() which will now contain more sensible
values.
Various places that used gtk_window_get_size() were updated to use
gtk_window_get_default_size() to remember and restore previous sizes.
This also changes the default value of 'default-width' and
'default-height' from -1 to 0. The gtk builder simplify tool is taught
how to omit when the default size is set to both -1 and 0.
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
This signal does not work on native file choosers,
and it exposes internals of the widget that should
not be public. And it is just not very interesting.
This signal does not work on native file choosers,
and it exposes internals of the widget that should
not be public. And it is just not very interesting.
We were stepping on our own toes, by first setting
up a save entry and telling the filechooserwidget
about it, and then nuking it by setting a title
on the headerbar. The filechooserwidget wasn't
ready for the entry to die without anybody telling
it.
This fixes a crash when using the filechooser for
print-to-file in the print dialog.
GtkFileChooser's API predates GIO by a few years, so it started off with
filenames and URI as character arrays. After introducing GIO as a
dependency, the API included GFile-based entry points.
It's much more appropriate to use GFile everywhere, as we want to
encourage people to use GIO instead of passing random bytes to low level
POSIX API.
See: #2455
The FileChooser ToolKit (fctk) had its own machinery to handle default
sizes which was completely busted and trying to marshal random numbers
through the widget hierarchy that maybe made sense in 2012 but don't do
now.
Get rid of it, just keep the dialog's GSetting - which funnily enough
used to be written by the dialog but written by the widget.
But that's fctk for you.
This reverts commit 2ed533c3e1.
This also made the filechooser dialog not save the window size anymore,
which does not depend on the gtk_window_get_position() removal.
I was a little overzealous when going
for the new default handling here. We
can't switch to gtk_widget_activate_default
before we actually handle the default.activate
action.
Instead, use the new way of activating default.
I think most of the default handling in
GtkFileChooserDialog should be dropped, but
for now this keeps things working.
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.
Since setting a clip is mandatory for almost all widgets, we can as well
change the size-allocate signature to include a out_clip parameter, just
like GtkCssGadget did. And since we now always propagate baselines, we
might as well pass that one on to size-allocate.
This way we can also make sure to transform the clip returned from
size-allocate to parent-coordinates, i.e. the same coordinate space
priv->allocation is in.
We were only storing the dialog size on unmap, but resetting to the
stored default value more often, e.g. on focus-out. This was causing
the dialog to 'jump back' to its remembered size after the user
manually resized it, leading to frustration and bug reports.
Instead, save the dialog size on every ::size-allocate of the toplevel.
To avoid needlessly spamming dconf, only write the new value if it
changed.
