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
The code to draw the root background has now been moved into Mutter,
with added smarts to not draw obscured portions. Remove the old
version of the code and clone the Mutter background actor to draw
the background in the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=634836
Add a "gicon" property so that a GIcon can be used instead of an
icon name, while still getting icon recoloring from the theme.
Also include a compatibility wrapper in libshell until GJS has
support for interface static methods.
https://bugzilla.gnome.org/show_bug.cgi?id=622451
gnome-volume-control-applet was renamed to gnome-sound-applet when
moved to the control-center module, so we need to check for both names
when identifying the legacy status icon.
It was decided at GNOME Summit that we would remove the invisible
setting until we have a better story for how it works with chat
and other sharing/messaging applications. We'd also need to
figure out how it relates to busy.
The action is far less common than powering off. It is mostly
used for performing system updates so the update tool should
offer the option directly. Also, currently the Shut Down option
dialog offers Restart anyway. We would like to keep the number
of entries in this menu as limited (close to 7) as we can.
Switch from St.TextureCache.load_named_icon() to using St.Icon for named
icons. Along with the advantage of getting colorization right for symbolic
icons, this allows moving some icon sizes into the CSS.
In the CSS, the system status icon size is changed to be 1em (=16px for the
default font size), at the request of the artists. See bug 613448.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
gnome-settings-daemon has moved to GSettings for most settings, we
should adapt as well. The only remaining GConf key is for metacity
(visual bell).
https://bugzilla.gnome.org/show_bug.cgi?id=634693
Waiting for LookingGlass to close after calling St.set_slow_down_factor()
is annoying so divide the time for opening and closing by the slow-down
factor.
As popup menus now take focus for keyboard navigation, no application
is focused when activating the menu. Use the target application instead,
which keeps track of the application currently associated with the menu.
https://bugzilla.gnome.org/show_bug.cgi?id=634103
Action names sometimes unintentionally overlap with icon names, so
we should only create icon buttons if the message tray source requests
it. For the notification daemon, this is done by setting the
'action-icons' hint on the notification.
The previous notification server capability used to advertise this
feature, "x-gnome-icon-buttons", has been removed in favour of the
new capability described in the notification spec, "action-icons".
https://bugzilla.gnome.org/show_bug.cgi?id=624584
We shouldn't hide the tray as quickly if the user might have left it
unintentionally, such as when moving the mouse over to a different tray item or
using the scroll bar in the chat notification.
https://bugzilla.gnome.org/show_bug.cgi?id=630767
This way the new modal level is independent of whatever may have been
happening before. Fixes a problem with status menus becoming active
again from inside the app switcher, etc.
Tray icons replaced by a shell version are automatically filtered
and never make to the tray container, but when removed by the client
we were still trying to remove them from the tray, causing a warning.
https://bugzilla.gnome.org/show_bug.cgi?id=633028
Each menu is a focus manager group, but there is also some explicit
focus handling between non-hierarchically-related widgets. Eg, to move
between menus, or from a menubutton into its menu.
https://bugzilla.gnome.org/show_bug.cgi?id=621671
The constructor was setting this.active to reflect the switch state,
which is wrong; this.active indicates whether or not the item is
highlighted.
https://bugzilla.gnome.org/show_bug.cgi?id=621671
Adding a "PopupMenuRadioButtonItem" wouldn't work well, because we'll
need radio-button indicators on multiple different styles of menu
item. Also, the current design draws the indicator in the menu item's
padding, so it's sort of special anyway. So just add support at the
BaseMenuItem level.
Also, redo the menu/menuitem padding so that all the horizontal
padding is in the menu item, or else the indicator dot will show up in
the wrong spot.
https://bugzilla.gnome.org/show_bug.cgi?id=631193
