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.
tools/build/gnome-shell.modules: Point at master branch of Clutter (0.9)
and make gobject-introspection a dep of Clutter.
configure.ac src/Makefile.am: Use Clutter-0.9
js/ui/button.js js/ui/genericDisplay.js js/ui/overlay.js js/ui/panel.js
js/ui/runDialog.js js/ui/workspaces.js src/shell-status-menu.c:
Use ClutterText instead of ClutterLabel and ClutterEntry
js/ui/workspaces.js js/ui/genericDisplay.js: Use ClutterClone instead
of ClutterCloneTexture
src/shell-global.[ch]: Add Shell.get_event_key_symbol() to workaround
unaccessibility of clutter_key_event_symbol() to use.
js/runDialog.js js/overlay.js: Use Shell.get_event_key_symbol() as
appropriate.
Divide the screen into a grid and use it to determine the layout of the overlay components in a more consistent manner.
Remove the 'Add workspace' control and slide the workspaces
display to the side without scaling it when switching to the 'More' mode.
Automatically removes tweens on destroyed actors, and provides
additional "animation started/stopped" callbacks (eg, for tracking
whether or not to show window clone titles)
mode. When this control is clicked, documents display section slides down,
workspaces display slides to the side, and a multi-column applications view is
presented to the user. "More' control is replaced with a 'Less' control. When
the 'Less' control is clicked a default overlay view is restored.
Clean up positioning of the components of the overlay sideshow
and the items within generic item displays.
svn path=/trunk/; revision=179
- Don't let the user grab a moving window or we'll get dueling tweens.
- Update _overlappedMode each time _positionWindows is called
svn path=/trunk/; revision=170
* Make updating of the clone title more of a state-machine - instead
of showing/hiding/creating/raising the title all over the code, have a
single Workspace._updateCloneTitle() method that looks at state bits and
decides if the clone should be hidden or shown, and updates the
stacking and position.
* Move code to positioning of windows within a workspace in the overlay
modeto a new method Workspace._positionWindows()
* Add Workspace.addWindow()/removeWindow() to add and remove windows
from the workspace on the fly. (Triggered manually: we still don't
handle external changes to windows when the overlay is up.)
* Hook up mouse-dragging for window actors and add a
::window-dragged signal to Workspace
* Connect to ::window-dragged for each workspace, compute the new
workspace, move it the window there, and animate everything into the
new position. Snap back to the old location if the window didn't move.
http://bugzilla.gnome.org/show_bug.cgi?id=568753
svn path=/trunk/; revision=164
Use Tweener.registerSpecialPropertyModifier to handle moving windows in
straight lines on the screen even while their parent workspaces are also
moving.
Have the remove buttons track their parent workspace scale and deal with
it automatically rather than having special cases in each Workspace method.
svn path=/trunk/; revision=157
Can't close over loop variables in that way; need to define an explicit var.
Also fix case where no title is defined yet when attempting to adjust.
svn path=/trunk/; revision=154
The icon+text is useful in order to distinguish between windows
that might look similar otherwise.
The implementation is not optimal:
* We create a new texture from the pixmap each time
http://bugzilla.gnome.org/show_bug.cgi?id=563406
svn path=/trunk/; revision=129
