It is not obvious that only the icon is clickable to activate the
default action - in fact, with the area being that tiny, many don't
even know that notifications can be clicked.
Just extend the clickable area to the whole notification.
https://bugzilla.gnome.org/show_bug.cgi?id=613932
Adds class PopupSwitchMenuItem, which is a two-state switch similar
to those in system status indicators mockups. Also adds class Switch,
which represents the switch itself, in case it is useful somewhere
else.
https://bugzilla.gnome.org/show_bug.cgi?id=621880
In addition to already grabbing focus in the summary notifications,
we also want to grab focus in the new notifications when the user
hovers over them and expands them.
The notifications that expand automatically will only get focus once
the user hovers over them. The notifications that don't expand will
never grab focus because they don't need it.
Make sure that we toggle the way we grab focus when switching between
the overview and the main mode. This is necessary because, unlike
summary notifications that pop down when the user moves between the two
modes, new notifications keep being shown as long as the user hovers
over them or until they time out.
https://bugzilla.gnome.org/show_bug.cgi?id=617224
Because clicking on the summary item to have it display its notification
is a more deliberate action than hovering, we can now grab focus in that
notification. This makes chat notifications in the summary more convenient
to use because you don't need to click on the text entry there.
We pop down the notification when the user clicks anywhere outside of it,
triggers the overview, or the run dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=617224
This ensures that the summary appears when we are showing a new
notification and switch to the overview at the same time.
Another effect of this patch is that the summary is shown if the
user moves the mouse to the bottom right corner while a notification
is being shown, which is ok.
This patch adds the method "removeMenu" to PopupMenuManager, to allow
for removal of menus after they're inserted. In order to do this, it
needs to store along with the menu all the relevant signal connections,
that are disconnected when the menu is removed.
Also adds a parameter "position" to "addMenu", so that menus can added
in arbitrary order (in particular to reintroduce those which were removed).
This patch is intended towards dynamic menu users, like extensions for
application lists, docks, sidebars showing recent documents or favourites,
as well as advanced system tray implementations.
https://bugzilla.gnome.org/show_bug.cgi?id=622730
In GSettings, a change notification is generated immediately from context of the _set() call.
In GConf, The "value_changed" signal is emitted whenever the server
notifies your client program that a value has changed in the database (100% NOT from context of the _set() call).
https://bugzilla.gnome.org/show_bug.cgi?id=624296
We need to only connect to 'action-invoked' on notification once
when the notification is created. We were accumulating callbacks
otherwise, which resulted, for example, in the Rhythmbox skipping
through multiple tracks when the 'Next' button was hit.
Always be sure to destroy the notification when its source is
destroyed, which is the case when an action is invoked.
Note that in the future, we might not want to destroy the source
for some notifications when an action is invoked. For example,
it makes sense to keep Rhythmbox in the tray while the music is
playing and allow the user to use the controls from the summary
notification too.
Solved by splitting the base class (PanelMenuButton) in a separate
module, ui.panelMenu, which is meant to hold also other reusable
button classes.
https://bugzilla.gnome.org/show_bug.cgi?id=621705
The spinner animation moving from left-to-right to indicate a starting
application changes its direction on reaching the end of the movement.
Instead, keep the spinner at the right of the app name until startup
has finished.
https://bugzilla.gnome.org/show_bug.cgi?id=623687
We should not be showing the cursor in the search entry in the overview
if the user's input will be appearing elsewhere, such as in the run dialog,
in the Looking Glass console, or in the notification's response field.
"text-align" allows setting the alignment of text, with respect to
other lines and allocated space, without requiring a reference to
the ClutterText (which is private for most widgets).
If not specified, all text is left-aligned.
https://bugzilla.gnome.org/show_bug.cgi?id=622447
This is part of the design update for the message tray.
Source now takes an extra argument called 'title'.
All expanded message tray items are same width, which is determined by
the width of the item with the longest title, up to MAX_SOURCE_TITLE_WIDTH.
This is done so that items don't move around too much when one is expanded
and another one is collapsed.
https://bugzilla.gnome.org/show_bug.cgi?id=617224
While the contents of the left and right group in the panel are
flipped correctly, the groups themselves have to be swapped as
well. The location of the hot corner has to be corrected as well.
https://bugzilla.gnome.org/show_bug.cgi?id=622243
It has probably crossed the line to evil by a mile or so, but here
it is: a Tweener.slowDownFactor replacement used by all animations
without exception.
While at it, update Tweener to use the new setTimeScale() upstream
function instead of adjusting the timeline directly.
https://bugzilla.gnome.org/show_bug.cgi?id=622249
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
The shell design says that upon launching an application,
no X window should have focus, and we should display an
animated launching indicator.
Implement this by in panel.js, keep track of the last started
application. If there isn't currently an X focus, show an animation
for the last starting application.
https://bugzilla.gnome.org/show_bug.cgi?id=598349
Canonical replaced status icons with libindicator based solutions,
which don't work in the shell environment. Force the distro-patched
versions to fall-back to upstream.
https://bugzilla.gnome.org/show_bug.cgi?id=621382
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
Sometimes it is desirable to be able to react to DND events that
happen outside a target actor's bounds, e.g. to implement reactive
screen edges. Add a simple interface which allows to hook into
drag motion and drop handling without jumping through ugly hoops.
https://bugzilla.gnome.org/show_bug.cgi?id=620504
The design calls for item to not appear abruptly, but not too slow
either - 100ms seems to be a good sweet spot for elements which are
supposed to appear "instantly".
Add a fade effect to the alt-tab popup and set the timings for other
fade effects to 100ms.
https://bugzilla.gnome.org/show_bug.cgi?id=621247
We query the transformed position and size of the popupMenu before actually showing
it which results into wrong positioning, when displaying it for the first time.
In case of the statusMenu this can even result into it being offscreen.
https://bugzilla.gnome.org/show_bug.cgi?id=621385
Add _st_actor_contains() in st-private for use within St, and
monkey-patch in a Clutter.Actor.contains() for use by javascript, and
then replace all the duplicate implementations with one or the other
of those.
https://bugzilla.gnome.org/show_bug.cgi?id=621197
Currently, we use 'gtk-yes', 'gtk-no' and 'gtk-media-pause' as
user status icons. It seems more logical to use the dedicated
icons from gnome-icon-theme instead.
https://bugzilla.gnome.org/show_bug.cgi?id=620374
First, we were passing an incorrect timestamp to
meta_display_focus_the_no_focus_window - fix that.
The invocation of set_focus_app to the started app there couldn't
really work, because (if the above call had worked) we'd get the
X reply *after* the started app.
What we need to untangle here is the distinction that's now made in
ShellApp between _STATE_STARTING and _STATE_RUNNING. A nice way to
start doing this is to rebase ShellWindowTracker to only be concerned
with app states. Concretely, the current "has windows implies
running" logic now lives just inside shell-app.c.
Rename the app-running-changed signal to be app-state-changed. This
will ultimately be useful so that inside the panel, we can track
the last started app.
https://bugzilla.gnome.org/show_bug.cgi?id=620899
Currently the workspaceSwitcher does not take the screen size into account
which could result into overflowing the screen.
Fix that but using Shell.GenericContainer instead of St.BoxLayout which takes
the monitor size into account when allocating.
https://bugzilla.gnome.org/show_bug.cgi?id=620404
Before adding a new entry to the history, we check that it does not
match the previous entry to cut down the number of duplicate entries.
Part of that condition is a check for a history length greater zero
to avoid an illegal negative index, with the side effect that nothing
is ever added while the history is empty.
https://bugzilla.gnome.org/show_bug.cgi?id=621123
