Commit Graph

111 Commits

Author SHA1 Message Date
Florian Müllner
2021edd1fb workspaces-view: Set geometry on new workspaces
Currently the workspace geometry is updated on zoom/allocation
changes, which means that newly added workspaces use their initial
geometry of (0, 0, 0, 0) until the next zoom change. As a result,
windows on the affected workspaces are mispositioned, e.g. placed
outside the workspace area. To fix, set the geometry on newly added
workspaces to the view's cached values.

https://bugzilla.gnome.org/show_bug.cgi?id=649001
2011-06-03 19:56:33 +02:00
Florian Müllner
45c1a9eafb workspaces-view: Simplify handling of removed workspaces
Workspaces used to contain the desktop background, so when a
workspace was removed, we animated its actor to an off-screen
position before destroying it. As the background has been
removed a while ago, we can destroy the actor directly.

https://bugzilla.gnome.org/show_bug.cgi?id=645031
2011-06-03 19:56:33 +02:00
Dan Winship
898b2b903d environment: put gettext stuff into global environment
Rather than defining _() as a local function in every module, put it
into the global environment (along with C_() and ngettext()).

https://bugzilla.gnome.org/show_bug.cgi?id=649203
2011-05-16 14:57:21 -04:00
Adel Gadllah
56d584b7c6 workspacesView: Don't change opacity during dnd
We used used to indicate to the user the ability to move to another workspace
during dnd by highligthing the adjacent workspaces on hover.

This was done by changing the workspace's opacity to 200 and set it to
255 for the highlighted adjacent ones.

This is now no longer needed as the design was completely changed since
then (overview relayout; we no longer represent workspaces in the way
we did before) and introduces a bug where we don't properly reset the
opacity after the drag action, so just remove that code.

https://bugzilla.gnome.org/show_bug.cgi?id=648983
2011-04-30 00:04:22 +02:00
Alexander Larsson
f84c62f0be Fix overview sizing when exiting via thumbnails
We need to update WorkspacesView._ZoomOut before calling
_updateWorkspacesGeometry() in show(), as otherwise the old
value is kept. This was a problem if we previously left the
overview zoomed out.
2011-03-22 12:50:14 +01:00
Adel Gadllah
528fc9bc47 XDND: Allow workspace switching using the thumbnails
Currently activating a window on a different workspace requires very
long drag distances, which is very inconvenient to use.

Fix that by allowing switching workspaces using the thumbnails which is
consistent with window and launcher dnd and much easier to use.

https://bugzilla.gnome.org/show_bug.cgi?id=643945
2011-03-22 00:05:17 +01:00
Alexander Larsson
b2df3fcd1d Always show the workspace thumbnails if there is a monitor to the right
If there is a monitor to the right it is very easy to overshot the
expanding thumbnails and enter the next monitor. So, in that case
we just always show it.

https://bugzilla.gnome.org/show_bug.cgi?id=641877
2011-03-21 18:48:57 +01:00
Florian Müllner
7f35b2dc43 workspaces-view: Zoom out early on canceled item drags
Start the zoom at the same time as the snapback animation, as it's
already done for window snapbacks.

https://bugzilla.gnome.org/show_bug.cgi?id=644324
2011-03-19 11:16:10 +01:00
Jasper St. Pierre
f259162d64 workspacesView: Fix graphical glitches with windows appearing for a split-second
When we were knocking off workspace height to fix the ratio problems, we
weren't adding spacing in between workspaces, so they smooshed up against
each other whenever we took height off, causing them to be visible.
2011-03-18 23:21:43 +01:00
Alexander Larsson
09f2028d6a overview: hidden workspace thumbnails should not stick out on other monitor
We clip the entire WorkspacesDisplay to its allocation to avoid things
like the WorkspaceThumbnails sticking out of the primary monitor into
another monitor.

https://bugzilla.gnome.org/show_bug.cgi?id=609258
2011-03-17 14:13:55 +01:00
Alexander Larsson
05736ba0a1 Always reserve space in all workspaces on a drag
We used to do this only on automatic workspace switch, but that
doesn't work for the multiple monitors case where we want to reserve
space on the extra monitors.

