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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
The layout of recent mockups occupies the space previously reserved
for the info bar with the view selector. As the bar's purpose is
mainly to provide the user with feedback, it makes sense to use the
existing message tray facility instead of moving the bar elsewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=634948
The scrollbar is the main culprit for cluttered controls in the
linear view - all its functionality is already provided by the
workspace indicators, so it is save to remove the scrollbar in
order to clean up the interface.
https://bugzilla.gnome.org/show_bug.cgi?id=634948
MutterWindow and MutterPlugin have been renamed to MetaWindowActor
and MetaPlugin, mutter_plugin_list_windows() to
meta_plugin_list_window_actors(). Adapt to those changes.
https://bugzilla.gnome.org/show_bug.cgi?id=632500
Although within St itself there are situations where the semantics of
these functions (return TRUE or FALSE and return the actual value in
an out parameter) is useful, it's mostly just annoying at the
application level, where you generally know that the CSS property is
going to specified, and there is no especially sane fallback if it's
not.
So rename the current methods to lookup_color, lookup_double, and
lookup_length, and add new get_color, get_double, and get_length
methods that don't take an "inherit" parameter, and return their
values directly. (Well, except for get_color, due to the lack of (out
caller-allocates) in gjs.)
And update the code to use either the old or new methods as appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=632590
Return a DND.DragMotionResult constant from delegate _handleDragMotion
methods as well as the existing return value from the drag monitor method dragMotion.
https://bugzilla.gnome.org/show_bug.cgi?id=607821
Use GSettings for all Shell configuration. GConf is kept to read
configuration from external programs (Metacity, Nautilus and Magnifier),
but ShellGConf is removed because it's mostly useless for the few calls
we still have. Also get rid of unused GConf code in ShellAppSystem.
A basic GConf schema is still used to override Metacity defaults and
configure Magnifier in a system-wide fashion. GConf is also used as
GSettings backend via the GSETTINGS_BACKEND environment variable.
All of this will be removed when these programs have been ported
to GSettings and able to use dconf.
GLib 2.25.9 is required. Schemas are converted to the new XML format,
and compiled at build time in data/ so that the Shell can be run from
the source tree. This also requires setting the GSETTINGS_SCHEMA_DIR
environment variable both when running installed or from source tree,
in src/gnome-shell.in and src/gnome-shell-clock-preferences.in.
https://bugzilla.gnome.org/show_bug.cgi?id=617917
While zoomed out in drag mode, the workspaces at the left and right
of the active workspace are slightly transparent - when switching
workspaces, one of the transparent workspaces becomes the new active
workspace, but its opacity is not updated.
https://bugzilla.gnome.org/show_bug.cgi?id=620940
When in drag mode, the linear view raises a transparent actor
covering the entire stage. That way the view can handle events
like dragging items to the screen edges, but in order to not
disable any drop target not handled by itself, it duplicates
huge amounts of code from dnd.js.
Cleanup that mess by using the new drag monitoring support.
https://bugzilla.gnome.org/show_bug.cgi?id=620504
Currently we don't get any drop events for dual screen modes with a screen
at the right, and behave weird by hardcoding the screen size and 0 as drag
edges.
Fix that by spawning the drop group over the whole stage and take the primary monitors position and size into account in _handleDragOver.
https://bugzilla.gnome.org/show_bug.cgi?id=620378
When dragging windows in linear view, the workspace zooms out to
allow moving the window to other workspaces. Enable the same
behaviour for items dragged from the dash.
https://bugzilla.gnome.org/show_bug.cgi?id=618055
While zoomed out, the workspaces view's drop target spans the entire
monitor to implement reactive screen edges. When a drop event is not
handled by the view, an attempt is made to pass it on down the stack,
but it doesn't work properly. Fix it by iterating the target's parents
as well.
Also improve the code which translates dnd coordinates to target
positions.
https://bugzilla.gnome.org/show_bug.cgi?id=619203
Currently, the drag and drop code assumes that on a successful drop
the target will either consume the drag actor or that it is otherwise
OK to destroy the actor.
As the drag behavior for window preview was changed, dropping a preview
on the dash now results in the preview being swallowed - to fix, add an
option to restore the actor in case of a successful drop as well.
https://bugzilla.gnome.org/show_bug.cgi?id=619203
There are some places in the code where we use both fixed positioning
and CSS. Currently we use either a combination of ClutterGroup and StBin,
or we uses StBoxLayout with fixed positioning. Replace those with the new
StGroup container.
https://bugzilla.gnome.org/show_bug.cgi?id=613907
This is our convention.
The only exceptions are double quotes for words in comments that give
them a special meaning (though beware that these quotes are not truly
necessary most of the time) and double quotes that need to be a part
of the output string.
It was previously possible to add a workspace above the maximum workspaces
limit by dragging an item to the "add workspace" button or using the middle
mouse button click.
Provide the user with feedback in the info bar when it is not possible to create
a new workspace or remove the current workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=591645
This ensures that we launch the new instance of an application on the newly
added workspace in the grid view, in which we don't make the newly added
workspace active by default.
https://bugzilla.gnome.org/show_bug.cgi?id=591645
Currently there is no way for the user to cancel a workspace drag action,
which means the user has to complete the drag action before and move back
to the other workspace manually afterwards.
So cancel the drag action when the user stops.
https://bugzilla.gnome.org/show_bug.cgi?id=618062
