The magnifier should be enabled/disabled via the appropriate
GSettings key - otherwise the setting gets out of sync with the
actual state of the magnifier.
https://bugzilla.gnome.org/show_bug.cgi?id=636151
The popup menus of application icons in both the dash and the app view
are positioned on the right of the icon. In the case of the dash this
results in the menu being displayed off-screen in RTL locales, so move it
to the opposite side instead.
https://bugzilla.gnome.org/show_bug.cgi?id=635645
In some circumstances, a boxpointer would draw itself with the arrow
partially overlapping the rounded corner, causing things to not line
up correctly. Don't do that.
And while we're at it, don't draw the pointer very very close to the
corner either, since it looks odd if the corner flows directly into
the arrow.
https://bugzilla.gnome.org/show_bug.cgi?id=635393
Show a positional indicator where a new favorite will be added and
make the favorites re-orderable. Also allow the removal of favorites
using drag-and-drop according to the mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=634948
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
Current mockups display all search results as icons as used by
application results, so change the default result display to use
iconGrid/BaseIcon. Remove the custom application results display,
as it is no longer needed.
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
Being no longer an independent menu pane, both the toggle() and
close() functions are no longer needed, and the view's structure
can be simplified a bit.
Also update the style to fit into the view selector.
https://bugzilla.gnome.org/show_bug.cgi?id=634948
The view selector should only deal with view switching, so move the
logic to deal with search (find-as-you-type, cancelling a search,
navigating/activating results) into the SearchTab.
https://bugzilla.gnome.org/show_bug.cgi?id=634948
The view selector is a tabbed interface with a search entry. Starting
a search switches focus to the results' tab, ending a search moves the
focus back to the previously selected tab. Activating a normal tab
while a search is active cancels the search.
https://bugzilla.gnome.org/show_bug.cgi?id=634948
With the new layout, search results will be displayed in an independent
view like window previews, applications and possible future additions;
it does not make much sense keeping it with the switching logic, so move
the code to its own file.
Also remove the dash-prefix from the relevant style classes.
https://bugzilla.gnome.org/show_bug.cgi?id=634948
The new dash implementation is a single-column vertical sidebar,
whose items are scaled dynamically to fit the available height.
If the height is still exceeded after scaling down to a minimum
item size, excess items are cut off.
The now unused old dash implementation is renamed to OldDash, as
its code will be used as a base for the new view selector element.
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
When the last message is older than SCROLLBACK_IMMEDIATE_TIME (1
minutes), show a timestamp in the middle, indicating the time it
was sent.
Use the same style for presence changes, but show them on the left.
https://bugzilla.gnome.org/show_bug.cgi?id=617228
NotificationDaemon-based notifications have markup in the banner/body,
but Telepathy-based notifications don't. (Eg, an XMPP message
containing "<b>foo</b>" should show up angle brackets and all, not as
bold.) Fix MessageTray.Notification to allow explicitly specifying
where there should and shouldn't be markup, and use that
appropriately.
https://bugzilla.gnome.org/show_bug.cgi?id=610219
According to the HIG we should use ellipsis when:
"Label the menu item with a trailing ellipsis ("...") only if the command requires further
input from the user before it can be performed. Do not add an ellipsis to items that only
present a confirmation dialog (such as Delete), or that do not require further input
(such as Properties, Preferences or About)"
So adjust the use of ellipsis to match that.
Pointed out by Michael Monreal.
We updated the normal devices part, but we forgot the part about
the primary device (possibly because it is not reported as such
in case it is fully charged). Update that as well, to avoid showing
weird GIcon serializations.
https://bugzilla.gnome.org/show_bug.cgi?id=635288
Reimplement UI without any indication of percentage or mutedness,
and whitout switches. The only interaction point is slider, but
it still supports mute changing for applications that track it,
and will react appropriately to external changes.
https://bugzilla.gnome.org/show_bug.cgi?id=634329
If the drag actor is destroyed as part of a drag target accepting it,
we were not calling ungrabEvents, meaning the mouse/keyboard remained
grabbed until you clicked somewhere to cancel it.
This fixes that without trying to improve the extremely confusing
control flow...
https://bugzilla.gnome.org/show_bug.cgi?id=635278
Previously, when snapping back a drag actor, we moved it back to its
original stage-relative position and scale. This worked fine if its
parent was still in the same place it was when the drag started, but
failed in cases like the linear workspace layout window drag-and-drop,
where dragging a window would "zoom out" its parent workspace, causing
the snapback to send it to the wrong place.
Fix this by instead snapping the actor back to "where the actor would
have been right now if it were still at its original scale and
position within its original parent actor" rather than "where it was
before the drag started"
https://bugzilla.gnome.org/show_bug.cgi?id=635272
Instead of hiding the drag actor temporarily to determine the actor
beneath it, make it invisible to picks while dragging using the new
shell_util_set_hidden_from_pick().
https://bugzilla.gnome.org/show_bug.cgi?id=634560