https://bugzilla.gnome.org/show_bug.cgi?id=609258
2011-03-17 14:13:55 +01:00
Alexander Larsson
e5f05bc9d8 Add workspaces on non-primary monitors
We create a Workspace with a null metaWorkspace for each
non-primary monitor, showing the windows on these monitors.
These are saved in WorkspaceView.extraWorkspaces.

https://bugzilla.gnome.org/show_bug.cgi?id=609258
2011-03-17 14:13:55 +01:00
Alexander Larsson
cdd1209b55 Only show windows from the primary monitor on the overview workspace
This means a bunch of windows will not be visible at all in the overview.
Those will be added back with per-screen workspaces on the non-primary
monitors.

https://bugzilla.gnome.org/show_bug.cgi?id=609258
2011-03-17 14:13:55 +01:00
Jasper St. Pierre
a9505d0426 workspaceView: Make sure to scale the workspace proportionally
Commit 0207f1f29b landed a new
way of zooming, but was causing all sorts of window positioning
weirdness because the positions were supposed to be working against
a proportional workspace.

https://bugzilla.gnome.org/show_bug.cgi?id=644542
2011-03-15 13:28:38 -04:00
Adel Gadllah
29d473f2fa XDND: Fix dragMonitor leak in WorkspacesDisplay
WorkspacesDisplay removes its dragMonitor in _dragEnd, but
this was never called in when a xdnd drag ended causing
dragMonitors to stack up and handling events multiple times.

Fix that by making sure that _dragEnd is called when xdnd ends.

https://bugzilla.gnome.org/show_bug.cgi?id=644642
2011-03-14 22:03:33 +01:00
Alexander Larsson
df2f939f3a Start the workspace zoom out immediately on dnd cancel.
This means the snap-back animation happens at the same time as the zoom,
which looks much better.

https://bugzilla.gnome.org/show_bug.cgi?id=643786
2011-03-09 10:36:09 +01:00
Alexander Larsson
0207f1f29b Restructure the way we handle positioning zooming in Workspace
We currently show the workspace in the overview in a rectangle
with the same aspect ratio as the screen. Originally this was
probably done since it showed the desktop, but we don't do this
anymore, and the positioning of the windows in the overview is
strictly a grid, so its not in any way related to monitor geometry.
Additionally, in the multihead case the screen aspect ratio is
very different from the overview monitor geometry, so a lot of
space is lost.

So, instead we just fill the entire inner rectangle of the overview
with the workspace. However, the way the zoom into and out of the
workspace right now is by scaling the workspace so that it covers
the entire monitor. This cannot really work anymore when the workspace
is a different aspect ratio. Furthermore the coordinates of the
window clone actors are of two very different types in the "original
window" case and the "window in a slot case". One is screen relative,
the other is workspace relative. This makes it very hard to compute
the cost of window motion distance in computeWindowMotion.

In order to handle this we change the way workspace actor positioning
and scaling work. All workspace window clone actors are stored in
true screen coordingates, both the original window positions and the
in-a-slot ones. Global scaling of the workspace is never done, we
just reposition everything in both the initial zoom and when the
controls appear from the side.

There is one issue in the initial and final animations, which is that
the clip region we normally have for the workspacesView will limit the
animation of the clones to/from the original positions, so we disable
the clip region during these animations.

https://bugzilla.gnome.org/show_bug.cgi?id=643786
2011-03-09 10:36:02 +01:00
Sardem FF7
1b4cff7cdc workspaceThumbnails: Allow mousewheel scrolling
Allow the user to switch the active workspace by using
the mousewheel over the workspace thumbnails.

https://bugzilla.gnome.org/show_bug.cgi?id=642303
2011-02-18 18:12:18 +01:00
Owen W. Taylor
649ed3332f Fix background to animate with thumbnails
When we animating the scale for the thumbnails, the border and
background should wrap around the current size of the thumbails.
The technique that we are using to animate the scale breaks that
since we don't animate the overall size of the thumbnails box -
we just animate our child actors within the allocation.

