AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2025-01-10 20:50:12 +00:00
Code Issues Projects Releases Wiki Activity
GTK is a multi-platform toolkit for creating graphical user interfaces.
82,883 Commits 1,248 Branches 814 Tags 579 MiB
C 90.8%
CSS 7.3%
Meson 0.5%
SCSS 0.4%
GLSL 0.3%
Other 0.5%
79d4cae50b
Go to file
Sergey Bugaev 79d4cae50b boxlayout: Rework natural opposite size-for-size computation 
...and separate it from minimum opposite size-for-size computation.
Previously, the two were intertwined.

In broad terms, gtk_box_layout_compute_opposite_size_for_size () gathers
minimum and natural size requests of the child widgets *along* the box's
own orientation, and then uses gtk_distribute_natural_allocation () to
distribute the available size (the size being measured for, minus any
spacing) between them. This mirrors what gtk_box_layout_allocate () does
to distribute the allocated size. Once the available space along the
box's orientation has been distributed and a size assigned to each
child, gtk_box_layout_compute_opposite_size_for_size () measures
children in the opposite orientation for those sizes assigned to them,
and then does the usual aggregation (namely, MAX + baseline handling) on
the resulting list of size requests.

In commit 76c4673944 "boxlayout: Fix
broken min-size-for-opposite-size", it has been discovered that simply
distributing available size based on the size requests in that one
orientation -- the way that gtk_distribute_natural_allocation () does it
-- leads to reporting incorrect minimum opposite size. This is not an
issue during allocation, since there, the size requests of the children
already account for the available space in the other orientation. To fix
this for the measurement logic, a new code path was introduced that uses
binary searching to reliably discover the minimum size in the other
orientation.

The minimum size found by the binary search, however, was not getting
directly used to report the box' minimum size. Instead, the size
requests of child widgets would get measured based on the discovered
minimum size (just as they are during allocation), and then fed into the
generic gtk_distribute_natural_allocation-based logic described above.
Since minimum size is (assumed to be) monotonic, and both distributing
extra space towards natural sizes and applying expand flags could only
increase the size of the children along the box's own orientation, the
minimum size in the opposite orientation that got computed should match
the one that was found during binary searching.

But there are still issues with this. For one thing, the implementation
had a bug, in that it wouldn't actually re-measure size requests based
on the final minimum size discovered during binary searching; instead,
it would use the values left in sizes[i].minimum_size and
sizes[i].natural_size by distribute_remaining_size (). Those were indeed
often the measurements for the found minimum size (in case the last
iteration of the binary search accepted the candidate size). In case the
last iteration took the other branch, ruling out the candidate size,
those leftover measurements would simply be incorrect, and the box would
likely end up reporting minimum opposite size being smaller by 1px
compared to the correct value. This is a simple bug in the code and not
a fundamental issue with the approach.

A more serious issue is the following: the distribution of child sizes
along the box's own orientation that achieves minimum size in the
opposite orientation might be quite different from the one that would be
considered "natural", as in describing the layout that produces the
natural size in the opposite orientation. For a specific example,
cosider a box containing a wrappable GtkLabel and a GtkPicture. Since
the picture's minimum size is 0 (assuming can-shrink is not unset), the
layout that achieves minimum size in the opposite orientation is the one
that gives the label as much size along the box's own orientation as the
label is able to make use of, only assigning the remaining part (if any)
to the picture. Moreover, the actual size assigned to the picture may be
even smaller than the remaining part, since the picture's natural size
request will be measured based on that (small) minimum size in the
opposite orientation, and the picture expanded from its minimum size of
0 up to that size. Measuring the natural size in the opposite
orientation will then likely produce the same value as the minimum size
again. This will happen even if the available size in the box's own
orientation was enough to fit the label and the picture at their natural
sizes, which would then allow them to ask for their full natural sizes
in the opposite orientation. The only reason for this is that for
measuring the natural size, we picked a size distribution that was
optimized for producing the smallest possible minimum size, and one has
little to do with the other.

Similarly, consider the case of a horizontal box containing a label that
has its natural width limited by setting max-width-chars. Such a label
is able to make use of more horizontal space than its natural width to
reduce its height request, when that is required. By computing the
minimum height possible and considering label's minimum and natural
widths for that height as the basis for the following distribution of
available width, we'll force the label to take up more width that its
natural size even though we're not actually vertically constrained,
which will then result in it asking for less height than its normal
natural height.

