The idea behind this move is that we have a lot more control over
rendering if StWidget isn't a big pile of actors, and things are
more efficient.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
The hover rewrite added a freeze/thaw_notify to
st_clickable_leave_event() (to match the one already in
st_clickable_enter_event()), which broke code in two places that
assumed "pressed" would still be TRUE when "hover" changed to FALSE.
Fix that by exposing the "held" property as well.
A pointer does not equal to an int on x86_64
(which results into pointer - pointer not being an int either),
fix that by casting the resulting value to an int.
Breakage was introduced by commit 909b5ec43c
If track-hover is set, update the hover property automatically, and
the "hover" pseudo class to match, as StClickable used to do. (Remove
the corresponding code in StClickable). Tweak the tooltip handling to
use track-hover, which also makes it slightly more reliable in the
presence of reactive children, etc.
Since style_class and pseudo_class are space-separated lists of names,
add new methods to add and remove individual names rather than just
re-setting the entire name.
Update existing code to use the new pseudo-class methods where
appropriate. In some cases, this may result in actors having multiple
pseudoclasses where previously they only had one at a time, but there
don't seem to be any visible differences.
(There are some places that could usefully use the new style_class
methods as well, but this patch doesn't change them.)
Also, update test-theme.c to test the new methods.
https://bugzilla.gnome.org/show_bug.cgi?id=604943
The way we were loading data into a CoglTexture, then pulling it out
and manipulating it on the CPU, then loading it back into a texture
was a bit lame.
Clean things up a bit here by loading directly into the CPU, doing
the fading, then creating a texture.
Also cache the faded data in StTextureCache.
https://bugzilla.gnome.org/show_bug.cgi?id=612759
If we don't do this, then boolean/int/list keys will seem to sort of
work (but defaulting to false/0/[] instead of the correct schema
defaults), but string keys will return null, which will usually cause
exceptions or crashes.
https://bugzilla.gnome.org/show_bug.cgi?id=611214
The relationship between adjustments and scrollbars and
scrollable widgets was much more complex than it needed to be.
StScrollView: Have the scroll view own a pair of adjustments,
set them on the child on add(), remove unnecessary
change notification signal connections.
StBoxLayout: Remove auto-create of adjustments, just take the
adjustments from the scrollbars and set them on the scrollable
child. Notify for hadjustment/vadjustment properties.
StScrollBar: Notify adjustment property.
StScrollable: Document how adjustment setting works.
https://bugzilla.gnome.org/show_bug.cgi?id=611740
* Add missing chain-up for dispose and finalize methods
* ShellGenericContainer needs to destroy its children in dispose()
* Fix variable naming and excess casts in st_label_dispose()
https://bugzilla.gnome.org/show_bug.cgi?id=612511
StScrollable: Document how to set adjustments
StBoxLayout: Make sure that we always have upper >= lower + page_size,
so that clamping works properly. Set the page_increment to be slightly
less than the page_size so there is some overlap, as is customary.
StScrollView: Remove unnecessary fabs() calls, rewrite expressions
for additional clarity.
https://bugzilla.gnome.org/show_bug.cgi?id=611740
- Fix existing typos and spacing problems
- Get preferred height, not current height, of shadows
- Let shadows overflow don't clamp them when we have too little space
- Remove a now-unecessary stray MAX()
- Fix up scrollview visibility for the pathological case of no child
- Disconnect from adjustments on remove()
- Don't unset the adjustments on the child on remove(), since they
already existed or were autocreated on add()
(We should what we are doing and set the adjustments of the
scrollbars on the child rather than setting the adjustments of
the child, so we match GTK+'s scrolllable interface, but this
at least makes it consistent instead of a weird mix.)
https://bugzilla.gnome.org/show_bug.cgi?id=611740
StScrollable: Document how size negotation now works between the
parent and scrollable child.
StBoxLayout: Adapt to the new contract for how size negotiation
works; in particular, handle being allocated less than the
minimum size when scrolled and treat the minimum size as the
size of the scrolled area in instead of the natural size.
StScrollView: Substantially rewrite with fixes including:
- Implement new size negotation contract; this allows us
to determine scrollbar visibility without having to
connect to the adjustment.
- Implement all ALWAYS along with the existing NEVER/AUTO
- When hiding and showing scrollbars and shadows, don't
hide and show widgets, just turn on and off including them
in pick and paint. This avoids queueing relayouts.
- Cleanups for the code for connecting to adjustments,
for changing policy, and for turning on and off shadows.
scroll-view-sizing.js: New test case for StScrollView, allowing
resizing the scroll view interactively, changing the scrollbar
policies and turning shadows on and off.
https://bugzilla.gnome.org/show_bug.cgi?id=611740
When an StScrollView is allocated, allocating the child would
cause the adjustment values to change, which would result in
the scrollbars queueing a relayout, which isn't allowed during
allocation.
To avoid this, instead of queueing a relayout when the adjustment
changes:
- When we have a valid allocation already, just go ahead
and reallocate the children.
- Otherwise do nothing immediately and wait until we get allocated
Because the 'needs_allocation' flag in ClutterActor isn't exposed,
this requires some slightly ugly code to shadow that state locally.
https://bugzilla.gnome.org/show_bug.cgi?id=611944
Having StDrawingArea use ClutterCairoTexture causes circularity
problems with sizing - StDrawingArea wants to use its allocation for
the size of the texture, but ClutterTexture wants to use the size of
the texture to determine the requited size.
Avoid this by making StDrawingArea directly use Cairo and CoglTexture;
while doing this, the API is changed a bit for simplicity and to
match our use case:
- Instead of clutter_cairo_texture_create(), we have
st_drawing_area_get_context() to retrieve an already created
context. This can only be called in the ::repaint signal.
- The ::redraw signal is changed to ::repaint so we can have
st_drawing_area_queue_repaint() that doesn't collide with
clutter_actor_queue_redraw()
- ::repaint is now emitted lazily when painting the actor rather
than synchronously at various different points.
https://bugzilla.gnome.org/show_bug.cgi?id=611750
- Specify a minimum version of clutter-1.2.0
- Switch clutter branch in the moduleset to master
- Replace deprecated cogl_texture/material_unref() with
cogl_handle_unref()
- Use cogl_clip_push_rectangle() rather than cogl_clip_push()
- Replace cogl_check_extension() with strstr - should be
accurate enough.
https://bugzilla.gnome.org/show_bug.cgi?id=610679
It's wrong to do anything that requires looking up a widget's style
before you add the widget to the stage, since its final style may
depend on properties inherited from its parents.
st_widget_get_theme_node() used to emit a warning in this case, but
many would-be contributors apparently didn't notice. Help them out.
https://bugzilla.gnome.org/show_bug.cgi?id=610279
StButton animated the background for button transitions; since these aren't
presently part of the shell design, simply remove them. We can readd
these in the future.
StTooltip should probably have :vertical and :horizontal pseudo classes
to make the arrow work but it should still function.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
Rather than having ShellTextureCache know about the type of each
item it's caching, this lays the foundation for simply caching
arbitrary string -> CoglHandle.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
For StWidget we want the ability to load raw CoglHandle references
rather than having a big pile of actors backing StWidget.
Several bits of StWidget expect to be able to synchronously load
textures; this is a crutch to support that until we can cleanly
make this asynchronous.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
Brute force merge these two by essentially replacing St.TextureCache
with a (renamed) Shell.TextureCache.
One function was added for convenience, namely "st_texture_cache_load_file_simple".
St.TextureCache had a function to load a texture from a filename, and it
returned NULL on error but only half the callers actually checked this. This
function is better.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
StScrollBar: Be robust against being disposed multiple times,
which can happen, and in fact, normally happens when destroying
the parent.
StScrollView: Implement remove() for the hscroll and vscroll members,
and just destroy them in dispose() and let them be removed.
unparent the shadows, instead of just unref'ing them directly.
https://bugzilla.gnome.org/show_bug.cgi?id=611203
When starting oocalc or ooimpress from oowriter's menu get_app_for_window,
fails to recognize the newly started up as such, which result into the appMenu
still showing "Openoffice.org Writer" as app name.
Fix this by trying to window itself first before using the group for finding the app.
https://bugzilla.gnome.org/show_bug.cgi?id=611288
Since shell-slicer.h includes st.h, and that includes
<st/*.h>, we need to add -I $(srcdir) to the command line when
running g-ir-scanner to generate Shell-1.0.gir.
For srcdir != builddir, in the builddir, the st/ subdirectory doesn't
exist, so we can't generate st.h there. Just switch to building st.h
directly in the current directory. (The other option would be to
create a st/ subdirectory in the builddir if necessary; might be a
little cleaner, but this works for now and gets things distchecking.)
Add a 'vshadow' property to StScrollView, which, when turned on,
overlays gradient shadows on the top and bottom of the StScrollView.
Turn this on for the StScrollView used for the app browser.
https://bugzilla.gnome.org/show_bug.cgi?id=609604
The type we don't currently handle is _ALWAYS, my original use
of g_return_if_fail was wrong.
Also the default should be AUTOMATIC in the properties, not ALWAYS.
Finally the test case was still using the incorrect St.ScrollPolicy.
https://bugzilla.gnome.org/show_bug.cgi?id=609015
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.
