If icon lookup fails or if loading it fails later, just always
fall back to the built in image-missing icon. Nobody is handling
missing icons in a sane way anyway.
If you *truly* need to handle missing icons, you need to manually
use gtk_icon_theme_has_icon().
While changing the loading code I also fixed an issue where it
was always passing "png" to pixbuf, now it also handles "xpm" if
that is the filename suffix.
We had a pretty complex setup where we tried to avoid scaling up themes from dirs
that specified a size. However, not only was it very complex, but it didn't quite
work with window scales, because when using e.g. a size 32 directory for 16@2x
the dir size is wrong anyway. Additionally it turns out most code either picks
an existing icon size, or uses the FORCE_SIZE flags, so it doesn't seem
like a useful behaviour.
This change drops the FORCE_SIZE flags, and always scales
icons. Additionally it moves the scaling of the icon to rendering,
which seems more modern, and allows us to (later) share icons loaded
for different sizes that happened to use the same source file (at
different scales).
Note that this changes the behaviour of
gtk_icon_paintable_download_texture() is it now returns the unscaled
source icon. However, ignore thats, as I plan to remove this function
and replace it with a way to render a paintable to a cairo-surface
instead.
Stylecontexts are on their way out and I'm removing API that the
testsuite was relying on, so remove the tests.
Put the useful parts of the tests elsewhere.
Instead, rely on people passing fallbacks explicitly.
Alternatively, GThemedIcon provides the functionality to create
fallbacks, which is what GtkImage and the testsuite now use.
That method is slightly better, too, so the expected test results
have been updated accordingly.
There is no way to query contexts or do anything useful with them.
So don't keep track of them and don't make them an argument in public
APIs with the docs saying "I don't know what to use here, maybe read
some spec somewhere".
We expose no API to get at any colors for drawing symbolics, so we
shouldn't have APIs to draw with them.
Apart from that, those APIs look like a box of crayons, not like an
icontheme.
Most users were just forgetting to set the proper flags.
And flags aren't the right way to set this anyway, it was just
acceptable as a workaround during GTK3 to not break API.
The API encouraged wrong usage - most of the users were indeed wrong.
Use the correct version instead:
gtk_icon_theme_get_for_display (gtk_widget_get_display ())
These days initilizing gtk may create a connection to the sesson bus,
so we have to initialize GTestDBus before initalizing gtk, or we'll
use the address of the "real" session bus (and remember that in the
global).
To further muck things up, g_test_dbus_up() resets important env
vars like DISPLAY and XDG_RUNTIME_DIR, which we have to re-set.
This adds a GDK_DEBUG=default-settings flag which disables reads
from xsettings and Xft resources, and enables this for the testsuite.
This is one less way to get different testresults depending on the
environment. In particular, it was failing the css tests for me
due to getting the wrong font size because i have a different dpi.
When looking for the get_type function for GThemedIcon,
try both g_themed_icon_get_type and gthemed_icon_get_type
The former is what gio has, the latter is still supported
to avoid breaking gweather_location_get_type.
Update tests to cover this new case.
GtkBuilderScope is an interface that provides the scope that a builder
instance operates in.
It creates closures and resolves types. Language bindings are meant to
use this interface to customize the behavior of builder files, in
particular when instantiating templates.
A default implementation for C is provided via GtkBuilderCScope (to keep
with the awkward naming that glib uses for closures). It is derivable on
purpose so that languages or extensions that extend C can use it.
The reftest code in fact does derive GtkBuilderCScope for its own scope
implementation that implements looking up symbols in modules.
gtk-widget-factory was updated to use the new GtkBuilderCScope to add
its custom callback symbols.
So it does it different from gtk-demo, which uses the normal way of
exporting symbols for dlsym() and thereby makes the 2 demos test the 2
ways GtkBuilder uses for looking up symbols.
All the list model tests were leaking items,
because g_list_model_get_item is transfer full.
Fixing these unveils a crash in the treelistmodel
and maplistmodel tests.
We use a compilation symbol in our build to allow the inclusion of
specific headers while building GTK, to avoid the need to include only
the global header.
Each namespace has its own compilation symbol because we used to have
different libraries, and strict symbol visibility between libraries;
now that we have a single library, and we can use private symbols across
namespaces while building GTK, we should have a single compilation
symbol, and simplify the build rules.
gtk_builder_connect_signals() is no longer necessary, because all the
setup that made it necessary to have this extra step is now done
automatically via the closure functions.
This is pretty unused and gets in the way of the next steps.
A potential side effect is that for templates the widget was passed as
the user data argument. If that turns out to be important, we have to
special case that situation.
This adds support using the GtkTextHistory helper for undo/redo to the
GtkText widget. It is similar in use to GtkTextView, but with a simplified
interface.
You can disable undo support using the GtkText:enable-undo property. By
default, it is enabled.
The code previously forgot to include the left child of the model's
node. Which of course only happened if that child wasn't NULL, which is
a common case.
Found and test provided by Matthias Clasen.
Instead of playing games with mapping negative symbolic values to
positive ones, let's use the appropriate constants everywhere. This
allows us to use:
GTK_CONSTRAINT_STRENGTH_WEAK * 2
Or
GTK_CONSTRAINT_STRENGTH_STRONG + 1
In code using the public API.
We also store the strength values as integers, so we can compare them
properly, and only turn them into doubles when they are inserted into
the solver, just like every other variable.
Make the 'repeat edit' test make more than to
suggestions in a single edit phase. It turns out
that this does not work, whereas just doing
two in a row does.
GtkConstraintSolver is an implementation of the Cassowary constraint
solving algorithm:
http://constraints.cs.washington.edu/cassowary/
The Cassowary method allows to incrementally solve a tableau of linear
equations, in the form of:
x = y × coefficient + constant
with different weights, or strengths, applied to each one.
These equations can be used to describe constraints applied to a layout
of UI elements, which allows layout managers using the Cassowary method
to quickly, and efficiently, lay out widgets in complex relations
between themselves and their parent container.
Differentiate between wrapping around and
stopping at the end of the focus chain.
Update the existing tests, and add two
new ones where the difference matters.
Add a test that enumerates the focus chain by
emitting move-focus repeatedly, and compares
the result to expected output.
The test expects a ui file and a reference
file as input. The reference file can be created
using the --generate option.
We want to use a gdk_surface_new_popup for popups,
and align the constructor names with the surface
types, so rename
gdk_surface_new_popup -> gdk_surface_new_temp
gdk_surface_new_popup_full -> gdk_surface_new_popup
The temp surface type will disappear eventually.
The calls used old bugzilla URLs and nobody cared about that.
So apparently they are very unused.
There's also a potential conflict between gitlab and bugzilla URLs and
what base bug to use there.
The old usages have been converted to comments.
The need of a specialised fixed layout container that can be placed into
a GtkScrolledWindow ceased to exist once GtkScrolledWindow gained the
ability to automatically interpose a GtkViewport when adding a child
that does not implement GtkScrollable.
All the other justifications that led to the existence of GtkLayout as a
separate widget from GtkFixed have been largely made irrelevant in the
20 years since its inception.
GtkLayoutChild instances are created on demand once we have a widget, a
GtkLayoutManager, and a child widget. This makes testing their creation
fairly tricky.
Let's skip them, for the time being.
Check that we get the expected sequences of focus
change events for the nonlinear, inferior and ancestor
cases.
It would be nice to do the same checks for crossing
events, but we have no gtk_window_set_hover().
Make the API expect a tranform of the proper category instead of
doing the check ourselves and returning TRUE/FALSE.
The benefit is that the mai use case is switch (transform->category)
statements and in those we know the category and don't need to check
TRUE/FALSE.
Using the wrong matrix will now cause a g_warning().
In particular, check that to_matrix() and to_2d(), to_affine() and
to_translate() return the same values.
This also requires a recent Graphene version or the tests will fail.
