Every place that called chrome.addActor was specifying
visibleInOverview:true, and no existing designs call for chrome that
disappears when you enter the overview, so just drop that as an
option.
https://bugzilla.gnome.org/show_bug.cgi?id=633620
We call global.sync_pointer() on MetaScreen::restack as a hack to try
to fix up the hover state after a pointer grab. Previously we were
doing this in chrome.js, since there was already a ::restack handler
there anyway, but this isn't really related to the chrome at all, so
move it to main.js instead.
https://bugzilla.gnome.org/show_bug.cgi?id=633620
If the pointer moves on or off the stage while another process has a
grab, we will lose track of it. One example of this is that if you use
a popup menu from a message tray trayicon, the tray will stay up after
the menu goes away, because the shell never saw the pointer leave it.
Add a new method shell_global_sync_pointer() that causes clutter to
recheck what actor is under the pointer and generate leave/enter
events if appropriate.
Of course, we can't actually tell for sure when another process has a
grab, so we need a heuristic of when to call this. Currently we call
it from Chrome._windowsRestacked(), which is not really the right
thing at all, but does fix the menu-from-trayicon case...
https://bugzilla.gnome.org/show_bug.cgi?id=630842
Mutter really expects this, as this is how app-specified struts
happen. For instance, if the primary display is beside a taller
screen and is not positioned at the top, then we extend the struts
for the panel with the size of the unused area above the primary
monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
Right now we require a strut to be as wide as the full screen to
create a TOP strut. This means that in a multi-monitor scenario (at
least if the primary monitor is leftmost) we will make the panel strut
be Meta.Side.LEFT due to the random side picking for corner objects.
This changes the width/height comparison to the primary monitor rather
than the screen to get this right. Also adds some docs about how
struts work in a multi-monitor situation.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
This is required since we can have chrome on multiple monitors (due to
per-monitor hot-corners).
Windows are primary associated with the monitor that their center is on.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
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
