Using an image() fallback from svg to png doesn't make too
much sense, since the svg is always used (unless librsvg is
not present), while the png icon is faster and cheaper to
load and thus preferable.
Also, "ie" wasn't very clear, but fixing that to "i.e." would cause
truncation of the summary when processed by bindings using doxygen. So,
I replaced it with "in other words", which is no _less_ clear, at least.
It was suggested that the project files to be moved to win32/, so that we can
have one less layer of directories we need to go down into to reach the project files.
So we can set the css name of a widget to something that's not related
to the class name. If the css-name property is set to NULL, we will
still fall back to the one set using gtk_widget_class_set_css_name which
is alwasys non-NULL since GtkWidget itself sets it to "widget".
See the implementation of gtk_entry_create_layout():
pango_attr_list_splice() is used to add the PangoAttrList of the preedit
string. And that is done *after* applying the PangoAttrList of the
"attributes" property.
https://bugzilla.gnome.org/show_bug.cgi?id=776868
We now have GTK_CSS_AFFECTS_CONTENT for properties that have an effect
on content rendering.
Using GTK_CSS_AFFECTS_ICON is wrong for icon-transform and icon-filter
as they don't change the icon, just how the icon is rendered, so we use
GTK_CSS_AFFECTS_CONTENT for those.
We also introduce GTK_CSS_AFFECTS_POSTEFFECT for opacity and filter -
properties that affect the whole drawing of the widget by applying an
effect after everything is said and done.
...which treats the first '.' in doc comments as the end of the summary.
So, e.g., in gtkmm, get_kinetic_scrolling() is currently summarised as
"Changes the behaviour of @scrolled_window wrt." Not very informative!
No need for a period there & anyway, the phrase "wrt to" is superfluous,
and we have space to actually say "with regard to", so just do that now.
Instead of
-gtk-icon-effect: dim;
-gtk-icon-effect: hilight;
we now use
-gtk-icon-filter: opacity(0.5);
-gtk-icon-filter: brightness(1.2);
respectively.
This node essentially implements the feColorMatrix SVG filter. I got the
idea yesterday after looking at the opacity implementation.
It can be used for opacity (not sure if we want to) and to implement a
bunch of the CSS filters.
If the signal handler ends up changing the label text,
the link is no longer around to update the css node.
Check for this possibility to avoid a crash here.
Homogeneous branches repeated the calculation/assignment of the initial
space available to children. This avoids that by shuffling some code.
Perhaps more importantly, in doing that, I ended up with some ambiguous
names, and Company and I realised how vague the pre-existing naming was.
"size" becomes "extra_space", as this is what it represents. Conversely,
"extra" becomes "size_given_to_child" (albeit still given out in two
different ways depending on whether the Box is homogeneous). My hope is
that these sections of code are now somewhat less baffling than before!
Now that every call to GtkCellArea is a snapshot call and no more cairo
calls are left, move the actual differentiation between Cairo and
Snapshot down to the cell renderer.
I had originally thought I'd use GskShadow for box-shadow, but didn't in
the end.
So now it's only used for text-shadow and icon-shadow, and those don't
have a spread.
VLAs are not supported by Visual Studio and possibly other compilers that
are supported by GTK+-3.90+, and probably never will be, although it is a
C99 specification, and it became optional for C11. It is also not a part
of the newer compiler requirements that are listed out for GTK+-3.90.x.
There exist concerns about the implementation of VLAs in compilers that
support them as well, so change it to a g_newa() approach.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
This causes the snapshotting algorithm to dump all widget nodes into
their own container node. We then name that group accordingly (ie
"GtkSwitch<0xdeadbeef>") so you can easily see which node belongs where.
The feature is toggleable in the inspector's visual tab.
There's a few problems with it, becuse GtkSnapshot optimized container
nodes away if they are not needed, so we are losing some widgets...
When the first/last color stop is not at 0%/100%, we need to start the
repeating at their offsets and not at 0%/100%.
Attached reftest demonstrates the problem.
Instead of making people intiialize a rectangle and then applying border
radius manually, provide a constructor that does it for them.
While doing that, also allow people to instead request the padding box
or the content box.
Refactor all relevant code to use this new constructor.
... and make the icon rendering code use it.
This requires moving even more shadow renering code into GSK, but so be
it. At least the "shadows not implemented" warning is now gone!
The node draws a solid CSS border, which can be used to cover everything
but dashed and dotted borders (double, groove, inset, ...).
For different border styles, we overlay multiple nodes and set their
colors to transparent for sides with non-matching styles.
It turns out, some simple getters - such as
gdk_drawing_context_get_clip() - love copying things before returning
them.
I guess somebody has to burn cycles...
When the background-clip of the background is smaller than the
background-clip of blended images, not pushing a group is wrong.
Test testing exactly that included.
This uses the new push()/pop() mechanism to its fullest extent when
implementing transitions. It's fun to inspect the results in the
inspector.
Crossfades don't work yet, they continue using a Cairo fallback.
A side effect of the stack conversion is that widget-factory now uses
snapshots for a lot more things.
It is now possible to call push() subfunctions for simple container
nodes with just a single child. So you can for example
gtk_snapshot_push_clip() a clip region that all the nodes that get
appended later will then obey.
gtk_snapshot_pop() will then not return a container node, but a clip
node containing the container node (and similar for the transform
example).
This is implemented internally by providing a "collect function" when
pushing that is called when popping to collects all the accumulated
nodes and combine them into the single node that gets returned.
To simplify things even more, gtk_snapshot_pop_and_append() has been
added, which pops the currently pushed node and appends it to the
parent.
The icon rendering code has been converted to this approach.
Instead of appending a container node and adding the nodes to it as they
come in, we now collect the nodes until gtk_snapshot_pop() is called and
then hand them out in a container node.
The caller of gtk_snapshot_push() is then responsible for doing whatever
he wants with the created node.
Another addigion is the keep_coordinates flag to gtk_snapshot_push()
which allows callers to keep the current offset and clip region or
discard it. Discarding is useful when doing transforms, keeping it is
useful when inserting effect nodes (like the ones I'm about to add).
Instead of having a setter for the transform, have a GskTransformNode.
Most of the oprations that GTK does do not require a transform, so it
doesn't make sense to have it as a primary attribute.
Also, changing the transform requires updating the uniforms of the GL
renderer, so we're happy if we can avoid that.
I'm about to move children handling to the container node, which means
the generic code can no longer assume children APIs existing.
So rewrite the treemodel to work without it.
gsk_render_node_get_bounds() still exists and is computed via vfunc
call:
- containers dynamically compute the bounds from their children
- surface and texture nodes get bounds passed on construction
We want to split nodes into containers and nodes that do actual drawing.
So pushing nodes that do drawing is exactly the wrong thing.
Also fix up GtkPopover. There's no need for it to push anything.
When running uninstalled tests with GtkApplication on an autobuilder with
a fake session bus, warnings will cause the tests to abort. The GNOME
session manager, the Xfce session manager, and the Inhibit portal are all
not needed for normal operation of GTK, so we should not log warnings if
they are not found.
As well as not being present on a fake session bus, it's also not
expected that they'll be present on all platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=774784
... with gtk_list_box_get_row_at_y. It would be nice to avoid the
'find' versus 'get' discrepancy since we are planning to expose it as
public API.
https://bugzilla.gnome.org/show_bug.cgi?id=776187
It does weird clipping that
(a) nobody likes
(b) is hard to support in the new rendering world.
So we take the easy way out.
The actual frame is now drawn by the frame node around the label.
GtkCellView has a gadget, so peopl can do all their shenanigans with
CSS.
And the original use case (overriding the background so that the
cellview's GdkWindow shares the background color of the combobox) is
outdated since we have transparent backgrounds.
It's using a GtkCssPositionValue, even though that name is wrong. But
the functionality of managing 2 lengths is exactly what we want.
Nobody is using this yet.
These only exist for the window dragging which does not exist anymore
currently. It will be reintroduced later in a form that does not require
these handlers.
That way we can capture both the actual changes (clip region) and the
area that was redrawn (render region), which in OpenGL might not be
identical.
Nothing shows the render region yet though...
GtkListBox is not a windowed widget anymore so we can't use
gtk_widget_get_window. Just directly access priv->view_window instead to
get the right window.
For a menu mode CB with wrap_width == 0 and an active item, that item is
selected in gtk_combo_box_menu_popup. Selection causes the MenuShell to
activate and hence take a grab. This was done before the menu was popped
up. A patch distributed in Debian sid - after being proposed on our BZ -
revealed that on the 1st popup of any such ComboBox, within grab_add,
the MenuShell's toplevel's GdkWindow is NULL. This causes a Gdk-CRITICAL
assertion fail on the 1st time opening any such CB, on Debian and if
that patch were merged to GTK+. By selecting after popup, we ensure the
MenuShell is realised before its grab_add and so avoid the critical.
https://bugzilla.gnome.org/show_bug.cgi?id=771242
and remove gsk_renderer_get_for_display().
This new function returns a realized renderer. Because of that, GSK can
catch failures to realize, destroy the renderer and try another one.
Or in short: I can finally use GTK on Weston with the nvidia binary
drivers again.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Instead of having a gsk_renderer_set_window() call, pass the window to
realize(). This way, the realization can fail with the wrong window.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
We were producing org.symbolic.png from org.gnome.Recipes-symbolic.svg,
which is not useful. Look for the last dot in the original name, to
produce the expected org.gnome.Recipes-symbolic.symbolic.png instead.
Since at-spi-atk commit 96621a5e95 fixed PropertyChange notifications
for AccessibleParent, setting the parent will result in a call to
ref_state_set() which assumes that the object is fully initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=774939
While GtkEventController implementations today are all GtkGesture, it is
possible to create a GtkEventController manually. This is an extrac check
to ensure we only add gestures to the list.
https://bugzilla.gnome.org/show_bug.cgi?id=774760
We need to unrealize the children manually for that to happen, but so it
goes.
The order is necessary because we want the renderer to still be alive
while children are unrealizing.
We no longer have GtkPlug nor GtkWin32EmbedManifest for GTK+-4.x, and it
is not entirely clear at this point what would be the "best" replacement
for them, but this issue here prevents GTK+-3.89.x building on Windows.
As a result, this is a fast port to avoid using APIs that have been
removed for 4.x, and things seem to work properly (the print.c page
printed).
https://bugzilla.gnome.org/show_bug.cgi?id=773299
When checking if a rectangle is contained by the rounded box, the code
will refuse a rectangle which is the exact size as the one backing the
rounded box, since it checks for greater or equal width and height.
Check for greater only instead.
https://bugzilla.gnome.org/show_bug.cgi?id=774114
- Make the rows larger
- Display the elapsed time between renderings
- Display if it was a full or a partial redraw
- Add a toggle button to display profiler info
Empty doc comments make gtk-doc complain about undocumented
functions, even though these functions are not supposed to
be documented in the first place.
Just to avoid having to do NULL checks when calling
widget_class->snapshot. We were crashing with drawing areas who don't
have a draw or a snapshot vfunc (woot!).
We need so subtract the allocation from the clip to get the clip offset,
not the other way around.
This was screwing in particular with marks on GtkScale, because GtkScale
mark clip computation is broken and always returns (0,0) which makes
scales have a waaaaay too large clip.
But that's another bug.
And use this to cull widgets and gadgets that are completely outside the
clip region.
A potential optimization is to apply this clip region to cairo contexts
created with gtk_snapshot_append_cairo_node(), but for that we'd need to
apply the inverse matrix to the clip region, and that causes rounding
errors.
Plus, I hope that cairo drawing becomes exceedingly rare so it won't be
used for the whole widget factory like today (which might also explain
why no culling happens in the widget factory outside the header bar.
The equivalent to cairo_matrix_multiply (a, b, c) is
graphene_matrix_multiply (c, b, a).
graphene_matrix_multiply (a, b, c) may not be called with b and c being
the same matrix.
Grips have long been unused in GTK, so remove all support for them.
This removes the GTK_STYLE_CLASS_GRIP and the special
gtk_render_handle() code for drawing those grips.
