Previously we were hacking out the vertical scrollbar, this patch
allow us to sanely say in which directions we want to scroll.
Note this patch intentionally changes St to depend on GTK+ in the
API. I believe this is a correct long term change where we should
view St as co-evolving with GTK+ rather than replacing or paralleling.
https://bugzilla.gnome.org/show_bug.cgi?id=609015
st_theme_node_adjust_preferred_width/height now limit the content area
of an actor to the max, if given. (The requested width/height may be
larger to make room for borders, etc.)
https://bugzilla.gnome.org/show_bug.cgi?id=606755
In StBin, StBoxLayout, and StTable, if a child has a potential
allocation that is larger than its preferred size, we give it its
preferred size instead. However, the corresponding
get_preferred_height/width methods were not making the same
assumption, which meant that if we had more width than the widget
wanted, we would allocate it its preferred width, but with the height
that corresponded to the larger width.
Fix this by defining new helpers _st_actor_get_preferred_width() and
_st_actor_get_preferred_height() and using them everywhere. Also, make
StBin and StTable use _st_allocate_fill() rather than having
nearly-identical duplicate copies of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=609848
The forward/backward steppers are always allocated a square region at the
scroll bar's ends. Change the allocation to be based on the steppers' size
requests instead.
https://bugzilla.gnome.org/show_bug.cgi?id=609401
Make the framerate, file extension and gstreamer pipeline used by the
screencast recorder configureable using gconf.
This patch does not change the defaults, it justs provides a way for
the user to override them.
https://bugzilla.gnome.org/show_bug.cgi?id=608995
Fixes drawing of the overview in the case where there is no root pixmap
(eg, --xephyr mode).
(And the workaround for not drawing an unintialized ClutterTexture can
be removed now, since the texture will always have been initialized.)
https://bugzilla.gnome.org/show_bug.cgi?id=609339
To comply with C89, structure initializers should have
only constant values.
(Not a thorough check for this throughout the codebase, just
StWidget is fixed up in this commit.)
https://bugzilla.gnome.org/show_bug.cgi?id=608746
As of 2a78adc5e3, gobject no longer allows for setting construct-only
properties via g_object_set() during object initialization; set the
properties in a custom constructor instead.
https://bugzilla.gnome.org/show_bug.cgi?id=608802
In some situations we might need to look up an application from
a process identifier, such as the notification system where we
will determine application from the message sender.
By calling clutter_actor_get_allocation() in st_widget_recompute_style()
to determine whether to redraw gradients, we triggered a complete
reallocation of the stage for each gradient.
As gradients are processed in st_widget_real_style_changed() anyway, the
additional checks in st_widget_recompute_style() are redundant and can
be removed altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=608847
On style changes from gradient to solid backgrounds, the new background
must be drawn unconditionally, not depending on whether old and new
background color differ.
https://bugzilla.gnome.org/show_bug.cgi?id=608914
The current way we keep track of skip-paint children is more
difficult than it needs to be, and can lead to subtle bugs.
(For one, the skip-paint state of a child is remembered
when it is removed then added back again, which is completely
unexpected.)
Instead of using weak references to track children, just remove
items from the skip-paint list by overriding the remove() virtual
function of the ClutterContainer interface.
The 'skip_paint' hash table is then destroyed in finalize rather than
dispose since it doesn't hold references to memory any more but just
passively tracks an attribute of the children that are currently in
the container.
https://bugzilla.gnome.org/show_bug.cgi?id=608848
When moving a widget with a gradient, its allocation changes
continuously, resulting in constant redraws.
Checking for actual size changes before the operation avoids
unnecessary redraws.
https://bugzilla.gnome.org/show_bug.cgi?id=608715
The screen recording wasn't working because of two bad interactions
with Cogl:
- Buffered primitives weren't being flushed out
- Cogl changes the pixel store values away from their default values
Thanks for Jon Nettleton for tracking down the source of the
problems with the recorder.
https://bugzilla.gnome.org/show_bug.cgi?id=598390
StButton has an internal animation for the border-image actor, then
it connects to the "completed" signal passing itself as data. However,
if the button is destroyed, nothing prevents the animation's completed
signal from then causing a reference to freed memory.
Holding a reference to the button is the most straightforward fix here.
https://bugzilla.gnome.org/show_bug.cgi?id=607825
Added signal 'screen-size-changed' to ShellGlobal.
Connect to this signal in main.js and run the _relayout() method.
If Overview or calendar are visible when this signal emit, they will be hiding.
https://bugzilla.gnome.org/show_bug.cgi?id=584526
Replace ngettext with dngettext and set the correct translation
domain, so gnome-shell's domain is searched for translations
rather than mutter's.
https://bugzilla.gnome.org/show_bug.cgi?id=597882
Some theme authors have stated interest in radial gradient backgrounds.
The w3c has some draft:
http://dev.w3.org/csswg/css3-images/#radial-gradients
As this is rather complex, we add only some very basic support, which
extends our syntax for linear gradients:
background-gradient-direction: [vertical|horizontal|radial]
Gradients are centered circles, whose size is determined by the closest
side.
https://bugzilla.gnome.org/show_bug.cgi?id=604945
Some changes to the way we handle CSS gradients:
* draw without padding, thus interpreting gradients as part of the
background rather than as content
* clip to (rounded) border area
* draw the border along the gradient instead of trying to align the
gradient layer with the background/border layer
* use the border_image actor instead of the background_image one
https://bugzilla.gnome.org/show_bug.cgi?id=606257
We were holding on to UsageData structure pointers in previously_running,
but those can be purged by the unused app cleanup. Instead just hold
onto dup'd copies of the application id strings.
Add support for a new -st-shadow property, which is based loosely
on the CSS3 box-shadow property:
http://www.css3.info/preview/box-shadow/
It defers from the specification as follows:
* no multiple shadows
* the optional color argument may be placed anywhere
* the shape is not determined by the widget's bounding box,
but by the background-image property
https://bugzilla.gnome.org/show_bug.cgi?id=603691
Change "./src/gnome-shell --create-extension" to use "gnome-open"
when opening the newly created .js file, so that it is launched
with the user's preferred text editor, instead of hardcoding gedit.
In case of duplicate infos structures with the same id, the
info structures we get from looking up the id in app_id_to_info
aren't necessarily the same as those we used to match, so we
can't rely on matching to implicitly initialize info->casefolded_name.
Since the name collation key isn't used in matching results,
just in sorting, init it on-demand in the sorting which is also more
efficient.
Move CSS handling of StLabel and StButton for their underlying
ClutterText objects into st_private, and implement support for
the underline and strikethrough St text-decoration properties.
Overline isn't implemented for lack of a corresponding Pango
attribute, and blink, well...
https://bugzilla.gnome.org/show_bug.cgi?id=599661
Consumer documentation will live at http://live.gnome.org/GnomeShell/Extensions
In terms of implementation; basically we load extensions from the well-known
directories. Add a GConf key to disable extensions by uuid. There is a new
option --create-extension for the gnome-shell script which takes a bit of
interactive input, sets up some sample files, and launches gedit.
No extensions UI in this patch; that will come later.
https://bugzilla.gnome.org/show_bug.cgi?id=599661
The high level goal is to separate the concern of searching for
things with display of those things; for example in newer mockups,
applications are displayed exactly the same as they look in the
AppWell.
Another goal was optimizing for speed; for example,
application search was pushed mostly down into C, and we avoid
lowercasing and normalizing every item over and over.
https://bugzilla.gnome.org/show_bug.cgi?id=603523
