(optional) is only valid for (out) or (inout) parameters (that are
marked as such).
However GError** arguments appear as throws="1" in the GIR anyway
instead of an explicit parameter, so we don't need any annotation
at all here.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1408
Much of St is undocumented, aside from input/output arguments. This is
no doubt because a lot of it parallels Gtk closely, but is worth
improving since many new programmers are not familiar with Gtk.
closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2983
The framebuffer we use for rendering shadows is scaled by the resource
scale, that means we also need to offset coordinates when translating
them to the framebuffers coordinate system.
So far we forgot to do that when translating the framebuffer using the
position of the actor, which lead to small rendering bugs of
text-shadows for actors allocated at non-zero origins. To fix that,
simply multiply those positions with the actors resource scale.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1390
We still load the surface into an StImageContent, but instead of
adding the content to an actor we hand out, return the content
itself (as GIcon).
That means we lose the ability to specify an icon size, but as we
get the pixel data from a fixed-size surface anyway, that shouldn't
matter much in practice.
Not to mention that the function is only used for fallback X11 icons,
which are already shit more often than not.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1342
On the one hand, this is a bit of a stretch: StImageContent is what
we create from GIcons.
But on the other hand, there's some justification: StImageContent does
represent an image (and likely icon) after all, and there's some
precedent with GdkPixbuf.
In the end as we don't care about serialization or loading from other
API, we can go with a very crude implementation that allows us to
pass out a content as GIcon and use it directly when "loading" it.
We will use that soon to represent X11 window icons as GIcons, which
in turn will allow us to unify app icon handling.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1342
ClutterActor provides the same function, but with a different return
value. So since we already switched to the ClutterActor implementation
in our C code, we can now safely remove st_widget_get_resource_scale()
and update the JS code that's still using the old API.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1287
Instead of using the "notify::resource-scale" signal and StWidgets
"resource-scale-changed" signal, use the new "resource-scale-changed"
signal of ClutterActor, which replaces its "resource-scale" property.
Since we'd now have two "resource-scale-changed" signals, one on
ClutterActor and one on StWidget, remove the StWidget one in favour of
the new one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1287
When scrolled, the container's allocation is smaller than the allocation
of the content. To account for that, commit 2717ca9d08 added the
additional size reported by the layout manager to the content allocation.
However as it did so unconditionally, we now allow children to extend
outside the parent even when *not* scrolled, which breaks any constraints
set on the container (like "width" or "max-height").
Fix this by only extending the child allocation in scrollable dimensions.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2491
The performance of the icon grid was being hindered by a large number
of primitives (a few hundred) being copied from the CPU to the GPU on
each frame. This was first noticed in mutter#971 but we failed to
investigate all the issues at the time.
You can also see the high number using `COGL_DEBUG=batching` or
`COGL_DEBUG=disable-texturing`. So now it's obvious that high number is
every letter of every label being uploaded as a separate quad. Let's not
do that and instead treat the whole label as a single quad/texture.
Measured performance on an i7-7700 at UHD 3840x2160:
Journal entries per frame on the icon grid:
* Before: 288 (18 KB copied from CPU to GPU)
* After: 73 ( 4 KB copied from CPU to GPU)
Spring animation:
* Before: 20-30 FPS, avg 22/peak 45 milliseconds per frame
* After: 30-40 FPS, avg 14/peak 28 milliseconds per frame
Scrolling the icon grid:
* Before: 15 FPS, 50 milliseconds per frame
* After: 30 FPS, 28 milliseconds per frame
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1329
As the view now scrolls from right-to-left in RTL locales, the
scroll bar handle should reflect that.
Likewise the event handling needs adjusting as well: Scrolling
left should increase the adjustment value, and clicking the
trough to the left of the handle as well.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1318
clutter_text_get_selection() creates a copy of the selected text which
gets passed to st_clipboard_set_text() which creates its own copy. The
copy returned by clutter_text_get_selection() however never got free'd.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1306
As outlined in commit 36b8dcbe07, we can end up with wrong icons
if the icon theme changes right after a GTK theme change to/from
HighContrast triggered a theme reload.
That's because when we reload icons for the new icon theme, there
are already pending requests due to the icon-style change; those
requests are simply re-used for the new icons, with the existing
icon infos from the old theme.
The above commit applied a simple work-around by changing the
icon theme before the GTK theme, but that only works for the
HighContrast switch in our own UI.
It turns out that Settings also uses the "wrong" order, so the
issue still reproduces with the Universal Access panel.
So instead of relying on everything changing the settings in the
order we expect, cancel all ongoing requests on icon-theme changes.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1277
Since the `MetaSelection` of the global `StClipboard` is private (and
should be), there is no reasonable way for extensions or external code
to query the supported mime-types.
Add `st_clipboard_get_mimetypes()` so this can be queried without
poking around in private code.
closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2819
Since e06109c23c we keep old theme nodes
valid during the emission of the "custom-stylesheets-changed" signal.
It turns out that we might still look up the file of a stylesheet using
the files_by_stylesheet hashtable during the emission of that signal,
causing a crash because the assertion in _st_theme_resolve_url() fails.
So fix that and remove the stylesheet entry from the files_by_stylesheet
hashtable after emitting the "custom-stylesheets-changed" signal. And to
be consistent, also remove the entry from the stylesheets_by_file
hashtable after emitting the signal.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2757
`StBoxLayout` has a couple properties (`vertical` and `pack-start`)
improperly referenced as signals, and is somewhat unclear these
properties are wrappers around the underlying `ClutterBoxLayout`
properties.
Fix these up and add references to the underlying properties, rather
than redescribing them.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2816
Since we now remove all theme nodes on a stylesheet change (ie.
StTheme's "custom-stylesheets-changed" signal) instead of only
invalidating them, those nodes may not be accessed anymore as soon as
"custom-stylesheets-changed" is emitted.
It turned out though that when comparing them to the newly generated
nodes in `st_widget_recompute_style()` using the
`st_theme_node_paint/geometry_equal()` functions, the properties of the
old nodes will still be accessed, causing a crash since the
CRDeclarations are already freed.
To fix that, keep the reference to the CRStylesheet, which owns the
CRDeclarations used by the theme nodes, around a bit longer, so it's
still possible to access the CRDeclarations inside the
"custom-stylesheets-changed" signal handler. This allows us to compare
the old theme nodes to the new ones since the CSS properties of both are
still valid.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2709
StThemeNodes are built around the assumption that they're "immutable",
that means they are created once with certain parameters (that resolve
to certain css properties) and then replaced with new ones in case those
parameters changed.
Changes to the internal information stored by theme nodes (i.e. the css
properties, font names or the cached scale-factor) are not all handled
the same though: For changes to the font or the scale-factor we remove
all theme nodes from the cache and let the widgets which are on stage
generate new theme nodes. For changes to the css properties/the
stylesheet, we invalidate the properties of all theme nodes but keep
them in the cache using `_st_theme_node_reset_for_stylesheet_change()`.
So be a bit more consistent and handle changes to the css-properties/the
stylesheet stored by StThemeNodes the same way as changes to the font or
scale-factor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1218
Theme node invalidation stops at unmapped widgets, and widgets
that forget to chain up to the default ::style-changed implementation.
This may leave stale nodes that were invalidated on
StThemeContext::changed, but are still set on widgets, and maybe
used for CSS property lookups.
Make sure that theme node invalidation happens always by moving
propagation outside the vfunc, and ensure the theme nodes are reset
across the full actor tree. Emission of ::style-changed, and obtaining
a new theme node may be delayed till when the actor is mapped.
The theme node is also cleared after unparenting an actor to avoid
stale references.
This ensures that all widgets get their theme node cleared after
stylesheet changes, instead of maybe being left with a theme node
that's been cleared of all its properties.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2541https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1223
I noticed the following warning while building the .deb package for
gnome-shell on Endless OS:
../src/st/test-theme.c: In function ‘main’:
../src/st/test-theme.c:549:3: warning: ignoring return value of ‘chdir’, declared with attribute warn_unused_result [-Wunused-result]
chdir (cwd);
^~~~~~~~~~~
(Of course this is very unlikely to fail in practice.)
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1208
We currently always ignore the minimum width of the hint actor and
request/allocate the preferred width. This can be problematic with
labels with long text, where we should rather ellipsize the text
than allow the entry to grow indefinively.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2607
Each node stores the scale factor in place when it was created.
Creating nodes with the same style, but with different scale
factors, yields different nodes.
Use the node's scale factor instead of retrieving the context's
one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1176
Since commit 6a42d77261 we invalidate the
cached properties for each theme node on stylesheet changes by iterating
over the hashtable of the theme context instead of listening to the
signal in each individual theme node.
That commit forgot one particular node though that's not stored in the
hashtable, but using the `priv->root_node` property instead: The theme
node that belongs to the stage.
So make sure we also invalidate the cached properties of the stage theme
node on stylesheet changes. This fixes various crashes that happened
with extensions providing custom stylesheets (emitting the
"custom-stylesheets-changed" signal on every extension enable/disable),
trying to access an already freed CSS property of the stage.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2584
Commit 7ff7fb5d3b forgot to clear the
`priv->icon_texture` actor when returning from st_icon_update(), which
means we don't always switch to an empty icon if both gicon properties
are set to NULL.
Fix this and destroy the actor before returning early from
st_icon_update().
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1178
Commit c89d6a633 introduced a default fallback icon that would be displayed in
case the main gicon or the fallback gicon wasn't set or failed to load.
This broke the use case where a StIcon is created but no main icon or
fallback icon are set on purpose, for example the appindicator extension
which always creates a StIcon to represent icons in menu items but the
actual icons are only set if the application provides one, leaving the
menu showing the default fallback ("image-missing") icon for all menu
entries that don't actually have an icon provided by the application.
Fix that by only using the default fallback icon if the provided one
failed to load.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1173
It seems reasonable that an entry shouldn't allow entering text when not
reactive. The same could be achieved by changing the text's :editable
property, however that will disable scrolling if the text doesn't fit,
which may result in an unwanted size change.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
The text is part of the entry, so it is surprising that it can
still be edited when the entry itself isn't reactive. Address
this by setting up a binding instead of expecting all consumers
to handle the case themselves.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
This is documented as a value between 1 and 65536. However we were passing
a 0 value for 100% transparent colors, which is interpreted as "system
inherited" in pango_renderer_get_alpha() docs.
Ensure we respect this range by specifying the minimum allowed alpha (1)
if the color is fully transparent. If someone notices this 1/65535th change
I'll ask him how many pleiades can he count.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2504
(yes, again).
