Currently we only connect to the 'notify::n-workspaces' signal the
first time the overview is shown, which means we will miss any
changes to the workspace layout in the meanwhile.
In particular, the decision of whether the workspace switcher should be
shown is taken before the dynamic workspace handling takes over, and is
thus based entirely on the value of the num-workspaces user preference
rather than the actual number of workspaces.
Just connect the signal in _init() (with the nice side-effect to make it
explicit that the signal handler won't ever be disconnected).
https://bugzilla.gnome.org/show_bug.cgi?id=673198
We seem to have a lot of code that does something along the lines of:
if (condition)
actor.show();
else
actor.hide();
ClutterActor already has such a thing for exactly this purpose: the 'visible'
property. Use it instead of the mess above.
https://bugzilla.gnome.org/show_bug.cgi?id=672272
If the user has their mouse over the workspace thumbnails while
entering the overview, it's more likely that it's a coincidence
that their mouse pointer is in the area. Avoid expanding the
thumbnails box in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=651092
When in overview, window labels flicker or are temporarily hidden on a
number of occasions - when simply clicking around the area the windows
are displayed in, dragging a window, sliding in the workspace list,
adding new workspaces etc. This patch makes the label for any window
visible at any given moment when in overview and the said window is
not being dragged around.
https://bugzilla.gnome.org/show_bug.cgi?id=644861
If workspaces-only-on-primary is false, swipe scrolling is now
broken with multiple monitors. To fix, let workspacesDisplay
handle swipe scrolling for all views.
https://bugzilla.gnome.org/show_bug.cgi?id=652580
If workspaces-only-on-primary is false, workspaces should be shown
on each monitor; rather than letting the existing workspaces span
the entire screen, manage one workspacesView per monitor (similar
to the extra workspaces in WorkspacesView when the setting is true).
https://bugzilla.gnome.org/show_bug.cgi?id=652580
Extra workspaces are special, in that they collect windows from
all workspaces for a particular monitor. This matches the default
behavior, but we need more than a single workspace per monitor if
workspaces-only-on-primary is false, so don't create the extra
workspaces in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=652580
WorkspacesDisplay was introduced to manage the workspace objects
and views; however, the overview still accesses the view held
by the workspacesDisplay directly, which is a bit odd.
Add some additional methods needed by the overview, and make the
view a private property.
https://bugzilla.gnome.org/show_bug.cgi?id=652580
The last patch in the sequence. Every place that was previously
setting prototype has been ported to Lang.Class, to make code more
concise and allow for better toString().
https://bugzilla.gnome.org/show_bug.cgi?id=664436
js2-mode is no longer developed and we recommend js-mode these days,
so switch the modelines to specify that, and make them consistent
across all files.
https://bugzilla.gnome.org/show_bug.cgi?id=660358
When workspace "previews" in the overview were just tiny gray
rectangles, it made sense to provide a way to move windows
directly between workspaces (by switching workspaces when dragging
a window to the corresponding screen edge). As the overview has
evolved however, the workspace switcher provides a good and
intuitive drop target already, so the alternative provided by the
screen edges is no longer necessary. As it also conflicts with
moving windows between monitors when using a vertical layout,
just remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=660838
Remove ShellGlobal's monitor-related methods, and have
Main.layoutManager provide that information instead. Move
Main._relayout() to LayoutManager, and have other objects connect to
the layout manager's 'monitors-changed' signal to know when the screen
geometry has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=636963
Sliding out the workspaces pager when starting a drag causes a lot
of motion. With the pager only hiding if workspaces are not used,
it is better to require to explicitly hover the workspaces sidebar
for the sliding.
https://bugzilla.gnome.org/show_bug.cgi?id=652730
After completing the overview transition, the workspace view is
clipped to avoid overlapping the search entry/view selector titles
while switching workspaces. For clipping, the view's position and
size was used, which works well assuming that the workspace pager
will start hidden or stay zoomed out while the overview is visible.
However, that assumption holds no longer true, as auto-hiding the
pager now depends on the number of workspaces, and thus may change
while in the overview. For instance, when starting with the pager
being visible, the clip area ends up being too small when moving
all windows to the first workspace (and thus triggering auto-hide).
As a fix, handle the clip rectangle separately from the view's
geometry, and set it always to the area the workspaces would
occupy with the pager hidden.
https://bugzilla.gnome.org/show_bug.cgi?id=653142
With commit 59a3e393f9 whether the workspace pager should autohide
now depends on the number of workspaces. As we only track changes
to the number of workspaces while the overview is visible, we miss
changes in "normal mode", i.e. when creating a new workspace by
moving a window with ctrl-alt-shift-arrow; as a result, the pager's
autohiding might be incorrect when entering the overview after that.
As a fix, keep tracking changes to the workspaces when the overview
is hidden and update the zoom options.
https://bugzilla.gnome.org/show_bug.cgi?id=653078
The purpose of autohiding the workspace pager on the right was to
avoid exposure of workspaces to users who are not using them.
However, for users who do use workspaces, the behavior limits the
purpose of the overview. To fix, always show the pager if more than
one workspace is actively used.
https://bugzilla.gnome.org/show_bug.cgi?id=652714
Currently the user has to find an empty spot in the workspace
to be able to launcha new instance of an app using dnd.
This is unnecessary hard, so just allow dropping on windows too.
https://bugzilla.gnome.org/show_bug.cgi?id=652079
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
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
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
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.
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
