MutterWindow and MutterPlugin have been renamed to MetaWindowActor
and MetaPlugin, mutter_plugin_list_windows() to
meta_plugin_list_window_actors(). Adapt to those changes.
https://bugzilla.gnome.org/show_bug.cgi?id=632500
Add _st_actor_contains() in st-private for use within St, and
monkey-patch in a Clutter.Actor.contains() for use by javascript, and
then replace all the duplicate implementations with one or the other
of those.
https://bugzilla.gnome.org/show_bug.cgi?id=621197
Ignore the fullscreen flag when we are in the overview,
otherwise we might up not showing actors like the panel even though
they have visibleInOverview set to true.
https://bugzilla.gnome.org/show_bug.cgi?id=619693
This is our convention.
The only exceptions are double quotes for words in comments that give
them a special meaning (though beware that these quotes are not truly
necessary most of the time) and double quotes that need to be a part
of the output string.
In preparation for adding magnification, "uiGroup.patch", organizes the stage
along the following lines:
Stage
*Magnifier
UI group
Window group
Chrome group
Overlay group
Alt tab
App display
Chrome
...
This allows a magnifier actor to clone and magnify the UI group. The magnifier
is a sibling of the UI Group in this stage oraganization -- see the next patch,
"Magnifier.patch".
Previously we used a ClutterGroup containing a second ClutterGroup for
the non-visibleInOverview actors. Redo it using a single
ShellGenericContainer, and use set_skip_paint() to hide the
non-overview chrome when the overview is visible.
Also fix up the default values for trackActor().
https://bugzilla.gnome.org/show_bug.cgi?id=608667
The check in _windowsRestacked checks for
windows[i].x >= primary.x
and
windows[i].x <= primary.x + primary.width
(likewise for y).
This is wrong because a fullscreen window on the secondary screen is likely
to have windows[i].x == primary.x + primary.width which means that the checks
for _both_ screens would be valid, but the first one would win due to
the "break;" statement.
But here the window isn't really on the primary but on the secondary one.
Fix that by using < instead of <= for those checks.
https://bugzilla.gnome.org/show_bug.cgi?id=614509
Currently the check in chrome.js checks if a window is on the
primary screen by checking its coordinates, width and height.
This check misses the case where windows just set
_NET_WM_FULLSCREEN without changing their position and
size (examples are Flash and ooimpress's presentation window).
Fix this by separating the check for fullscreen windows from the
override redirect one, and only check whether the window is
anywhere on the primary screen in the fullscreen case.
https://bugzilla.gnome.org/show_bug.cgi?id=597271
Replace 'overlay' with the more descriptive name 'overview'
where the Activities Overview is meant. Call it Overview
(capitalized) in code comments.
The overlay-group and overlay-key provided by Mutter are not
affected, since they may be used for other components than
the Activities Overview.
The split between this.actor and this.nonOverlayActor in chrome.js is
annoying, but aside from actually subclassing ClutterGroup (which
would have to be done from C), all of the other possibilities are
annoying too.
Increase the priority of the idle for updating work area and struts
to META_PRIORITY_BEFORE_REDRAW. This prevents it from being starved
by a constantly-redrawing client.
http://bugzilla.gnome.org/show_bug.cgi?id=585500
- clutter_actor_get_transformed_position()/size() return floats
- clutter_stage_get_actor_at_pos() takes a pick mode
- ClutterTimeline no longer has a concept of frames
- ClutterUnit is now replaced by float
- cogl_texture_new_from_data() signature changed
http://bugzilla.gnome.org/show_bug.cgi?id=585013
Drag and drop was not working since the (non-reactive, invisible)
chrome group was on top of most of the screen. Explicitly set
a 0x0 size on that group to resolve the problem.
Adds an explicit "chrome" layer for the panel (and later the sidebar),
managing the input region and struts for them, and hiding them when
fullscreen windows are present or the user enters the overlay.
http://bugzilla.gnome.org/show_bug.cgi?id=581771