The reftests added in this commit demonstrate the issues in the cases
described above.

Moreover: there is an optimization that we'd like to implement, namely
it should be possible to avoid the binary search in case of a single
inconstant-size child, and instead ask the child about its minimum size
directly. However, in order to fit this approach into the existing
gtk_distribute_natural_allocation-based logic, we have to rely much more
on the child widget reporting consistent width-for-height and height-
for-width measurements. An initial attempt to implement this
optimization, https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6569,
ran into many cases where this just wasn't so in practice, which broke a
number of layouts, and while specific individual cases of inconsistent
measurements are being fixed, merging this optimization is just not
feasible. Separating computation of minimum and natural sizes allows the
direct measurement of a single child optimization to only affect the
computation of minimum size, without either breaking natural size or
running into contradictory measurements.

So, this patch does just that.

distribute_remaining_size () no longer fills sizes[i].minimum_size and
sizes[i].natural_size; it now only calculates the minimum size, and that
calculated size is used directly for the reported minimum size of the
box. gtk_distribute_natural_allocation-based logic is only used for
measuring the natural size in the opposite orientation, and the minimum
and natural sizes passed to it are just overall minimum and natural
sizes. (The produced layout is still kind of being used for measuring
baselines, but those are hopefully only used with constant-size
children, whose baseline and size doesn't depend on the distribution.)

Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
2024-12-26 16:43:50 +03:00
.gitlab/issue_templates Mention the new button in the issue template 2024-11-26 16:55:52 -05:00
.gitlab-ci Merge branch 'android-container' into 'main' 2024-12-13 23:59:02 +00:00
build-aux flatpak: Fix build 2024-10-15 01:38:03 +02:00
demos gtk-demo: Don't create extra windows 2024-12-21 10:39:09 -05:00
docs docs: Mention AccessKit in various places 2024-12-20 14:01:21 -05:00
examples bloatpad: Call gtk_init in main 2024-10-21 21:17:00 -04:00
gdk Tightly integrate tree updates with surface rendering, so there's always at least one tree update before each surface commit, as required by Newton, without the AccessKit context having to do extra surface commits itself. This should also prevent multiple tree updates per frame across platforms. 2024-12-20 09:34:51 -05:00
gsk gsk: Simplify font handing in the parser 2024-12-15 14:11:14 -05:00
gtk boxlayout: Rework natural opposite size-for-size computation 2024-12-26 16:43:50 +03:00
modules gstreamer: Fix small memleak 2024-11-04 21:50:26 +01:00
po Update Russian translation 2024-12-09 12:29:13 +00:00
subprojects Forgotten commit 2024-12-20 13:56:50 -05:00
tests tests/parallel: build on 32bit platforms without warnings 2024-12-14 18:59:52 +01:00
testsuite boxlayout: Rework natural opposite size-for-size computation 2024-12-26 16:43:50 +03:00
tools updateiconcache: Fix GOptionContext leak in main 2024-11-12 21:16:18 -05:00
.clang-format clang-format: The link to code formatting has changed 2024-02-12 15:51:41 +01:00
.editorconfig Add editorconfig file 2021-10-28 18:17:02 +01:00
.flake8 Add flake8 configuration file 2023-07-05 10:12:20 +01:00
.gitignore gitignore: Add .vscode directory 2024-10-18 12:02:03 +02:00
.gitlab-ci.yml ci: Try to handle glib+gobject-subprojects 2024-12-10 19:03:11 -05:00
AUTHORS AUTHORS: Some updates 2023-08-02 20:14:02 +00:00
CONTRIBUTING.md Drop references to the GNOME wiki from the docs 2024-07-04 12:03:19 +01:00
COPYING Change FSF Address 2012-02-27 17:06:11 +00:00
gtk.doap DOAP: Replace non-existing mailing lists with GNOME Discourse URL 2023-09-19 18:21:17 +02:00
gtk.supp Fix some typos in gtk.supp 2023-06-09 08:28:36 -04:00
lsan.supp lsan: Don't suppress glib and gio leaks 2024-04-21 22:02:44 -04:00
make-pot Add new printf patterns to make-pot 2022-11-05 11:23:53 +01:00
make-release.sh Small tweak to the release script 2024-12-06 21:02:45 -05:00
meson.build Forgotten commit 2024-12-20 13:56:50 -05:00
meson.options Cosmetic typo fix 2024-12-20 14:03:21 -05:00
NEWS Post-release version bump 2024-12-06 11:47:41 -05:00
NEWS.pre-1.0 Split NEWS 2018-01-10 19:06:45 -05:00
NEWS.pre-2.0 Split NEWS 2018-01-10 19:06:45 -05:00
NEWS.pre-3.0 Split NEWS 2018-01-10 19:06:45 -05:00
NEWS.pre-4.0 Split NEWS for pre-4.0 changes 2021-01-19 10:40:09 +01:00
README.md Remove my insertion from the README 2024-12-20 10:13:55 -05:00

README.md

GTK — The GTK toolkit

Build status

General information

GTK is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK is suitable for projects ranging from small one-off projects to complete application suites.

GTK is a free and open-source software project. The licensing terms for GTK, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties.

GTK is hosted by the GNOME project (thanks!) and used by a wide variety of applications and projects.

The official download location

The official web site

The official developers blog

Discussion forum

Nightly documentation can be found at

Nightly flatpaks of our demos can be installed from the GNOME Nightly repository:

flatpak remote-add --if-not-exists gnome-nightly https://nightly.gnome.org/gnome-nightly.flatpakrepo
flatpak install gnome-nightly org.gtk.Demo4
flatpak install gnome-nightly org.gtk.WidgetFactory4
flatpak install gnome-nightly org.gtk.IconBrowser4

Building and installing

In order to build GTK you will need:

You will also need various dependencies, based on the platform you are building for:

If you are building the Wayland backend, you will also need:

  • Wayland-client
  • Wayland-protocols
  • Wayland-cursor
  • Wayland-EGL

If you are building the X11 backend, you will also need:

  • Xlib, and the following X extensions:
    • xrandr
    • xrender
    • xi
    • xext
    • xfixes
    • xcursor
    • xdamage
    • xcomposite

Once you have all the necessary dependencies, you can build GTK by using Meson:

$ meson setup _build
$ meson compile -C_build

You can run the test suite using:

$ meson test -C_build

And, finally, you can install GTK using:

$ sudo meson install -C_build

Complete information about installing GTK and related libraries can be found in the file:

docs/reference/gtk/html/gtk-building.html

Or online

Building from git

The GTK sources are hosted on gitlab.gnome.org. The main development branch is called main, and stable branches are named after their minor version, for example gtk-4-10.

How to report bugs

Bugs should be reported on the issues page.

In the bug report please include:

  • Information about your system. For instance:

    • which version of GTK you are using
    • what operating system and version
    • what windowing system (X11 or Wayland)
    • what graphics driver / mesa version
    • for Linux, which distribution
    • if you built GTK, the list of options used to configure the build

    Most of this information can be found in the GTK inspector.

    And anything else you think is relevant.

  • How to reproduce the bug.

    If you can reproduce it with one of the demo applications that are built in the demos/ subdirectory, on one of the test programs that are built in the tests/ subdirectory, that will be most convenient. Otherwise, please include a short test program that exhibits the behavior. As a last resort, you can also provide a pointer to a larger piece of software that can be downloaded.

  • If the bug was a crash, the exact text that was printed out when the crash occurred.

  • Further information such as stack traces may be useful, but is not necessary.

Contributing to GTK

Please, follow the contribution guide to know how to start contributing to GTK.

If you want to support GTK financially, please consider donating to the GNOME project, which runs the infrastructure hosting GTK.

Release notes

The release notes for GTK are part of the migration guide in the API reference. See:

Licensing terms

GTK is released under the terms of the GNU Lesser General Public License, version 2.1 or, at your option, any later version, as published by the Free Software Foundation.

Please, see the COPYING file for further information.

GTK includes a small number of source files under the Apache license:

  • A fork of the roaring bitmaps implementation in gtk/roaring
  • An adaptation of timsort from python in gtk/timsort