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
Ideally we'd be able to override _paint, but given that we can't
at the moment, this method gives a way to implement containers
which don't happen to paint all of their children.
https://bugzilla.gnome.org/show_bug.cgi?id=603522
The synchronous close causes us to block in fsync() which has extremely
poor interactivity implications on ext3.
Also, the 5 second timeout was an accidental commit from debugging, 5
minutes is fine.
https://bugzilla.gnome.org/show_bug.cgi?id=602456
StClickable replaces ShellButtonBox. Reduce the number of
button-like things by deleting button.js.
To do so, add CSS style for the actitivies button.
https://bugzilla.gnome.org/show_bug.cgi?id=602131
Now a StBin, and add hover/active style properties. Also, add the
event to the CLICKED signal. Otherwise a straightforward namespace
transformation.
https://bugzilla.gnome.org/show_bug.cgi?id=602131
It's nicer to have ShellDrawingArea as a St widget so it can
participate more cleanly in CSS styling, such as queuing a redraw
automatically on style changes, and allowing subclasses to use
CSS styling.
https://bugzilla.gnome.org/show_bug.cgi?id=602131
Rather than having gradients be individually implemented by higher
level JS widgets, move basic gradient functionality into StWidget.
There is prior art in WebKit for CSS gradients:
http://webkit.org/blog/175/introducing-css-gradients/
However, implementing this would be quite a lot of work; all we
need in the Shell design at the moment is basic horizontal/vertical
linear gradients. So, the syntax now supported is:
background-gradient-type: [vertical|horizontal]
background-gradient-start: color;
background-gradient-end: color;
https://bugzilla.gnome.org/show_bug.cgi?id=602131
An earlier commit was overzealous in removing (out) annotations;
introspection supports (out) for integral types just fine, we
only need to remove them for (out) types where the caller needs
to allocate a boxed type.
https://bugzilla.gnome.org/show_bug.cgi?id=602131
In addition to the Makefile changes, we also change uid_t to gulong in
the public API (which matches how it was already represented in the
gobject properties).
https://bugzilla.gnome.org/show_bug.cgi?id=601458
In a variety of places we're using boxes as data-modeling displays,
and in doing so we often want to either remove the children or
explictly destroy them.
Now ideally Gjs would support callbacks, and this would make using
the for_each functions possible, but even then these functions
are more efficient and shorter to type, at least.
https://bugzilla.gnome.org/show_bug.cgi?id=600734
If the space we're allocated is too small for our border + padding
constraints, don't give negative allocations to callers. Squash
to zero.
It isn't really useful for callers to get negative content sizes,
and certainly breaks most allocation code.
https://bugzilla.gnome.org/show_bug.cgi?id=600734
StTheme CSS supports different border widths for different sides. Implement
it for StWidget by drawing the border internally. However, we don't support
a nonzero corner-radius with nonuniform borders.
https://bugzilla.gnome.org/show_bug.cgi?id=599442
Previously shell_app_remove_window assumed that it was being
passed a window in its list; rather than having callers check
whether a window is interesting and only if so removing it
from the app, just ignore removal of windows we aren't interested
in, like how we ignore addition of windows we already have.
https://bugzilla.gnome.org/show_bug.cgi?id=598502
The behavior in respect to borders matches CSS - the properties set the size of
the content exclusive of the borders (CSS3 box-sizing property - not implemented
here - changes this).
min-width/min-height correspond very closely to the CSS meanings.
width/height are a little different from the CSS meanings - the CSS meaning is
"exactly this size unless overridden by min/max-width/height" - but within the
realm of our layout algorithm, making them control natural size is pretty
close.
This way we can force elements to have a fixed natural or minimum size.
https://bugzilla.gnome.org/show_bug.cgi?id=598651
For the purposes of determining which application is focused, don't
skip "uninteresting" windows. The old get_focused_window code
was used for usage tracking, but here we want reliable application
association.
Also convert a .text= to .set_text that was missed with the last
patch.
https://bugzilla.gnome.org/show_bug.cgi?id=599206
The two parts were mapping windows to applications, and
recording application usage statistics. The latter part
(now called ShellAppUsage) is much more naturally built on top of
the former (now called ShellWindowTracker).
ShellWindowTracker retains the startup-notification handling.
ShellWindowTracker also gains a focus-app property, which is
what most things in the shell UI are interested in (instead of
window focus).
ShellAppSystem moves to exporting ShellApp from more of its
public API, rather than ShellAppInfo. ShellAppSystem also
ensures that ShellApp instances are unique by holding
a hash on the ids.
ShellApp's private API is split off into a shell-app-private.h,
so shell-app.h can be included in shell-app-system.h.
Favorites handling is removed from ShellAppSystem, now inside
appFavorites.js.
Port all of the JavaScript for these changes.
https://bugzilla.gnome.org/show_bug.cgi?id=598646
The window lists were not being resorted when user-time changed, and
the app list was mistakenly "penalizing" apps for having *any*
minimized windows, rather than for having *only* minimized windows.
https://bugzilla.gnome.org/show_bug.cgi?id=598389
Previously, we had ShellAppInfo, which contains fundamental
information about an application, and methods on ShellAppMonitor
to retrieve "live" information like the window list.
AppIcon ended up being used as the "App" class which was painful
for various reasons; among them that we need to handle window
list changes, and some consumers weren't ready for that.
Clean things up a bit by introducing a new ShellApp class in C,
which currently wraps a ShellAppInfo.
AppIcon then is more like the display actor for a ShellApp. Notably,
the ".windows" property moves out of it. The altTab code which
won't handle dynamic changes instead is changed to maintain a
cached version.
ShellAppMonitor gains some more methods related to ShellApp now.
In the future, we might consider changing ShellApp to be a GInterface,
which could be implemented by ShellDesktopFileApp, ShellWindowApp.
Then we could axe ShellAppInfo from the "public" API and it would
return to being an internal loss mitigation layer for GMenu.
https://bugzilla.gnome.org/show_bug.cgi?id=598227
