| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
I want to export it as public API, so better choose a nice name.
I also want to split the public API from the implementation details, so
this file goes to gtkcanvasvectorimpl.c for now.
|
|
|
|
|
|
|
|
| |
Instead of normalized rectangles, make eval() return unnormalized ones.
This means that we need to normalize before allocating - but it also
means we can scale(-1) the widget if we want to. That is not implemented
yet, but we can.
|
|
|
|
| |
This allows referencing the actual allocation as well as the bounds.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of lots of special cases, just have 3 types:
* sums
* constants
* variables
And implement it in a new GtkCanvasVec2 struct and use it for points and
sizes.
Simplifies te code a lot.
Requires some changes though so that now all variables are
preinitialized instead of queried on demand.
|
| |
|
|
|
|
|
| |
If a widget needs more size than given via its bounds, expand it
according to its origin.
|
|
|
|
|
| |
Since the box is no longer specialized, it's easy to query it.
Make that happen.
|
|
|
|
|
| |
A box is a point, a size and an origin. All the specializing shall
happen in size and point.
|
| |
|
| |
|
|
|
|
|
|
| |
A meek attempt at exporting numbers into the sizing magic.
Update the demo to really center the label now
|
| |
|
|
|
|
|
|
|
| |
A canvas is awidget that allows placing widgets onto the canvas using
sophisticated relationships expressed via points, sizes and boxes.
This is all very experimental.
|
|\
| |
| |
| |
| |
| |
| | |
theme: selectable labels legibility
Closes #5017
See merge request GNOME/gtk!4840
|
|/
|
|
|
|
| |
- don't set fg color for selections
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/5017
|
|\
| |
| |
| |
| | |
gtk-demo: Cosmetics
See merge request GNOME/gtk!4839
|
| |
| |
| |
| | |
Tweak the complicated textview demo a bit.
|
|\ \
| | |
| | |
| | |
| | | |
tests: Add testdatatable
See merge request GNOME/gtk!4838
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add a GtkColumnView scrolling performance test similar to the one used
previously in https://gitlab.gnome.org/GNOME/gtk/-/issues/3334.
The test creates a table with 20 columns and 10,000 rows and scrolls it
to a random position every frame, while measuring the frame times.
There is a commandline flag to pick the cell widget between none (for
benchmarking raw column view scrolling) and various label types. There
is also a commandline switch to disable automatic scrolling in case a
manual assessment is desired. Finally, there's an argument for
controlling the number of columns.
|
|\ \
| | |
| | |
| | |
| | | |
ci: Force the fedora image for the publish-docs job
See merge request GNOME/gtk!4837
|
|/ /
| |
| |
| |
| | |
Otherwise every CI runner might decide to use a different default
image, and we'll end up on one that doesn't have curl.
|
|\ \
| | |
| | |
| | |
| | | |
Rework listitemfactory
See merge request GNOME/gtk!4835
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I'm not sure this is API safe, but it is necessary if we want to support
section items and canvas items.
If it's deemed API-unstable, we have to copy this object and deprecate
this one.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This way, we no longer prescribe the use of either GtkListItem or
GtkListItemWidget.
This means we can use it in other places, such as for custom section
header objects or with my Canvas ideas.
|
| | |
| | |
| | |
| | |
| | | |
Add a clear() function and call it from dispose() instead of using
set_paintable().
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Force quark creation for templates
See merge request GNOME/gtk!4836
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ /
|/| | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
gdk: Replace GTK_USE_PORTAL env var with GDK_DEBUG flag
See merge request GNOME/gtk!4829
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
It's a debug flag, so make it clear that it is one.
Related: Clowns on the Arch wiki on
https://wiki.archlinux.org/title/Uniform_look_for_Qt_and_GTK_applications#Consistent_file_dialog
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
shortcutcontroller: fix typo in property docs
See merge request GNOME/gtk!4827
|
| | | |
| | | |
| | | |
| | | | |
followup of d7dae84af248bc198601cad89441724c5345504d
|
|/ / / |
|
|\ \ \
| |_|/
|/| |
| | |
| | | |
[x11] Fix coordinate space of rect in gdk_x11_surface_get_frame_extents when called on popups.
See merge request GNOME/gtk!4820
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
called on popups.
If we take the early return we don't unscale this at the bottom of the
function, causing wrong coordinates in HiDPI screens.
This bug also affects GTK3 (I noticed this running Firefox tests on X).
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
gtk-demo: Remove mention of directories in picker examples
See merge request GNOME/gtk!4825
|
| | | |
| | | |
| | | |
| | | | |
Those were removed in https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2909.
|
| | | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
inspector: Inspect
See merge request GNOME/gtk!4822
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
And launch a new inspector.
The location of that button is rather random - I had no idea where to
put it.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We filter by display, so the inspector window should show up only when
inspecting the inspector.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When inspecting the inspector, we want to create mutiple displays here.
If we need this to be global, we should store it per-inspected-display.
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
wayland: Add supports for xdg_toplevel.bounds
See merge request GNOME/gtk!4261
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The GdkToplevelSize struct already has the concept of "bounds", which
means the largest size a window should reasonably have. It's practically
the equivalent of the monitor the window is intended to be mapped on,
with the "struts" (e.g. panels) cut out. It's used by GTK to use this
information to calculate a default window size that is "lagom" (swedish;
not too large, not too small).
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Implement gtk_window_export_handle for other backends
See merge request GNOME/gtk!4824
|
| | |_|/ / /
| |/| | | | |
|