We currently don't have any code either in gnome-shell or
gnome-shell-extensions setting margins directly with the Clutter API.
On the other hand, the current behavior doesn't allow us to remove a
style class with margins and have that be reflected, so removing this
special casing seems like the right thing to do at this point.
https://bugzilla.gnome.org/show_bug.cgi?id=746902
If users click outside the search entry while it's empty we reset and
thus give up key focus. This means that when using an input method
with candidate popups, interacting with the popup with a mouse click
cancels the current input method context if there's no other text in
the entry besides the preedit string.
To avoid this we can check if the entry has preedit in addition to
checking if it has normal text.
https://bugzilla.gnome.org/show_bug.cgi?id=745167
Commit 1c1f63a7d7 changed the shadow
pipeline to use cogl_framebuffer_ortographic() instead of cogl_ortho(),
but the two functions take their arguments in a different order.
Fixes graphical corruption for text shadows in the login screen.
https://bugzilla.gnome.org/show_bug.cgi?id=745061
This is wasteful, since GResource does not support file monitoring.
Further, doing so will trigger a fallback code path in GLib that polls
every second in a thread, which is doubly wasteful.
https://bugzilla.gnome.org/show_bug.cgi?id=744013
GTK+ added support for a -gtk-icon-style property in themes to
enforce a particular icon style. Do the same for shell themes
with an -st-icon-style property, with the same set of possible
values as the GTK+ variant:
'requested' - use symbolic or fullcolor icon depending on the
icon name (default)
'regular' - enforce fullcolor icons
'symbolic' - enforce symbolic icons
https://bugzilla.gnome.org/show_bug.cgi?id=740447
The split between st_texture_cache_load_gicon() and load_gicon_with_colors()
no longer makes any sense, so just move the code into the public method.
https://bugzilla.gnome.org/show_bug.cgi?id=740447
It's implemented similar to the padding property, but instead of taking
into account the margin values at drawing time in node-drawing, we set
the clutter actor margins in StWidget when the style is computed.
In the case that a CSS margin is not specified, we don't to set a value
of 0 to the clutter actor margin. In this manner it allows to use
Clutter margin values set in the code. However, the margins that are set
both in the code and in the CSS on the same side, the result is
unpredictable.
We avoid to set the clutter actor margin values to 0 if there's no CSS
margin values defined, so we still allow clutter actors to use margin
set in the code.
https://bugzilla.gnome.org/show_bug.cgi?id=728437
GTK+ added a new PolicyType which currently triggers compiler warnings
about unhandled values in switch statements. We also have a use case for
it already, so add support for the new policy type.
https://bugzilla.gnome.org/show_bug.cgi?id=739379
The pointer to ->accessible was cleared too early in dispose, which
resulted in another accessible object being created when the actor
was removed from its parent in clutter_actor_dispose(). Use a
weak reference instead to clear the ->accessible pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=738147
These keybindings are well-established on the CLI (e.g. "kill-line"
and "unix-line-discard" in readline(3)), and adding support for them
is cheap ...
https://bugzilla.gnome.org/show_bug.cgi?id=737346
The switch to GNOME_COMPILE_WARNINGS() caused -Wall and other
warnings to not actually be used since GNOME_COMPILE_WARNINGS()
just sets WARN_CFLAGS. Add WARN_CFLAGS to AM_CFLAGS so that
it takes effect.
Add -Wno-error=deprecated-declarations so that when -Werror is
enabled, we don't fail on all the deprecated cogl and clutter
symbols.
https://bugzilla.gnome.org/show_bug.cgi?id=730408
The hover state of a widget can become persistent if
the widget becomes reactive while a pointer grab.
To avoid that, remove hover state if the reactive property
is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=728343
We need to use a GdkPixbufLoader instead of the straightforward
gdk_pixbuf_new_from_file(), since we want to load the image already
scaled if possible - e.g. if it's an SVG file.
https://bugzilla.gnome.org/show_bug.cgi?id=726907
It's possible that FBO creation fails due to hw limits or the
driver not exposing the EXT_framebuffer_object extension.
In that case, just give up on creating square icons.
https://bugzilla.gnome.org/show_bug.cgi?id=724977
clutter_device_manager_get_core_device calls XIGetClientPointer, which
requires a round-trip to the server. Since we do this on StWidget
creation, this means a full round-trip for every created StWidget.
Replace this with get_device with the ID of the VCP/VCK, since mutter
doesn't support MPX, and we know this is what the device is.
Sorting actors by the distance in the axis of movement first and against
the axis otherwise means that if we have a situation like:
A F
B
where "F" is the focused actor, and it slightly overlaps with B vertically,
then we'll choose "B" to go left, rather than "A", which is most likely
what the user intended.
This is especially apparent in the overview where slight window size
differences mean we might not get an exact grid shape.
https://bugzilla.gnome.org/show_bug.cgi?id=644306
Commit 4095a58eb9 introduced a
regression, since we have to take into account four cases,
top, bottom, right, and left, and that can't be merged into
two like that commit did.
So fix it to make fade effect works again.
https://bugzilla.gnome.org/show_bug.cgi?id=708256
The vvalue and hvalue uniforms are only used to decide whether we
should do fade the edges or not based on the fade_edges uniform.
The result does not change accross fragments so there is no reason
to recompute it for every fragment (pixel) so just split the edge
fade into two uniforms and compute the "should we fade the edges"
boolean once for every direction (when setting the uniforms) instead
of for every single fragment twice.
This reduces the number of uniforms as well as the the number of instructions
which are limited on older hardware. It should also be more efficent.
https://bugzilla.gnome.org/show_bug.cgi?id=708007
We need to call into MetaScreen to set the cursor, but we can't
do that from libst, so add a hook that libgnome-shell can fill,
and remove more ClutterX11 usage.
https://bugzilla.gnome.org/show_bug.cgi?id=707467
It is expected that the primary and secondary icons in entries
change places in RTL locales. When doing so, the edit-clear
icon must be replaced by an rtl variant too.
http://bugzilla.gnome.org/show_bug.cgi?id=705779
Using the same idea that shell-generic-container. It implements
AtkValue with a dummy implementation based on signals. Javascript
code would connect to that and returns the proper value.
https://bugzilla.gnome.org/show_bug.cgi?id=648623
In the common case, the accessible object is created by the
own widget. In some cases it is needed to specify a custom
accessible, as some of the logic will be implemented on the
javascript code (extend functionality using Components vs Hierarchy).
https://bugzilla.gnome.org/show_bug.cgi?id=648623
With StBoxLayout using the Clutter layout manager, it will now respect
actors' expand/align properties. However for the change to be transparent,
we need to support the existing child meta properties as well. Do
this by simply translating them to the corresponding ClutterBoxChild
properties.
https://bugzilla.gnome.org/show_bug.cgi?id=703810
With the BoxLayout containers in St and Mx and the ClutterBoxLayout
manager, we now have three more or less diverged implementations of
the same layout policy.
While removing StBoxLayout entirely in favor of ClutterLayoutManager
would be the fashionable thing to do, there are obvious drawbacks:
- it is the only actor we have that implements the scrollable interface
- it conveniently exposes its spacing property in CSS
- last but not least, it is used all over the place
So do the next best thing and make our implementation use the
Clutter layout manager internally - that way, the change is
transparent to users, while we get to refer most of the tricky
bits to Clutter. win-win!
https://bugzilla.gnome.org/show_bug.cgi?id=703810
Commit cfecd063c9 changed the allocation logic to not allocate
scrollbars when the *_visible booleans are false. This breaks the
fade effect as well as the NEVER policy. We do not paint scrollbars
when they are not supposed to be visible, so not allocating them
and thus leaving them in a "needs allocation" state just causes problems.
I am not convinced that it solved any problem to begin with (we don't paint
them anyway).
As the previous condition has basically always been true, just do it
unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=705664
We don't set :visible on the scrollbars, but use booleans to track
if they are visible. Thus check the booleans instead of the actor's
properties when allocating the scrollbars.
https://bugzilla.gnome.org/show_bug.cgi?id=704265
Use ClutterActor.allocate_align_fill() so we don't have to do
this math ourselves. At the same time, clean up the RTL handling
so that it's easier to follow.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
When the St theme is changed, the StThemeContext unrefs all the theme
nodes cached in it's internal hash table, then emits a signal to
notify all theme nodes that the current theme has changed.
The problem is that the first StWidget to catch a theme changed signal
will trigger a "style-changed" signal catched by its children first.
So the theme changed signal can't be processed properly to cleanup
StThemeNodePaintState before recomputing the theme.
This patch adds a weak ref to the StThemeNode in the
StThemeNodePaintState to ensure paint states are properly cleaned up
when the associated StThemeNode is freed.
https://bugzilla.gnome.org/show_bug.cgi?id=703859
Commit 318283fc70 optimized box-shadow rendering by not recreating
shadow materials on every allocation change. Other handles cannot
be reused and are updated regularly, however the patch missed the
cached corner materials - while those can be reused, we still need
to ensure that the currently used paint state references them.
https://bugzilla.gnome.org/show_bug.cgi?id=703909
It is the job of layout containers to arrange their children; having
a hidden feature that *also* allows children to be positioned freely
outside the parent's allocation is just odd.
With the last user of the feature gone, kill it.
https://bugzilla.gnome.org/show_bug.cgi?id=703808
