Thanks Owen and Colin for debugging this:
<davidz> does anyone have a clue about this cryptic error message: http://fpaste.org/aWgh/ ?
<owen> davidz: well, I'd guess some sort of syntax error...
<walters> hmm
possibly but unlikely fallout from my js versioning
<owen> oh, it's happening here too
walters: exactly
Adding --js-version=1.8 to the wrapper script fixes
walters: I thought you were defaulting to allowing extensions?
<walters> actually, let's do that now anyways
Signed-off-by: David Zeuthen <davidz@redhat.com>
We weren't freeing the whole pixbuf, nor were we the GList of
subpixbufs. Plug both of these leaks in the error handling path
and in the default case.
All of the unreffing/cleanup should happen in the GDestroyNotify
for the result, not some in the handler.
https://bugzilla.gnome.org/show_bug.cgi?id=636489
While non-uniform border widths were parsed correctly, an arbitrary
side's width was picked when painting, so that each border ended up
with the same width and the widths specified in CSS were ignored.
At least for sides between non-rounded corners, using a different
border width can be reasonable, for instance at screen edges.
Different border widths around rounded corners are kind of crack,
but then it would be lame not to support it ...
https://bugzilla.gnome.org/show_bug.cgi?id=607500
For gradient backgrounds, borders were implemented by filling the
background shape with the border color first, and then scaling down
the path to draw the background.
The result is not correct[0], which is especially visible if the border
width is greater than the border radius - so instead of scaling down
the original path, use a separate path for the background.
The result is consistent with the borders we draw for non-gradient
backgrounds, and much closer to the correct standard behavior.
[0] http://www.w3.org/TR/css3-background/#the-border-radiushttps://bugzilla.gnome.org/show_bug.cgi?id=607500
non-absolute paths specified as url()'s in
stylesheets are resolved to be relative to the location
of the stylesheets they are in.
Inline styles don't have physical styleshseets sitting on disk,
which leads to a crash in the url resolving code.
This commit ensures that we don't try to use the stylesheet associated
with a url, if there isn't one to use.
This commit doesn't try to handle relative paths in inline styles.
It only prevents crashes when absolute paths are used.
https://bugzilla.gnome.org/show_bug.cgi?id=636975
This prevents a race at start up that could prevent the user
from getting loaded properly.
In the near future we need to drop the gdm user code entirely
and switch to using the accountsservice library.
When scrolled, st_box_layout_apply_transform() includes the scroll
offset and affects paint volumes. This is right for our children, but
our paint volume is determined by our allocation and borders and
doesn't scroll, so we need to reverse-compensate, the same as we do
when painting.
https://bugzilla.gnome.org/show_bug.cgi?id=630932
In order to take advantage of clipped redraws (only redraw the
parts that actually changed), we have to inform clutter about
our paint_volume by implementing the get_paint_volume virtual
method.
As this feature had been added in in clutter 1.5.x we now require
that.
https://bugzilla.gnome.org/show_bug.cgi?id=630932
We were going to great effort to include the normal directories in the
GJS search path and the code to to do this broke recently when
jsdir and jsnativedir were moved to gjs-internals-1.0.pc. However, it
was actually unnecessary since the standard directories are appended
to the default path.
(We continue to use a GNOME_SHELL_JS envvar separate from GJS_PATH
for the Shell to enable the somewhat unlikely case where someone wants
to invoke the shell specifying a GJS_PATH.)
https://bugzilla.gnome.org/show_bug.cgi?id=635367
Aggressive compiler flags can cause the compiler to be smart enough
to inline functions and detect variables not being set on certain
code paths but not smart enough to understand the overall logic;
add some extra initializations to suppress the warnings.
Fix several minor bugs in the logic found when double checking the
logic before adding the initializations.
Based on a patch by Marc-Antoine Perennou <Marc-Antoine@Perennou.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=634225
At times it is desireable to hide actors from being picked even
with a mode of CLUTTER_PICK_ALL.
Currently we use a pattern of
clutter_actor_hide();
clutter_stage_get_actor_at_pos();
clutter_actor_show();
in these cases, which gets hideous if the actor we want to exclude
from the pick is located in another module.
A more elegant solution is to connect a handler to the ::pick signal,
which stops further emission.
Credit for the idea goes to Owen Taylor.
https://bugzilla.gnome.org/show_bug.cgi?id=634560
The code to draw the root background has now been moved into Mutter,
with added smarts to not draw obscured portions. Remove the old
version of the code and clone the Mutter background actor to draw
the background in the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=634836
We weren't actually referencing the ShellTrayIcon actors at all
on creation, but would unreference them when they were removed,
causing crashes.
When we reference the actors, use g_object_ref_sink() so that
memory management is consistent whether or not the actors are
subsequently added to a parent actor.
Thanks for Jon McCann for help in tracking this down.
https://bugzilla.gnome.org/show_bug.cgi?id=635141
Add a "gicon" property so that a GIcon can be used instead of an
icon name, while still getting icon recoloring from the theme.
Also include a compatibility wrapper in libshell until GJS has
support for interface static methods.
https://bugzilla.gnome.org/show_bug.cgi?id=622451
Connect to the "changed" signal on the default icon theme, and
when it triggers:
- Evict all cached looked up icons from the StTextureCache
- Fake a style change on all StThemeContext; this will result
in StIcon looking up icons again.
https://bugzilla.gnome.org/show_bug.cgi?id=633866
It is not referencing them when adding, and also it is connecting
to the "destroy" signal, emitted on dispose, so there is no risk
of storing finalized objects.
https://bugzilla.gnome.org/show_bug.cgi?id=634781
We were always drawing the border and background of each
StThemeNode, even if they were transparent. The simple
optimization of checking the alpha provides a significant
performance boost (in a quick test, it increased the
overviewFpsSubsequent metric in the core performance test
from 28fps to 35fps).
https://bugzilla.gnome.org/show_bug.cgi?id=634752
Now that we're using St.Icon in the Javascript, there is no reason
to have separate st_texture_cache_load_icon_name() and
st_texture_cache_load_icon_name_for_theme(), instead just add
the StThemeNode argument to st_texture_cache_load_icon_name().
https://bugzilla.gnome.org/show_bug.cgi?id=633866
Use st_texture_cache_load_icon_name_for_theme() so that we get the
right colors for symbolic icons. The code refactoring to achieve this
also avoids constantly starting a new icon load each time we set
a property on initialization ... the icon is loaded only after we
have a #StThemeNode assigned.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Sometimes it's useful to get the theme node if there is one and do
nothing and wait for the ::style-changed signal if there is no theme
node. Add st_widget_peek_theme_node() that just gets the current
theme node if available. The caller must handle a %NULL return.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Add st_texture_cache_load_icon_name_for_theme() which, when loading a
symbolic icon, gets a #StIconColors from the theme node and uses that
to colorize the icon.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
A new StIconColors object is used to efficiently track the colors
we need to colorize a symbolic icon.
st_theme_node_compute_icon_colors() is added to compute the
StIconColors for a theme node. (Refcounting of StIconColors means
that we'll typically share the colors object of the parent node.)
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Scaling up icons from the loaded size to a larger size is uniformly
ugly and results in a long series of "fuzzy icon" bugs. It's better
to just load at the specified size and center. (Centering can be
overridden by packing not-fill in the parent container.)
https://bugzilla.gnome.org/show_bug.cgi?id=633865
We don't want the layout to change when we say, change from
battery-full to battery-full-charging, so we should request a square
based on the icon size unconditionally and not try to adapt to the
size of the texture we loaded. This also means that our layout is
independent of the loaded texure which, if we switch away from
using a ClutterActor child will allow us not queue a relayout when
the icon finishes loading.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Make StIcon compile and work in St.
Changes:
* ::icon-type and st_icon_set_icon_type are added to allow
specifying SYMBOLIC/FULLCOLOR for an icon.
* Ability to set the icon name from the theme is removed; it
wouldn't easily fit into our framework and two levels of
abstraction between code and image doesn't seem that useful.
* size CSS property is renamed from x-st-icon-size to icon-size
to correspond to what we are doing elsewhere.
* CSS and property based icon sizing are cleanly layered - if
you set the icon-size property, the CSS size is ignored.
* Add a simple JS test of StIcon.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
StIconType will be used by a new StIcon class, so move it to the
header file of common enumerations. Including st-types.h which had
the St single-include check revealed that st-texture-cache.h didn't
have that check and several places were including that directly.
Fix that up.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
The ability to set a "content image" on an icon relies on the ability
to have custom theme properties of a "border image" (9-slice) type.
We don't have this, and the capability of a bordered image specified
by the theme can be achieved more naturally with standard CSS facilities.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
ST makes use of GTK+ for input methods and for icon themes; therefore
we have need to initialize GTK+ in order to test these parts of Clutter.
Instead of LD_PRELOADING our module, use a separately compiled executable
that links to the UI components in GNOME Shell, initializes Clutter and
GTK+ and hooks them together.
Getting all the symbols from St and the GUI components exported for
use via GJS requires a bit of contortion: we need to actually link the
St convenience library into a shared library and link the executable
to that since there is no way with libtool to take a convenience library
and put all its symbols into an executable --whole-archive style.
https://bugzilla.gnome.org/show_bug.cgi?id=633657
