This is necessary for child popups in menus, e.g. while in a combo box,
clicking outside of the user menu should drop the entire menu, but
clicking on the user menu itself should only drop the combo box.
I have no idea why we used 'event' rather than 'captured-event' before.
'event' has some really strange quirks that came up when porting PopupMenu
to the GrabHelper
If the user is just pushing their mouse along the barrier's edge, rather
than pushing down onto the barrier, we shouldn't show the tray. Do this
by keeping track of the distance traveled perpendicular to the barrier,
and releasing the accumulated pressure if we pass a threshold.
These are sent by the X server and have large deltas. They really
should be filtered out by Clutter (or the X server) somehow, but we
don't have the means to do that yet.
https://bugzilla.gnome.org/show_bug.cgi?id=687573
The code here before was added as dummy code to satisfy an error
in the missing switch, and wasn't ever tested due to the lack of XI2
in mutter. Use the same math as GtkRange does to calculate scroll bar
positions from raw XI2 deltas to allow for proper smooth scrolling.
https://bugzilla.gnome.org/show_bug.cgi?id=687573
MessageTray._tween sets the state variable to the in-progress value,
so it must be sure that at the end of the animation the value will
be the corresponding final and nothing else will happen in between.
https://bugzilla.gnome.org/show_bug.cgi?id=683986
Message tray: modify bubble scrollview notification padding to
have the same padding at right, bottom, top and left since
having different padding make scrollbar looks missaligned.
Also adjust border radius of bubble to not clash the scrollbar.
https://bugzilla.gnome.org/show_bug.cgi?id=688393
Since the introduction of overlay hover borders, there has a been
a timing disconnection between hiding the border and button, and
this creates noise and reduces the effect of the window+overlay
as a single unit.
Solve that by animating the close button too, so that the two actors
are shown and hidden always at the same time.
Also, consolidate the code to make it clear to future authors that
those two items need to stay coordinated.
https://bugzilla.gnome.org/show_bug.cgi?id=688966
Turns out that tweener has a very complex logic to decide when a new
tween on the same properties overrides completely the old, and unfortunately
what we were doing was not enough in all cases.
Just be explicit, and don't let anything else mess with the state.
https://bugzilla.gnome.org/show_bug.cgi?id=688895
On additional monitors the workspacesView takes up the entire monitor
and in some cases windows in overview can end up hard against the
edge of the monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=688133
The panel should change appearance according to the sessionMode,
so add a new panelStyle sessionMode property which allows to
specify a mode specific style class for the panel actors.
https://bugzilla.gnome.org/show_bug.cgi?id=684573
The panel corners overlap the panel in order to hide the underline
used for active buttons where it is supposed to arc downwards
following the roundness of the corner.
Unfortunately this prevents us from using a transparent panel background,
as the overlapped area ends up with the wrong transparency. Work around
this limitation by only overlapping the panel if there is a visible
border.
https://bugzilla.gnome.org/show_bug.cgi?id=684573
Commit c3cab28 removed bits setting the password char that was used to
allow typing the password after a failure but before the first question
for the new attempt came.
Without that code, in complex PAM setups you can end up with a visible
password.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
Desktop files can specify if the application should only be shown for
specified desktops with OnlyShowIn and NotShowIn directives options.
If a menu category only contained entries for a different desktop, we
were still creating the category.
We now only add a category button if there is at least one application
to be displayed in this category.
https://bugzilla.gnome.org/show_bug.cgi?id=687970
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
