Since we are keeping a current pointer position anyways, we
don't have to continually call global.get_pointer() which is
a round trip to the magnifier; make ZoomRegion simply fetch
a current position stored in the Magnifier object.
https://bugzilla.gnome.org/show_bug.cgi?id=633553
Change the proportional algorithm so stop moving the zoom region
when cursor is in a "padding region" at the edge of the screen.
(The padding region is a 10th of the screen at 2x zoom, and smaller
for higher zooms.)
Based on earlier versions from Jon McCann and Florian Muellner.
https://bugzilla.gnome.org/show_bug.cgi?id=629950
This basic point of this change is to avoid always creating a
hidden Clutter.Clone actor for the default present-but-not-active
zoom region. The position of the viewport and region of interest
are now stored in member variables, and the actors are only created
and updated when the region is active.
Other significant changes:
* Unused public functions are removed or made private
* The mouse tracking position is immediately updated when options
like the zoom are changed, not just on the next mouse motion.
* ZoomRegion.setROI() now updates the zoom, not just the position;
a FIXME is added to the D-Bus interface for a place where the
D-Bus interface contains duplicate possibly conflicting information
* Lens-mode is now only effectively off when the magnifier is
fullscreen, instead of actually modifying the member variable;
this makes things work properly when changing out of full-screen
mode.
* When the clamping to screen edges is turned on, we now immediately
clamp.
* The handling of setting the position to fullscreen as compared
to just setting the viewport to fullscreen is untangled.
https://bugzilla.gnome.org/show_bug.cgi?id=633582
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.
