And constrain it in StScrollView instead (instead of falling back to an
infinite paint volume, as the actor as paint/pick impls, but no
corresponding get_paint_volume one).
Fixes artifacts with the AppView (and possibly other places) when paint
volumes are aggressively cached.
The default keyed_surface is meant to handle CoglTextures thus we can't
add cairo surfaces to it, as the DestroyNotify function won't handle them.
Then the quicker way is to just add another Hash table for handling
such types of textures, with proper destroy function.
This might cause a crash when cleaning up the cache as the hash table has
cogl_object_unref as DestroyNotify function but that assumes that
the passed object is a valid CoglObject.
Fixes: #210
The instance is owned by the actor (being its child), and thus when the
disposal happens for the parent the text is disposed too, thus it's just
safer to nullify its reference so that we won't try to access to invalid
objects later, and this might be the case since the JS objects could be kept
around until they aren't finalized.
https://bugzilla.gnome.org/show_bug.cgi?id=788931
Call _st_set_text_from_style() when updating the entry's style, so
that CSS style properties such as text-decoration or letter-spacing
are applied over the internal ClutterText instance.
If an actor is pending a relayout when get_allocation_box() is called,
the method forces an allocation update. In case of StWidget, this might
then result in a style update and a consecutive invalidation of the
shadow spec.
A helper method that invalidates one of its parameters as a side effect
(and by extension its return value as well) is most unexpected, so cur-
rently _st_create_shadow_pipeline_from_actor() poses an easy trap to
callers to run into.
Remove that trap by calling get_size()/get_position() instead, which
don't have the unintended side effect - it is still a good idea to fix
callers who were running into this to not waste resources on creating
shadows that are invalidated before the next paint, but throwing un-
defined behavior at them is harsh ...
https://bugzilla.gnome.org/show_bug.cgi?id=788908
The st_button_release() call wouldn't happen because StButton does not
set priv->button_mask on touch events. And if we make it called, we can't
try to unset the device grab at the end of the function, as device/sequence
are unset earlier on.
When creating a shadow for a ClutterTexture, we currently use the
underlying CoglTexture directly instead of rendering the actor to
an offscreen buffer. This assumes that the CoglTexture is directly
suitable as shadow source, which isn't necessarily the case - it
may have a very different size than what is shown and scaled up or
down by the hardware. In that case we end up with a scaled shadow
texture as well, which messes up the desired blur effect - the
result will be too light when scaling up, or too sharp when scaling
down. To fix this, only take the shortcut when a ClutterTexture's
underlying texture has the correct size and fall back to offscreen
rendering otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=788039
Unlike pango_font_description_from_string(),
pango_font_description_set_family() requires a already properly
formatted font family string. The proper format is a comma seperated
list of font families, but we generated a "comma space" separated list.
Passing a incorrectly formatted font family string to pango seems to
cause wierd issues, where the wrong font is sometimes selected.
For example, this fixes a font selection issue on zh_TW.UTF-8 locale for
chinese characters, where previously the "Droid Sans" font was selected
instead of "Source Han Sans TW" even though fontconfig had placed
"Source Han Sans TW" before "Droid Sans".
https://bugzilla.gnome.org/show_bug.cgi?id=786868
Compiling the generated source for each consumer of the dependency
means we end up trying to register the enum types multiple times,
resulting in a fatal failure on startup. Luckily code outside libst
itself only depends on the header, which doesn't cause those issues.
st_built_sources contains the source and header generated by mkenums,
not any other generated sources. Clarify that in the name, as we are
about to use source and header separately.
We cannot rely on any build order, except the one we specify ourselves.
St depends on various generated files; other targets depend on those
files existing, so they can be included. There is no direct relationship
between targets and files, unless we declare a dependency, using the
Meson declare_dependency() constructor — which allows us to replace the
various `link_with` directives with the more appropriate `dependencies`
one, and also allows us to specify sources that must exist by the time
we build those targets.
In parallel builds we may end up with st-enum-types.c being built inside
separate targets outside of src/st which may not have the ST_COMPILATION
pre-processor symbol defined. For this reason, we need to define it
ourselves in the source file, before including other headers, to avoid
the single-include guard.
Meson is on track to replace autotools as the build system of choice,
so support it in addition to autotools. If all goes well, we'll
eventually be able to drop the latter ...
https://bugzilla.gnome.org/show_bug.cgi?id=783229
Even though the API documentation doesn't say so, the underlying
Cogl texture of a ClutterTexture may be unset, so check for that
case to avoid a runtime warning.
https://bugzilla.gnome.org/show_bug.cgi?id=784353
This allows a full ClutterActor to be used as hint in the entry, instead
of a simple string.
The string case has been now re-implemented on top of the hint actor.
https://bugzilla.gnome.org/show_bug.cgi?id=783484
This is the same as the previous commit, but for StEntry.
We don't have any need to explicitly destroy this actor in our dispose
implementation, and doing so breaks the assumption that we can access
the clutter_text from within destroy.
https://bugzilla.gnome.org/show_bug.cgi?id=783483
There's no need to explicitly destroy the ClutterText actor inside the
label; doing so is actually harmful, as it will break the normal
reference cycle between container and children.
As StLabel doesn't hold any extra reference to the ClutterText actor and
just uses clutter_actor_add_actor() to add it to itself, let the normal
container dispose cycle run to dispose of the reference.
https://bugzilla.gnome.org/show_bug.cgi?id=783483
Commit ffe4eaf00d broke the handler by fetching the instance private
from the wrong actor - as we don't use the ::primary-icon-clicked signal,
and the ::secondary-icon-clicked signal still works by accident, nobody
noticed until now ...
https://bugzilla.gnome.org/show_bug.cgi?id=782190
When extracting the sliced image, the GTask grants data ownership on
g_task_propagate_*, so the pixbuf list must be properly freed. On async
load, we just left a dangling reference when returning on the async
task.
https://bugzilla.gnome.org/show_bug.cgi?id=642652
st_theme_node_get_border_image() may return %NULL, leading to a
segfault in st_border_image_get_file() when glib is compiled with
G_DISABLE_CHECKS.
https://bugzilla.gnome.org/show_bug.cgi?id=780381
It isn't useful to move the keyboard focus to a hidden actor, so
only include visible actors in the focus chain - this is in fact
the documented behavior of st_widget_get_focus_chain(), so having
the default implementation return all children has always been
unexpected.
https://bugzilla.gnome.org/show_bug.cgi?id=778158
Sliced images are loaded into a group actor with one child actor
per slice. In case loading the image fails, we currently quietly
return the empty group actor, which makes diagnosing problems
unnecessarily hard - just be a bit more verbose on failure.
https://bugzilla.gnome.org/show_bug.cgi?id=774805
Other windows like the mutter Xwayland selection bridges might deal with
the clipboard, which would result in events visible on st-clipboard event
filters.
In order to avoid unintended results, ignore events that are not meant for
the clipboard window.
https://bugzilla.gnome.org/show_bug.cgi?id=760745
We're using an unitialized box resulting in an undefined shadow box
size.
_st_paint_shadow_with_opacity() already computes the shadow's bounding
box from the source actor's box so we just need to pass that along.
https://bugzilla.gnome.org/show_bug.cgi?id=767954
