Commit Graph

151 Commits

Author SHA1 Message Date
Cosimo Cecchi
a0e340f06e workspaces-view: make sure to add spacing between view and controls
The thumbnail controls are not a separate actor in the overview group
yet, so we need to ensure a spacing between them and the workspaces
view.
Instead of exporting the overview spacing, just add a temporary style
class to the workspaces-view actor for it. It will be removed in the
future when we change the layout of overview elements.

https://bugzilla.gnome.org/show_bug.cgi?id=690174
2012-12-15 14:13:36 -05:00
Tanner Doshier
04d68c6e36 overview: overview as boxlayouts
https://bugzilla.gnome.org/show_bug.cgi?id=682286
2012-12-13 09:38:45 -05:00
Florian Müllner
6eb05af306 workspacesView: Restore activation of (empty) workspaces
Clicking empty workspaces to leave the overview was broken by
commit 830e701d13, restore the previous behavior.

https://bugzilla.gnome.org/show_bug.cgi?id=689552
2012-12-03 19:40:29 +01:00
Jasper St. Pierre
830e701d13 workspacesView: Don't use the overview swipe scrolling system
Switch to a ClutterPanAction instead too.

https://bugzilla.gnome.org/show_bug.cgi?id=689062
2012-11-30 16:03:34 -05:00
Jasper St. Pierre
57d9e7d5aa workspacesView: Clean up scroll code a bit
There's no code path that results in us not animating.

https://bugzilla.gnome.org/show_bug.cgi?id=689062
2012-11-30 16:03:34 -05:00
Jasper St. Pierre
bb88265d78 workspacesViews: Update new padding rules for workspacesOnlyOnPrimary
Tim Lunn fixed this for the !workspacesOnlyOnPrimary case, but not the
other.
2012-11-27 17:46:53 -05:00
Tim Lunn
f63fceb2ea workspacesDisplay: add spacing around the workspacesView
On additional monitors the workspacesView takes up the entire monitor
and in some cases windows in overview can end up hard against the
edge of the monitor.

https://bugzilla.gnome.org/show_bug.cgi?id=688133
2012-11-21 20:02:38 +01:00
Jasper St. Pierre
96556eb959 workspacesView: Add some more spacing between window and workspace thumbs
https://bugzilla.gnome.org/show_bug.cgi?id=582650
2012-10-23 15:12:45 -04:00
Jasper St. Pierre
d7929a2340 workspacesView: Don't conform to aspect ratio
We want the window picker to use the full height of the area it's given.

https://bugzilla.gnome.org/show_bug.cgi?id=582650
2012-10-23 15:12:45 -04:00
Florian Müllner
a2b1946b01 workspacesView: Fix updating when number of workspaces changes
Ouch. This went unnoticed for a long time as by default (using
dynamic workspaces) only one workspace is added at a time, which
happens to work fine.

https://bugzilla.gnome.org/show_bug.cgi?id=686487
2012-10-23 18:27:07 +02:00
Florian Müllner
96a80f7ba0 workspacesView: Fix typo
We want to check for a setting, not the existence of a function.

https://bugzilla.gnome.org/show_bug.cgi?id=686487
2012-10-23 18:27:07 +02:00
Jasper St. Pierre
a0e0cc1038 workspacesView: Simplify extraWorkspaces handling
https://bugzilla.gnome.org/show_bug.cgi?id=686002
2012-10-21 18:53:48 -04:00
Seif Lotfy
78f6dec73b workspacesView: Don't show workspace switcher when it doesn't make sense
Hide workspace switcher if dynamic workspaces is disabled and number of
workspaces is set to one only, since the user is bound to only one workspace
and showing the switcher is redundant.

Signed-off-by: Seif Lotfy <seif@lotfy.com>
2012-10-20 01:39:52 +02:00
Tim Lunn
046067565a workspace: fix typo in removeThumbnails.
https://bugzilla.gnome.org/show_bug.cgi?id=684869
2012-10-12 17:44:10 -04:00
Jasper St. Pierre
efc128e681 workspacesView: Refactor thumb zooming out code
https://bugzilla.gnome.org/show_bug.cgi?id=582650
2012-08-23 23:36:25 -03:00
Florian Müllner
e92a6b3c6c workspacesView: Avoid an unnecessary animation
Currently we animate scrolling to the active workspace both when
the number of workspaces changed and after changing the active
workspace. So in case we don't actually change workspace, this
results in an unnecessary animation that may even have unwanted
side effects: when done during the overview transition (e.g. in
the case of opening and activating a window on an empty workspace),
non-active workspaces become visible during the transition.
To fix, don't scroll to the active workspace when the number of
workspaces changes and rely on the 'switch-workspace' signal being
emitted as necessary.