To fix this, switch from drawing the background by packing in another
container to drawing the background with a separate actor that
is under the other actors and allocated by our custom logic.

https://bugzilla.gnome.org/show_bug.cgi?id=641881
2011-02-18 11:36:33 -05:00
Owen W. Taylor
fb8f3f19f7 workspacesView: Update zoom scale when controls are reallocated
The scale we zoom to in the "zoomed out" mode depends on the width of the
controls area. Once we rescale the workspaces dynamically, we'll need to
update the zoom scale as we add and remove workspaces.

https://bugzilla.gnome.org/show_bug.cgi?id=641879
2011-02-17 11:34:30 -05:00
Owen W. Taylor
85ecd1864f Use a fixed width for visible portion of workspace thumbnails
We will change the workspace thumbnail size as we get more thumbnails; it doesn't
really make sense to always show 1/5 of the thumbnails how big or small they are,
so instead show a CSS-configurable length.

https://bugzilla.gnome.org/show_bug.cgi?id=641879
2011-02-17 11:34:30 -05:00
Owen W. Taylor
630f0f0ac8 Improve allocation of workspace controls
Fix a bug in the computation of the zoomed-out scale and use a StBin
instead of an unnecessary StBoxLayout. Using the StBin will allow
correct width-for-height behavior for the controls.

https://bugzilla.gnome.org/show_bug.cgi?id=641879
2011-02-17 11:34:30 -05:00
Owen W. Taylor
ae5131f902 Make a separate class for workspace thumbnails box
Add WorkspaceThumbnail.ThumbnailsBox to handle managing the array
of workspace thumbnails; the logic will get more complex as we add
scaling and animation.

https://bugzilla.gnome.org/show_bug.cgi?id=641879
2011-02-17 11:34:30 -05:00
Adel Gadllah
c2ae95f912 AppWellMenu: Remove window filtering
Don't filter and highlight windows when opening the menu
as this turned out to be distracting and confusing.

https://bugzilla.gnome.org/show_bug.cgi?id=642189
2011-02-14 23:07:27 +01:00
Maxim Ermilov
aba6a85c56 workspace: don't show WindowOverlay during zoomFromOverview
https://bugzilla.gnome.org/show_bug.cgi?id=641533
2011-02-11 00:43:22 +03:00
Owen W. Taylor
fb71250dce Improve workspace controls slide-in positioning
Intead of using a St.Group and tweening the position of the controls
actor, use a St.GenericLayout and tween a Javascript property. This
allows us to more reliably track the height of the overall workspace
display and propagate it to the controls actor.

