We need to do a better job of indicating login process. This can
sometimes take a few seconds (particularly if you get your password
wrong): we need to give better feedback of what's going on.
This adds a spinner next to the login button if the authorization takes
some time.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
The login dialog had these issues:
- the entry was not really disabled, you could still edit text
- the sensitivity state was not reset on verification failure
- the session list was not disabled
The unlock dialog had these issues:
- "Login as another user..." was not insensitive
- redundant password char setting, overwriting the one given by the
question
The entry insensitive style was also wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
The "Sign In" button of the login dialog has its look disabled when the
entry is empty, but it can still be triggered by the Enter key.
This fixes the modal dialog so it does not trigger the action of an
insensitive button, and also means we do not need to connect to the
"activate" signal of the entry anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
Make the button layout public for callers to be able to have more
control over like adding custom widgets. Also, the clearButtons and
addButton methods are added as convenience for the most frequent usage.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
Open a modal dialog, try to open the message tray -> no effect, the message
tray is blocked by the dialog.
Close the dialog, try to open the message tray by pointer -> still
no effect, because the old timeout id was not cleared the first time,
so the dwell callback thinks the tray is about to open.
https://bugzilla.gnome.org/show_bug.cgi?id=688750
Windows in the overview should be highlighted when hovered, to indicate
they are an active target.
Based on a patch by Marc Plano-Lesay <marc.planolesay@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=665310
Setting auto-register to true launches the initial registration, and will
afterwards re-launch the agent registration if NetworkManager gets restarted.
When the component is disabled we'll first disable auto-registration, and only
then request to unregister.
https://bugzilla.gnome.org/show_bug.cgi?id=688379
The top panel and message tray icons were by default a gnome foot and
are replaced by better ones. The applications icon is now using the
symbolic apps icon of the dash, and the windows icon is also improved.
https://bugzilla.gnome.org/show_bug.cgi?id=641303
MessageTray tweens both opacity and y to hide or show _notificationWidget,
but only y when expanding it. This means that an existing tween to hide
the notification will continue running, clearing the notification state.
If the hiding one completes before the showing one, the onComplete handler
will throw an exception (because the notification was nullified) and
therefore break the state tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=683986
We where not setting a duration for the frames, which caused the resulting videos to
have a broken header.
Fix that by making the source a live source and setting the correct frame duration.
https://bugzilla.gnome.org/show_bug.cgi?id=688487
Instead of adding search providers to the system as we find them, wait
until we loaded information from all the directories, and then add all
providers at once.
This will be useful when we will sort the providers information
according to the sort order saved in GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=687491
The AnimatedIcon does not have an API for controlling the animation but
relies on the :visible property changes to start and stop a timeout used
to update the frame.
This has the inconvenient of having a side effect when visible is set to
true multiple times, and is not really the API expected from such
component. Also, there is a race if it is displayed before the images
are loaded: there is no child yet and thus we get this._frame = NaN
which leads to a crash.
Switch to a play/stop API instead, and add a load event callback to the
TextureCache.load_slice_image to exactly know when we can start using
the images.
https://bugzilla.gnome.org/show_bug.cgi?id=687583
As we now allow the ctrl-alt-tab popup on the lock screen, it should
be possible to navigate back from the top bar, so add the corresponding
elements to the switcher.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
The original condition the property was based on was added to make
the a11y switcher available in the login screen, though it did never
work properly - after popping up the switcher, additional tab key
presses were ignored. As we are now able to filter bindings much more
selectively, we can simplify the check and drop the sessionMode property.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
With the new flexible system in place, there's no point explicitly
hardcoding some built-in keybindings; just use the generic mechanism
for everything.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
Currently we hardcode the set of keybindings that are available in the
overview; add a generic mechanism to specify in which KeybindingModes
a keybinding should be available.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
For now we just use it to assign an identifier to modal modes in
which we want to allow some keybindings, but we don't use it for
any actual filtering; we'll start doing this shortly.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
We are currently using a hack to allow a select set of keybindings
in the overview. Implement the new MetaPlugin keybinding_filter
hook, which provides a cleaner way to achieve the same.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
Remove section titles for ethernet and mobile broadband, and replace
them with device status items that recognize if multiple devices are
installed in the same section, and if so automatically disambiguate.
https://bugzilla.gnome.org/show_bug.cgi?id=677142
It appears to be somewhat common for st_widget_style_changed() to be
called when no style-relevant attributes have, in fact, changed. Now that
we cache theme nodes, we're likely to get the same theme node back from
the cache. If we do, we don't need to waste time asking whether its
geometry and painting are equal to itself: we can just note that nothing
really changed and get on with our lives.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687465
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
If you copy a theme node's paint state into itself, it should be an
inexpensive no-op. What actually happened was that we destroyed the
old paint state, re-initialized to blank, then copied the blank state
back into itself. In the process, we lost (for instance) the textures
for rounded corners.
Until I introduced the texture cache, this never actually happened,
because when st_widget_recompute_style() calls st_widget_get_theme_node(),
we'd always get a fresh theme node. Now, we get a theme node T back
from the cache, notice that paint_equal(T, T) is true, short-circuit
slightly by copying its drawing state into itself, and destroy drawing
state that we still needed.
I'm going to fix this in recompute_style() too, but as a general
principle, self-assignment ought to be harmless.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687465
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
