If you called gtk_icon_theme_lookup(), then always return some useful
icon name from gtk_icon_paintable_get_icon_name(), even if we picked
an unthemed icon.
Also rewrite the gtk_icon_paintable_get_icon_name() docs to make this
clearer.
In GTK2, the filechooser was using a Paned, so switching between sidebar
and files list with the arrow keys didn't work (the slider would be
selected instead). So in
https://bugzilla.gnome.org/show_bug.cgi?id=161489 a crude hack was added
to make this possible.
Over the years the filechooser code has changed so that it now would do
this by default, yet the hack had been retained.
These are always set to the same value as the corresponding border
radius properties. They are also non-standard, so remove them and
replace them with the border radius properties everywhere.
Fixes#2414
When we are loading symbolic pngs or svgs, we know
that we need to the png or svg loader, so there is
no need to go through (surprisingly expensive) mime
sniffing to find the right loader.
It doesn't really make sense to treat double clicks here different than
single clicks (and is bad UX), and it also breaks switching months by
quickly trying to single-click the last/first days in the calendar.
This is an unused feature that's way too complicated for a default
calendar widget and complicates the implementation a lot. Since we want
to eventually replace this with actual widgets, remove the details
support now.
These will replace the previous gtk_snapshot_new_with_parent(), which
allocated an entirely new GObject just to push()/pop() some state. This
is already a problem but will be more important in the future as we
start using this more.
When reaching this point, it is impossible that all border styles are
HIDDEN or NONE, but up to 3 of them can still be that style. In any
case, the "none or solid" border style is the most common on there is,
so try to make this simpler here by just appending a border node
directly instead of going through the snapshot_border path.
Hide the expensive GTK_IS_ROOT() checks behind the cheaper realized,
mapped, etc. checks. This way we only check for the widget being a root
if the invariant does not hold.
This gets pop_verify_invariants() from 16% to 6% when running the
scrolling benchmark in the widget-factory.
When the css is validated we know the css size, so we can
create the paintable at that point, and we do so passing the
LOAD_IN_THREAD flag.
This causes us to load most icons early on, in parallel instead of
during the first snapshot.
Instead of having the IconTheme have a hashtable that owns
individual strings and then IconThemeDirSize have a similar
hash (but with the strings owned by the other hash), we
have a consecutive memory chunks where we store the icon names
and then the hashtable has pointers into this.
This means we can avoid a bunch of individual strdup()s in a
way that is less fragmented and wastes less space. Additionally,
since we do an initial lookup anyway we have the internalized
icon name during lookup which means we can use g_direct_hash/equal
instead of g_str_hash/equal making the lookup faster too.
If there is a passive grab and the pointer leaves the window we would
receive a GDK_CROSSING_NORMAL event when the pointer moves outside
the window, and a GDK_CROSSING_UNGRAB event when we do release the
button and the implicit grab.
We currently would react to the first, but want to react to the
second. In the time between both events, the client would still receive
pointer motion that will reach the implicitly grabbed widget.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/13
We've started to turns containers into widgets which
just happen to have children, and some of these need
to be exposed to the a11y stack.
This adds a very minimal implementation, it does not
currently emit change notification when children are
added or removed.
These now render the paintable to a cairo surface and convert that
to a texture. This is sort of a hack, but its only used in two
special cases internally and in two hacky test apps.
This changes gtk_text_buffer_insert_texture() to
gtk_text_buffer_insert_paintable() which is strictly more useful
(as textures are paintables). It also fixes the code to actually
support drawing the paintables (as well as tracking changes
to the paintables.
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.
It never makes sense to paint a texture that needs recoloring. If
you call the regular snapshot on a symbolic texture we just use the
default recoloring colors.
To support this we also change gtk_css_style_snapshot_icon_paintable()
to call gtk_icon_paintable_snapshot_with_colors() for IconPaintables
so that we get the correct colors, and we make it not emit the color
matrix.
Since we now rely on the icon to do the recoloring we also drop the
recolor argument in gtk_icon_paintable_snapshot_with_colors() as its
not needed anymore.
When we dismantle our children in dispose, we
trigger a11y children-changed signals which end
up calling back into the notebook. Handle this
without critical warnings.
Only update the action state when we have a text buffer,
there is no need to do it otherwise, since we are going
to get a buffer before we get shown. This avoids triggering
the action state updates from finalize, which is a bad
time to be recreating the action muxer.
The accessible gets properties of the entry, and
resetting the entry icons triggers accessible change
notification, so do that before we dismantle the entry
too far to respond to a g_object_get () call.
1. Rename the thing
2. Turn it from a signal to a vfunc
3. Pass the GtkCssStyleChange to it
We don't export any public API about the GtkCssStyleChange yet, it's
just a boring opaque struct.
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".
Those functions are unused and the documentation says "Returns some
random number that the icon theme creator chose" which does not seem at
all useful and an implementation detail.
So get rid of it.
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 ())
Fix up the index computation. We have duplicate entries
in the type enum, so to go from one of the 'initial' types
to it corresponding type you subtract one, but to find
the size array entry for a type, you divide by 2.
It turns out with the icon cache now using the virtual SYMBOLIC_PNG_SUFFIX
flag the two enums are now identical, so lets just use one of them, the
one GtkIconCache (so we move it to the header).
This is a useful widget to have, and it has minimal api.
Not having it public forces apps to recreate a lot of
complicated machinery for not good reason, if they need
an Emoji chooser in a different context.
Traditionally the icon lookup for a theme has been:
lookup (icon_name, size):
best_directory = NULL
forearch theme
foreach directory in theme
if dir_size_matches (directory, size) && dir_has_icon (directory, icon-name)
best_directory = chose_best_size_dir (best_directory, directory)
if best_directory
return icon from best_directory
However, it turns out that there are a lot of subdirectories which have the same
size, as they differ only in the (essentially useless) "context" value. For example
the "16x16/apps" subdirectory is essentially the same as the "16x16/actions" one.
So, instead rathern than keeping all the directories as separate we store the
all the directories with the same size as a single entity (DirSize) and the
icon lookup in that DirSize looks up not only which suffix to use for that icon
but also which subdir it is in.
Additionally we keep a hashtable with all icon names that are
available in the entire theme (i.e. all DirSizes), which allows use
both to store each icon name only once, but also to do a quick
negative lookup and early exit in case we're looking up an icon that
doesn't exist. This is pretty common because we often look up sets of
icons like "image-png-symbolic", "image-png", "image", expecting some
to fail.
This brings down the time of the initial css validation from 20msec to 15msec for
me when running icon-factory.
This lists the icons in a particular director, with their flags in a
hashtable. We also convert from "icon.symbolic" + SUFFIX_PNG to
"icon" + SUFFIX_SYMBOLIC_PNG.
We only have implementations of this on X11 and Win32,
so make it available as backend api there.
Update all callers to use either the backend api, or
just monitor 0.
Instead of requiring sassc to be installed add meson subprojects
which build libsass and sassc (currently both forks of mine, tested
under linux/mingw/msvc) when needed.
This allows us to drop the generated .css files and build scripts from git.
See #1502
In gtk_icon_theme_get_for_display() we were calling
gtk_icon_theme_set_display() which eventually (via the css machinery)
called back into gtk_icon_theme_get_for_display() which created a
second icon theme. We avoid this by setting the user-data earlier so
that the css machinery gets back the currently initializing theme
instead.
We look at whether a widget will be mapped (the actual state is not
yet set, so we can't rely on that at css validation time) and use
that to set the i/o priority of the async task.
This means that its likely that widgets that will be displayed soon
are loaded before those that are not yet going to be needed.
This limits the amount of preloading we to, which can for instance
avoid trashing if the icon cache is full, and in general do less work
when its likely to be wasted such as when e.g. background-color for an
icon helper changes.
At the end of GtkImage css validation (during style-updated) when the
css properties (like the icon size) are valid we call _gtk_icon_helper_preload
which does an async icon theme lookup and load. This will happen on a thread
in parallel with the rest of the css machinery, and hopefully by the
time we need the icon it will be ready. If not we will block when we need
it, but during that blocking all the other icons will be loaded.
Testing widget-factory this changes the time of snapshot() from 31 to
25 msec, but on the other hand we also load a few more icons that we
didn't before causing the css validation phase to be about 8 msec slower.
This is because we're preloading all the images in the window, not only
the ones that are visible.
Unfortunately we still load a bunch of icons in snapshot(), from
GtkCssImageIconTheme, and ideally we should try to preload those also.
This happens when we first get the theme for a display, or then the
icon theme setting changes.
This means we don't have to do this scan in the first snapshot
and can do the i/o it in parallel with other stuff. This moves
a 10msec block from the first snapshot cycle to early setup.
If some other thread is lock the icon or icon theme locks they are likely
to do so for a long time, doing i/o. So, switch to trylock() for the
nonblocking part of _async(). This way we can return directly if the
result is available, but do a thread otherwise, never blocking the
calling (main) thread.
Move the lru cache under the global cache lock to avoid some ABBA
style deadlocks when going from icon_theme->icon lock an icon->icon_theme.
We also move all the icon lock uses to a small part of code and make
sure that code never calls out or blocks with any locks held.
Rename the GtkIcon->cache_lock to texture_lock to avoid confusion withe
the global cache_lock.
Removed any mentions of threadsafety from the API docs, we don't
want apps to rely on this, but rather use it outselves internally.
This name can show up in error messages or profiler
traces, so it is nice to provide some hint what
file we are dealing with.
<GtkFileChoser template> is a lot more helpful
than <input>.
This was added in 0b1c9b7cc2 to protect
against reentrancy from the theme-changed signal, but we only emit this
from an idle these days, so thats not necessary anymore, and the recursion
check was causing issues with the async operations where a different
thread loading the theme caused the calling thread to thing the
theme is valid.