https://bugzilla.gnome.org/show_bug.cgi?id=682002
2012-08-22 16:26:59 +02:00
Jasper St. Pierre
dd80f39049 js: Spurious fixes for cases where we pass extra arguments
https://bugzilla.gnome.org/show_bug.cgi?id=680216
2012-07-19 11:01:03 -04:00
Giovanni Campagna
de72065a4a WorkspaceSwitcher: simplify code for handling keybindings
Most of code implementing workspace switches was repeated with
minor differences on each direction. Instead, consolidate it
and use the new meta_workspace_get_neighbor.

https://bugzilla.gnome.org/show_bug.cgi?id=674104
2012-06-27 19:35:37 +02:00
Florian Müllner
76005f5adf workspacesDisplay: Connect to 'notify::n-workspaces' early
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
2012-06-01 17:34:48 +02:00
Jasper St. Pierre
723a1c843a Refactor show()/hide() sequences
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
2012-05-02 12:43:58 -04:00
Joost Verdoorn
4f87e86603 overview: Don't show workspaces when entering the overview
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
2012-03-16 17:19:48 +01:00
Jasper St. Pierre
15f881f967 st: Remove custom text direction stuff
Clutter has its own built-in system for managing text directions, like GTK+.
Convert over to use this.

https://bugzilla.gnome.org/show_bug.cgi?id=670034
2012-02-28 08:14:06 -05:00
Jasper St. Pierre
bb862e20c0 st: Remove st-group
Now that ClutterActor/StWidget is concrete, we don't need it.

https://bugzilla.gnome.org/show_bug.cgi?id=670034
2012-02-28 08:14:06 -05:00
Zan Dobersek
102f2a91f9 Make the window labels visible at all times
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
2011-12-08 14:15:13 +00:00
Florian Müllner
a634f25d30 workspaces-view: Handle swipe scolling in workspacesDisplay
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
2011-12-01 17:55:13 +01:00
Florian Müllner
26df6cf35c workspaces-display: Implement workspaces on non-primary monitors
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
2011-12-01 17:55:13 +01:00
Florian Müllner
84dde8e9bb workspaces-view: Don't create extra workspaces unconditionally
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
2011-12-01 17:55:13 +01:00
Florian Müllner
f2c79be11a workspaces-display: Make workspacesView private
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
2011-12-01 17:55:13 +01:00
Giovanni Campagna
17c46c2452 Port everything to class framework
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
2011-11-24 09:50:04 +01:00
Dan Winship
75b824d032 *.js: Make emacs modelines consistent
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
2011-10-11 08:05:12 -04:00
Florian Müllner
28c3e0693e workspaces-view: Remove window dnd between workspaces
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
2011-10-04 20:30:20 +02:00
Jasper St. Pierre
3aa904da0a workspacesView: Only connect to nWorkspacesChanged after we've lazily inited
We lazily init this._workspaces, so we shouldn't try to run any code that uses
it until after it's been created.

https://bugzilla.gnome.org/show_bug.cgi?id=658007
2011-09-01 16:25:03 -04:00
Dan Winship
67b4f9b3a9 workspacesView: belatedly remove an unused variable 2011-08-04 13:37:57 -04:00
Dan Winship
64b2b4a7d4 layout: new file handling shell layout
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
2011-07-06 08:38:35 -04:00
Florian Müllner
ed8acefc00 workspaces-display: Don't slide out pager on drag-begin
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
2011-06-27 21:39:28 +02:00
Florian Müllner
737f395d6c dnd: Rename DND.removeMonitor() to DND.removeDragMonitor()
DND.addDragMonitor() and DND.removeMonitor() are inconsistently
named, so rename the latter.

https://bugzilla.gnome.org/show_bug.cgi?id=652730
2011-06-27 21:39:28 +02:00
Florian Müllner
6ce07abf50 workspaces-view: Handle clip rectangle separately
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
2011-06-27 15:22:23 +02:00
Florian Müllner
52a342300a workspaces-view: Always update zoom on workspace changes
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
2011-06-21 22:23:55 +02:00
Florian Müllner
59a3e393f9 workspaces-display: Improve pager autohide
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
2011-06-18 00:10:43 +02:00
Adel Gadllah
96dca48b3b overview: Allow dropping icons on windows
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
2011-06-13 22:30:52 +02:00
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