Instead of associating the GdkWindow that created the GdkDrawingContext
we can directly bind the Cairo context to the GDK drawing context.
Cairo contexts created via gdk_cairo_create() go back to not having a
GdkWindow associated to them, like they did before we introduced the
gdk_window_begin_draw_frame() API.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
Instead of giving out Cairo contexts, GdkWindow should provide a
"drawing context", which can then create Cairo contexts on demand; this
allows us to future proof the API for when we're going to use a
different rendering pipeline, like OpenGL.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
Existing code drawing on a GDK window has to handle the direct drawing
and the buffered drawing by itself, by checking the window type and
whether or not the window is backed by a native windowing surface. After
that, the calling code has to create a Cairo context from the window and
keep an association between the context and the window itself.
This is completely unnecessary: GDK can determine whether or not it
should use a backing store to draw on a GdkWindow as well as create a
Cairo context, and keep track of it.
This allows to simplify the calling code, and enforce some of the
drawing behavior we want to guarantee to users.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
The maximum content size does not increase the minimum request
but only ensures that both minimum and natural requests do not
exceed the maximum setting.
Widgets should support size requests before being realized in general,
otherwise this can cause flicker/resize at initial display time as
the toplevel window can make a request before realize/allocate.
This also makes the added testsuite/gtk/scrolledwindow.c test work again,
this was broken because we only ever calculate whether we are going
to use overlay scrollbars once the scrolled window is realized (and
the test case does not realize any window).
This patch does a couple of things:
o Removes the obscure 'extra_width' and 'extra_height' variables
making the request code exceedingly difficult to read
o Fixes the max-content-size properties introduced in bug 742281
so that they do not grow the minimum request.
o Cleanup of request code in general:
- min/max content sizes are clamped around the child request as needed
- scrollbar requests are only added in one place, after child request
sizes are calculated and without the extra_width/height thing.
Commit 023f406c96 has a typo that results
in this error:
../../../testsuite/gtk/notify.c: In function 'test_type':
../../../testsuite/gtk/notify.c:679:54: error: expected expression
before ')' token
(g_str_equal (pspec->name, "max-content-width") ||)
^
A wl_buffer has a max size of 4096 bytes, of which 8 are needed for the
header and another 4 for the string argument length (in this case), so
make sure the we only save the first 4083 bytes that are still valid
UTF8.
https://bugzilla.gnome.org/show_bug.cgi?id=767241
The allowed values for the max-content- properties depend
on the value of the min-content- properties, in a way that
our simple test is not prepared to deal with. Just skip
them for now.
xdg-shell allows desktop environments to extend the list of states
within a given range.
Use this possibility to add a new state for tiled so that gtk+ can
benefit from this.
https://bugzilla.gnome.org/show_bug.cgi?id=766860
If gtk_scrolled_window_add() has added a GtkViewport,
gtk_container_remove (GTK_CONTAINER (scrolled_window), child_widget);
or
gtk_container_remove(GTK_CONTAINER(scrolled_window),
gtk_bin_get_child(GTK_BIN(scrolled_window)));
removes both the added child widget and the viewport.
https://bugzilla.gnome.org/show_bug.cgi?id=710471
This removes leftover code from when classes where added to the style
context.
Now that they get added directly to css nodes, the classes can exist
without a style context.
https://bugzilla.gnome.org/show_bug.cgi?id=767312
With the FTS5 query syntax, when using quotes to delimit the search phrase
the '*' token must happen after the quote, or will otherwise be considered
a character to match, go through the tokenizer, and end up ignored in
result.
This reverts commit 0943c9f6b2.
The commit caused unexpected breakage in gtk3-widget-factory,
and also broke the just-added max-content-size properties.
Needed to adjust this again after applying commit 4e5ecb7
for bug 742281. Now that we also have max content size properties,
pushed the addition of possible scrollbar sizes to after the
clause which clamps the child request size into min/max content
sizes.
Commit a01fe14 changed the behaviour of popovers when the focus leaves
them to stop child popovers being hidden when the focus leaves their
parent. However they are now a bit too reluctant to hide - if the
focus passes to an unrelated popover the first popover is not
hidden. Also if the focus passes to another widget that does not
perform a gtk grab then the popover isn't hidden until the user
presses a non-movement key or clicks outside the popover.
The solution is to go back to checking if the focused widget is a
descendant of the popover, but to include popovers and their related
widgets in the ancestry chain.
https://bugzilla.gnome.org/show_bug.cgi?id=765595
This patch causes the scrolled window default behavior to change in
such a way that the natural size request of the child is unconditionally
reported, which probably should have been the case since day 1.
This should not cause significant fallout since a scrolled window is
normally used to expand/fill, eating up remaining space for scrollable
content - it will however cause the scrolled window to compete for
additional space with siblings, proportionally to the size of the
scrolled window's content.
gtk_tree_view_get_path_at_pos() mistakenly identifies the first
pixel of all but the first column in a tree view as belonging to
the previous column.
https://bugzilla.gnome.org/show_bug.cgi?id=708148
The GtkScrolledWindow has support to set the minimum content size (both
width and height) which controls the minimum space allocated, but does
not exposes any way to control the maximum size the content can grow.
After the introduction of GtkPopover, which always uses the minimum
size of it's children widgets, the lack of max-content-width and -height
properties became a concrete use case.
This patch introduces the GtkScrolledWindow::max-content-width and
-height properties. The properties will alter the minimum size of
the scrolled window, making it grow up to the set value. They also
respect the previously set ::min-content-width and -height.
https://bugzilla.gnome.org/show_bug.cgi?id=742281
Similar in spirit to
gtk_style_context_get (ctx, state, "font", ...)
but avoids the need for a style context.
This will be used to for css-styled text rendering
from css subnodes.
This is _gtk_style_context_get_pango_attributes, decoupled
from the GtkStyleContext. This will be used to drive css-styled
text rendering from css subnodes of widgets, e.g. for the value
in GtkScale.
The Wayland protocol does not share XI2's wealth of information
about individual devices, but it does provide discriminating
information about the source for scroll events. Pass this on to
the application by creating separate slave devices for these,
and setting them as source device on the scroll events.
These devices can be discriminated by their input-source property:
wheel - GDK_SOURCE_MOUSE
finger - GDK_SOURCE_TOUCHPAD
continuous - GDK_SOURCE_TRACKPOINT
https://bugzilla.gnome.org/show_bug.cgi?id=767093
fix up
