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
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
Previously, we initialized actor stacking order from the return
value of global.get_windows() once, which is defined to be in
stack order. However it was not updated later. Furthermore,
the way stackAbove was called from onAnimationComplete in
WindowClone was highly dubious, since there are lots of animations
which apply to the clones, and we want the stacking to be right
all of the time, not when some animation completes.
Fix this by connecting to 'restacked' on the screen and syncing
the clones.
I also snuck in another bugfix here; we weren't disconnecting
from the 'showing' signal handler, which had various bad
consequences.
https://bugzilla.gnome.org/show_bug.cgi?id=596263
Rather than having the mapping from window into "slots" (or
possible positions in the workspaces) be dependent on stacking
order, compute the minimum-motion which is a vector from one
top left corner to another. This order won't change as long
as the window set and their positions stay fixed.
There are two minimum motion algorithims; one simply computes
all possible placements by permuting the window list, up to
a current maximum of 5 windows. Past that (which also happens
to be the number where we switch to a grid), we use a "greedy"
algorithm which for each slot, finds the window with least motion
for that slot.
To break any ties, we use an internal integer in MetaWindow which
enumerates the order in which windows were created.
https://bugzilla.gnome.org/show_bug.cgi?id=582654
When we had a filtered set of windows, and want to exit the overview
into a particular window, what we do is re-show all the old windows
first, but don't reset the scaling on them. This will involve
some overlapping, but that's not a big deal because we'll immediately
get overlap anyways in the normal case zooming the windows back.
https://bugzilla.gnome.org/show_bug.cgi?id=594699
When the user click+hold+release over the icon, the effect we want
is for the menu to stick around.
Also, allow the user to mouse over the actual windows and select
them directly. If the user mouses over a window, reflect that in
the menu.
https://bugzilla.gnome.org/show_bug.cgi?id=594699
When the user click+hold+release over the icon, the effect we want
is for the menu to stick around.
Also, allow the user to mouse over the actual windows and select
them directly. If the user mouses over a window, reflect that in
the menu.
Rather than starting lightboxing only when the mouse enters the
menu, start it when an application filter is set.
Also delete a stale function in WindowClone from previous work.
http://bugzilla.gnome.org/show_bug.cgi?id=594555
When we have multiple windows for an application, implement the following
behavior:
* On click + immediate release, go to the most recently used
* On click, hold for 0.6s, pop up a menu with windows, filtering
the window list to just those windows.
Mouse over on the window list highlights the moused-over window.
Implement this by splitting well item into InactiveWellItem
and RunningWellItem, sharing a base class BaseWellItem.
The windows we considered for both the app monitor and the overview
workspaces were the same, but the code was duplicated once in C, once
in Javascript.
We had multiple copies of the code to position a drag actor given a particular
source. Instead, just put it inside dnd.js.
Second, rather than test for GenericDisplay/WellDisplayItem etc.,
in various places, add a new method on each source "shellWorkspaceLaunch"
which both marks the item as being droppable on a workspace, and is
called by the workspaces code to launch the item.
Instead of counting on the implicit sizing of ClutterGroup, which isn't
going to work well because of current limitations of ClutterClone, set
the size of workspace explicitly based on the screen size.
This should fix various problems with drag-and-drop being unreliable;
if a workspace was sized to big it could overlap other workspaces or
elements of the overview.
http://bugzilla.gnome.org/show_bug.cgi?id=591643
Remove the last use of passing width into Dash by having the
Pane with the previews scaling dynamically and relying on
Clutter scaling.
If we only have one workspace, don't display a selection frame
for it.
Rework Dash into a searchArea and sectionArea, which get
explicitly sized by overlay.js. We use the workspaces size
to choose the size of those dash areas.
Switch dash colors/boxes etc. to ones from shell-black02.
Add a gradient to the panel.
Add a magnifier.svg for use in search.
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.
Instead of only transforming the active workspace, create a
zooming effect when showing or hiding the overlay. This makes
the transitions simpler: the workspaces are now fixed to the
overlay actor group and will not slide over the Dash.
overlay.js: Add zoom animations, fade in/out Dash during those,
remove obsolete Dash clipping and stacking logic, add public
get[Scale|Position]() and getZoomedIn[Scale|Position]()
functions.
workspaces.js: Remove zoom animations, add fade animations for
the remove button, add helper functions for the overlay
zooming, keep the movement of windows linear to that of
their workspaces, remove the updatePosition() and
updateInOverlay() functions and fullSize variables that
were left from the old overlay design.
The scale of windows within a workspace is determined by the
scale of the workspace since we never scale a window bigger
than the original size of the window. So when we rescale
workspaces we have to rerun Workspace.positionWindows().
http://bugzilla.gnome.org/show_bug.cgi?id=591124
The onComplete when positioning windows may come before the
final stage of the workspace positioning animation. So we can't
use actor.get_transformed_position() to figure out where to put
the icons. Compute the final position manually ourselves instead.
http://bugzilla.gnome.org/show_bug.cgi?id=591123
Both the position and size of the frame actor depend on the scale
of the workspace, so update them both when the scale changes.
On the other hand, the the frame actor doesn't need to be
repositioned when the workspace moves (since it is relative to the
workspace). We do base the frame position of the desktop actor, but
that will presumably stay fixed (at 0,0) in most all cases.
http://bugzilla.gnome.org/show_bug.cgi?id=591122
When Workspace._positionWindows is called, the clone might nto
yet have its final size (because of the clone is is a clone of
the window texture and the window texture isn't updated until
right before painting.) So get the size from the MetaWindow
instead ... the MetaWindow size is determined synchronously when
the window is managed.
http://bugzilla.gnome.org/show_bug.cgi?id=590741
I've done some little modifications to the window positioning code
used in the overlay so that it considers the height of the windows
and they don't overlap or get out of the workspace.
I've also raised the hard-coded scales a bit to have the windows as
big as possible without overlapping (this could use some testing on
a non-widescreen monitor).
To better distinguish between vast fields of white of which many
windows are composed, add the application icon to the bottom
right of the window.
We fade them in to avoid an abrupt feel. The icons are in the
workspaces group, not individual workspace groups to avoid
having to adjust them when we scale the workspaces.
Replace Workspace._lookupIndexAndClone with Workspace.lookupIndex,
and make the caller go from index to clone, or clone and index.
Tweak arrangements with 2,3,4,5 windows in a desktop so:
- Windows are a bit bigger
- All windows for 5 windows are equally sized instead of making
the windows in the bottom row larger
This does cause some more problems with tall windows overlapping
or running off the edge of the workspace, but it's an overall
small improvement to the behavior.
We had duplicate code in appDisplay and workspaces for handling activating
a window; unify that inside workspaces, add an API to Main.overlay to
access it from both contexts.
Also, explicitly raise the clone we're activating to the top
before starting the animation to leave the overlay.
The goal of the workspace view is to identify and select windows. Transparency
results in the blending of the window and the background (and icons on the
desktop). I think the transparency is counterproductive.
We used it in the initial mockups kind of as a lark - it wasn't well thought
out.
http://bugzilla.gnome.org/show_bug.cgi?id=582647
Rather than having main.js manage this, put it into overlay.js, and
have the overlay object emit signals that other code can watch to do
things when the overlay is showing/shown/hiding/hidden.
Previously we forced all windows to shrink at least as much as the
workspace itself did. Now we allow to shrink by a smaller amount (or
not at all) if they'll still fit within their allotted slot.
http://bugzilla.gnome.org/show_bug.cgi?id=571192
Try to fix all places where we accidentally used foo_bar instead
of fooBar for function names, function parameters, and variables.
(Lucas Rocha pointed out one example.)
http://bugzilla.gnome.org/show_bug.cgi?id=581141
The overlay looks nicer with the root window pixmap drawn on the
background. It is scaled up to twice the size, with positioning
based on the rule of thirds.
The sideshow animations shown when entering or leaving the
overlay and toggling the extended view were implemented by
Marina Zhurakhinskaya. They replace the old method of having a
black rectangle behind the workspaces that partly covers the
sideshow during transitions.
configure.ac: Add gdk-x11, clutter-x11 and clutter-glx modules.
overlay.js: Add a root window pixmap actor, make sideshow width
definitions more logical, replace the way the sideshow
animates when entering or leaving the overlay.
workspaces.js: Remove the backdrop, add helper functions for the
overlay transitions.
shell-global.[ch]: Add a method that creates an actor displaying
the root window pixmap and returning clones of it.
The diagonal arrangement currently used in the overlay when there are
more than 6 windows is hard to read and hides most of the previews.
Both of these issues are fixed by arranging the windows in a grid pattern.
http://bugzilla.gnome.org/show_bug.cgi?id=576269
When a window is added while overlay is being exited (e.g. because
some application was launched), we don't want to add that window to
the workspace's window clones. Previously, the window clone was added
and an animation to place the windows to their overlay workspace view
positions was triggered, which resulted in the wrong animation being
shown and an abrupt change in window positions when the actual workspace
was shown.
Add a boolean argument to two _positionWindows() calls that were missing
an argument.
