When drawing the background image shadow, we need to clip it
to the node's background color, gradient, or borders if present.
If the background color is transparent, and there aren't any
borders, then we don't clip the shadow since there is nothing
to confine it.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
The border_texture (and border_material) variable is being
overloaded for two purposes: it's used as a source
to 9-slice the border from, and it's used as place to prerender
the background and border together for gradients.
While we only do one or the other for any given node, the two cases
are distinct, and should use distinct variables for readability.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
Currently, "-st-shadow" can mean one of three very
different things:
1) shadow based on alpha of the background image
2) shadow the "border box" of the node
3) shadow applied to the content of a StIcon
It isn't well defined which of the above 3 cases
-st-shadow will mean for any given node, however.
This commit splits the property into three
different properties, "box-shadow",
"-st-background-image-shadow", and "icon-shadow"
to make it all very explicit.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
This commit adds a few more examples to borders.js
that render borders with various combinations of
gradients, background images, shadows, and
border-images.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
With general support for swipe-scrolling in the overview, there is
no reason to limit the behavior to workspaces. It is equally useful
for scrolling through the grid of available applications, so enable
swipe-scrolling for the app view.
https://bugzilla.gnome.org/show_bug.cgi?id=635034
The workspaces view allows to drag the active workspace to swipe-scroll
to the next or previous workspace. While this behavior can come in handy
in general, there are good reasons to move the functionality to the
overview:
- Finding a spot on a workspace to start a drag can be hard,
especially when the workspace contains a single window
- With the new layout, workspaces have no visible border, making
it hard to predict where a drag can be initiated
- The same behavior is equally useful for other elements
So add setScrollAdjustment() to the overview, which allows setting
an adjustment controlled with swipe-scrolling (either horizontally
or vertically); only a single adjustment can be controlled at a
time. A swipe-scroll can be initiated on any part of the background that
is not occupied by a reactive actor. For cases where further control
is needed, 'swipe-scroll-start' and 'swipe-scroll-end' signals are
emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=635034
The vp8 codec provides better performance in pretty much all cases compared
to theora while still being free (as in not patent encumbered).
Also add a %T placeholder to the pipeline string which will be replaced
with the a thread count based on the target system.
https://bugzilla.gnome.org/show_bug.cgi?id=632595
Introduce a generic framework for on/off indicators that are shown
in the panel, next to the system status area, and use it for
showing the status of modifier keys.
https://bugzilla.gnome.org/show_bug.cgi?id=600771
StWidget reports a paint volume large enough to paint the current
theme node. As CSS transitions also paint the previous theme node,
the reported paint volume may be incorrect, resulting in screen
artifacts when painting outside the reported volume.
Add st_theme_node_transition_get_paint_box() to calculate an allocation
large enough to paint both theme nodes, and use it to report the correct
paint volume during transitions.
https://bugzilla.gnome.org/show_bug.cgi?id=640085
Drag monitor functions are supposed to return a value, but
_onDragMotion() does not always do so. Add the missing return
value and remove unnecessary else.
As Gdk.Device.get_state() does not work properly from Javascript,
we used to block it in the environment. The method now has been
annotated with (skip), causing shell to crash on startup as only
existing methods may be blocked.
Just remove the block in question, as the annotation prevents the
use of that method anyway.
Right now is just redefine atk_object_get_name.
If someone wonders why not implement AtkText interface, or expose the
internal ClutterText, here a extract from AtkText doc:
"AtkText should be implemented by AtkObjects on behalf of widgets that
have text content which is either attributed or otherwise
non-trivial. AtkObjects whose text content is simple, unattributed,
and very brief may expose that content via atk_object_get_name
instead;"
StLabel is attributed, but is still simple and brief. In the same way
the atk_object_get_name redefinition is required, so this patch is the
first step. We can implement AtkText in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=626658
It includes:
* Expose a proper focusable state, instead of the default one from
cally, using StWidget::can_focus, and also notifying the state change
* Management of the selected stated, using the current pseudo_class.
* Defines a new virtual method on StWidget: get_accessible_type. In
this way it is not required to reimplement get_accessible just for
a accessible type change. get_accessible is reimplemented using this.
You can see that as a substitute of the atk object factory
https://bugzilla.gnome.org/show_bug.cgi?id=636716
This basically:
* Checks a11y configuration properties
* Checks if clutter has a11y enabled
* Loads atk-bridge
It also ensure proper NO_GAIL and NO_AT_BRIDGE values on gnome-shell
startup script
https://bugzilla.gnome.org/show_bug.cgi?id=612599
Currently we reset the timeout on every mouse movement which means
the user has to keep the mouse at the exact same position for 1.25
seconds.
Be more tolerant and allow the user to move the mouse over the
window without reseting the timeout, which should make activating
windows easier.
https://bugzilla.gnome.org/show_bug.cgi?id=638896
- specify an overall font-family for all children of the stage and
for places where we just want to use a size, use font-size.
- also shrink the humongous 16px panel and menu size to a reasonable 14.
- scale up the icons to be 16px by default again
Based on a patch by Jakub Steiner <jimmac@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=634226
Instead of converting a CSS-specified length to an integer by truncation,
round. This means that sizes specified by converting a pixel value into
non-px terms will work reliably instead of potentially being off-by-one.
Commit a65a0f03d4 changed the literal RegExp to a string-based
RegExp(). As backslashes are treated specially inside strings,
translating an expression as /\s/ to '\s' results in a faulty
regex of /s/, so escape backslashes where necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=639914
This fixes the problem of chat notifications collapsing and then expanding
again when receiving multiple messages in the expanded new notification.
https://bugzilla.gnome.org/show_bug.cgi?id=629557
g_settings_schema_new() aborts if the requested schema is not found,
so the previous approach of handling the case of unstable nautilus
not being installed did not work.
Instead, remove the use of the setting altogether - the original intent
was to not have separate items for Desktop and Home in the places
section if the nautilus key was set. As the section has been removed
anyway, the impact of always adding the desktop folder is minimal
(e.g. searching for "desktop" will match the desktop folder even
if it's set to the home folder).
The latest development version of nautilus has been ported to
GSettings, which we now use as well for the desktop-is-home-dir
preference. Obviously, the required schema is only available if
a recent enough nautilus version is installed. Instead of adding
yet another module to the moduleset, catch the exception and
ignore the preference in case the schema is not available.
https://bugzilla.gnome.org/show_bug.cgi?id=639689
'Places' follows the nautilus preference of whether the Desktop
should be a separate directory or the home folder should be used.
Nautilus has been ported to GSettings a while ago, so follow suit.
https://bugzilla.gnome.org/show_bug.cgi?id=639689