https://bugzilla.gnome.org/show_bug.cgi?id=640996
2011-02-08 19:43:21 -05:00
Owen W. Taylor
1b8bfda3b4 Avoid popping the workspace controls in and out at the end of DND
At the end of a drag operation, we would invoke the code to slide the
controls in (because we were no longer DND'ing and not hovering) and
then immediately afterwards invoke the code to slide it back out when
we got the ENTER event from the end of DND. While the immediately
overridden tween probably won't have any visible effect it's better
to avoid this, so wait to update the zoom state until BEFORE_REDRAW.

https://bugzilla.gnome.org/show_bug.cgi?id=640996
2011-02-08 19:43:21 -05:00
Owen W. Taylor
f038ce1c69 Remove now unnecessary workspace controls
With automatic workspace management, explicit controls to add and
remove workspaces are no longer necessary. We also can remove the
use of addWorkspace for middle-button-click on a launcher since
launching on the last empty workspace will do the right thing.

https://bugzilla.gnome.org/show_bug.cgi?id=640996
2011-02-08 19:43:20 -05:00
Owen W. Taylor
e6938ed06c Add automatic workspace management
Automatically add and remove workspaces so that the last workspace is
always empty and no workspaces are empty other than that workspace.

https://bugzilla.gnome.org/show_bug.cgi?id=640996
2011-02-08 19:43:20 -05:00
Owen W. Taylor
2d5133ad51 Don't activate newly added workspaces
With workspace thumbnails, we want to make workspace switching
something that happens largely under the users control, so don't
switch to newly added workspaces in the overview.

https://bugzilla.gnome.org/show_bug.cgi?id=640996
2011-02-08 19:43:20 -05:00
Owen W. Taylor
6514bc845f Add workspace thumbnails to the overview
Add workspace thumbnails to the workspace controls area. The user can
click on the thumbnail to switch workspaces and can also drag windows
out of the thumbnail to other workspaces.

https://bugzilla.gnome.org/show_bug.cgi?id=640996
2011-02-08 19:43:20 -05:00
Owen W. Taylor
eda12542c0 Move restacking handling from WorkspacesView to WorkspacesDisplay
Moving the base tracking of restacking to WorkspacesDisplay will allow
us to use it to update stacking in the workspace thumbnails as well as
in the main workspaces.

https://bugzilla.gnome.org/show_bug.cgi?id=640996
2011-02-08 19:43:20 -05:00
Owen W. Taylor
7c2aee3ac0 Use a single "zoomed out" view for both workspace controls hover and DND
Instead of having a separation between popping the controls out on hover
and zooming out for DND, always do both at once. This is necessary because
when we added workspace thumbnails the controls will get bigger, so we need
to make sure we zoom out far enough so that the windows don't overlap the
controls.

https://bugzilla.gnome.org/show_bug.cgi?id=640996
2011-02-08 19:43:20 -05:00
Owen W. Taylor
3c593fc056 Don't check for Workspaces.WindowClone for window drops
When checking the type of a DND source, instead of checking
'instanceof Workspaces.WindowClone' accept any actor with realWindow
and metaWindow properties. This will be useful to support a separate
type of actor dragged from workspace thumbnails.

https://bugzilla.gnome.org/show_bug.cgi?id=640996
2011-02-08 19:43:20 -05:00
Owen W. Taylor
9748cc264a Remove workspace indicators
Once we have workspace thumbnails in the overview, workspace indicators
will no longer be needed.

https://bugzilla.gnome.org/show_bug.cgi?id=640996
2011-02-08 19:43:20 -05:00
Owen W. Taylor
295d286161 Switch to a vertical layout for workspaces
The new plans for a row of workspace thumbnails on the right side of the
overview means that the mental model we present to the user will be
vertical, so switch the Metacity workspace layout to be vertical and
adjust the keybinding handling, animations, and workspace layout in
the overview to match.

(This commit does not change the workspace switching indicator pending
finalization of what we want to do with that - it still shows workspaces
arranged vertically.)

https://bugzilla.gnome.org/show_bug.cgi?id=640996
2011-02-08 19:43:20 -05:00
Maxim Ermilov
e3acaa05be Remove st_container_remove_all & rewrite st_container_destroy_children
1. Both functions leaked the nodes in priv->children
2. st_container_remove_all wasn't properly updating first_child and last_child
3. remove_all() is almost never right since it won't cause signal handlers
   on the children to be removed. In the rare cases where it might be needed
   the caller can simply use clutter_container_remove().
https://bugzilla.gnome.org/show_bug.cgi?id=640781
2011-02-01 23:41:21 +03:00
Maxim Ermilov
457c7adf59 workspacesView: dispose _scrollAdjustment in _onDestroy
https://bugzilla.gnome.org/show_bug.cgi?id=640781
2011-02-01 23:41:11 +03:00
Maxim Ermilov
8ebdb7f493 workspacesView: remove duplicate connection to same signal 2011-02-01 23:41:05 +03:00
Florian Müllner
d64d491f63 workspaces-view: Use overview swipe-scrolling
Remove the swipe-scrolling implementation in WorkspacesView and
use the new overview facility.

https://bugzilla.gnome.org/show_bug.cgi?id=635034
2011-01-24 02:59:39 +01:00
Adel Gadllah
ceedc7e32c Implement cross overview drag & drop
The gnome-panel allows the user to hover over a tasklist entry
while draging to activate a minimized or obscured window and drop onto it.

Implement a similar behaviour by allowing draging to the activities button or
the hotcorner (and thus opening the overview), which allows the user to
activate any window (even on different workspaces) as a drop target.

https://bugzilla.gnome.org/show_bug.cgi?id=601731
2011-01-05 23:19:56 +01:00
Florian Müllner
6f9ede569e workspace-indicators: Add hover indication
Scale up indicators on hover to hint at their clickability.

https://bugzilla.gnome.org/show_bug.cgi?id=634948
2010-11-29 16:35:54 +01:00
Florian Müllner
5fef9188c9 workspaces: Change handling of window-drag signals
Delegate the emission of the window-drag-begin/window-drag-end
signals to overview functions, as done already for other items.
This will enable objects to react to those signals without having
access to the workspace objects / the workspaces view.

https://bugzilla.gnome.org/show_bug.cgi?id=634948
2010-11-29 16:35:54 +01:00
Florian Müllner
d5d7d8a391 overview: Add ViewSelector to the overview
Add the view selector and adjust the positioning of elements in the
overview. Unlike the old dash, the view selector is made public to
indicate that extensions may add additional views or search providers.

https://bugzilla.gnome.org/show_bug.cgi?id=634948
2010-11-29 16:35:53 +01:00
Florian Müllner
7811632e6f workspaces: Rework workspace controls for the view selector
As workspaces will appear as a particular view in the view selector,
merge WorkspacesControls and WorkspacesManager to control workspaces
and related controls, so that a single actor can be added to the
selector instead of positioning the elements from the overview.

https://bugzilla.gnome.org/show_bug.cgi?id=634948
2010-11-29 16:35:53 +01:00
Florian Müllner
6c5c3bedbe workspaces-view: Swap workspace ordering for RTL locales
Make the first workspace the right-most one in RTL locales, as one
would expect. Update all dragging/scrolling functions to behave
correctly.

https://bugzilla.gnome.org/show_bug.cgi?id=634948
2010-11-29 16:35:53 +01:00
Florian Müllner
0942f50781 workspaces-view: Remove MosaicView
The new layout does no longer support view switching, so merge
GenericWorkspacesView and SingleView, and remove MosaicView.
Also rename or remove workspace properties and functions which
are now unused.
The grid will have a comeback with the new DND behavior.

https://bugzilla.gnome.org/show_bug.cgi?id=634948
2010-11-29 16:35:53 +01:00
Florian Müllner
2d2ac5b3f6 linear-view: Remove NewWorkspaceArea
As the button to add workspaces will move to the same position as
the new workspace drop area in drag mode, the latter is redundant
and can be removed.

https://bugzilla.gnome.org/show_bug.cgi?id=634948
2010-11-29 02:25:15 +01:00
Florian Müllner
e06b608b10 linear-view: Remove shadows when zoomed out
Overlaying inactive workspaces with a gradient to fade out the actors
does no longer work when re-using the normal desktop background. If
we keep the current DND behavior, we probably want to implement a real
fade effect - for now, just remove the visually disruptive shadows.

https://bugzilla.gnome.org/show_bug.cgi?id=634948
2010-11-29 02:25:15 +01:00
Florian Müllner
f24e567dc4 overview: Do not zoom the desktop background
While scaling the desktop background with the window previews represents
workspaces quite intuitively, the approach is not without problems.
As window previews in the overview behave quite differently to "real"
windows, the representation of workspaces as miniature versions of
"real" workspaces is flawed. The scaling also makes the transitions
to and from the overview much more visually expensive, without adding
much benefit.
Leaving the background in place provides more visual stability to the
transitions and emphasizes the distinctive behavior of elements in the
overview.

https://bugzilla.gnome.org/show_bug.cgi?id=634948
2010-11-29 02:25:15 +01:00