GObject-Introspection started warning for wrong annotations, and
StGenericAccessible::set-current-value has a return value annotation
even if it returns nothing. This generates the warning:
src/st/st-generic-accessible.c:146: Warning: St:
StGenericAccessible::set-current-value: invalid return annotation
Which, coupled with fatal warnings, breaks the Shell build.
StIcon will skip loading the texture when its theme node is unset (which
may happen on style changes while the widget is hidden). While our size
request to compute the dash icon size will create the icon's theme node
if necessary (and of all its parents), a missing texture can still throw
off our computation.
Make sure this doesn't happen by ensuring the icon's style first, so the
texture is updated in response to StWidget::style-changed if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=745649
When adjusting dash icon sizes, we compute the icon padding by subtracting
the configured icon size from the first icon actor's preferred size. To
make sure that the preferred size correctly corresponds to the current
dash icon size even while the icon is animating, we enforce the size
before the size request. For that we used to temporarily manipulate
the icon texture size directly, but commit e92d204d42 cleaned this
up to use the setIconSize() method instead.
This does not work however, as the icon actor's iconSize property will
always match the dash iconSize property, making the method a noop. So
go back to the original approach of enforcing the texture size to make
sure we always base our computations on correct values.
https://bugzilla.gnome.org/show_bug.cgi?id=745649
The destroy signal handler is kept connected despite the NotificationMessage
being destroyed, which leaves dangling NotificationMessage objects that will
be mass destroyed when the Notification object these depend upon is finally
destroyed.
Depending on the amount of accumulated NotificationMessages, this may lead
to temporary freezes or other more funky issues when recursion limits are
hit.
https://bugzilla.gnome.org/show_bug.cgi?id=755425
We only need the user verifier for the purpose of user verification.
Once it's complete we should clear it so it doesn't get in the way
later.
This fixes a bug introduced in commit 3c8c5a5570 that leads to the
user session crashing when the login screen is reactivated.
https://bugzilla.gnome.org/show_bug.cgi?id=753181
We fade out the authentication prompt when a user successfully
logs into a user session. We reset it and fade it back in when
the user switches back to the login screen VT.
The problem is, we only fade it back in if the auth prompt status is
VERIFICATION_SUCCEEDED. It's possible for it to be NOT_VERIFYING
if the authprompt gets reset for some other reason in the interim.
This commit changes the check to be more precise. We now only skip
the fade-in, if we're already faded in, and we only skip the reset if
we're already reset.
https://bugzilla.gnome.org/show_bug.cgi?id=753181
It may be 2015, but users still stumble upon the occasional .desktop
file that uses a filename encoding other than UTF-8. We currently
fail quite spectacularly in that case by not displaying any apps at
all - handle this case more gracefully, by only filtering out the
offending apps.
https://bugzilla.gnome.org/show_bug.cgi?id=651503
The user should be allowed to cancel if verification hasn't
started yet and they're typing in their username. This
commit changes the authPrompt cancel function to not
ignore such requests.
https://bugzilla.gnome.org/show_bug.cgi?id=752739
Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
This commit addresses that bug.
https://bugzilla.gnome.org/show_bug.cgi?id=752739
If the next button ever gets set to Sign In, it won't
get reset to next until the next question asked by pam.
This commit ensures it gets reset to Next when asking
for the username.
https://bugzilla.gnome.org/show_bug.cgi?id=752739
We currently only cancel the user verifier on reset if
verifying, but that means we don't properly cancel it when
asking for a username at the Not Listed screen.
The object already handles getting called when there is
nothing to cancel, so just cancel it unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=752438
Our StartUpWMClass heuristics use a StartupWMClass -> .desktop ID
mapping built from the list of all installed applications. In case
of multiple .desktop files setting the same StartupWMClass, we
currently simply pick the last one returned by g_app_info_get_all (),
which can be a bit surprising:
A window with WM_CLASS 'emacs', launched through a .desktop file
named 'emacs.desktop' with a StartupWMClass of 'emacs' maps to ...
'emacsclient.desktop'!
Make this case a bit less random by preferring the app info whose
ID matches the StartupWMClass.
https://bugzilla.gnome.org/show_bug.cgi?id=751541
In some cases we might be allocated a size such that
this._grid.topPadding and this._grid.bottomPadding are both 0 which
means that the ScrollView fade effect gets removed. In that case don't
try to access the effect since it will be NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=750714
And make these only handled on wayland. There's a plethora of issues
around touch passive grab and touch/pointer doubly handling to use
these right away on X11, so we stick to single-touch/pointer there.
This reverts commit 032a688a72.
https://bugzilla.gnome.org/show_bug.cgi?id=750287
The menu is clearly associated with a particular window, so keeping
it around when the window is gone doesn't make sense - in case of
the window menu, it is actually harmful as every action will act on
the invalidated window and result in a crash. So just dismiss the
menu when the menu is unmanaged.
https://bugzilla.gnome.org/show_bug.cgi?id=749529
When chrome is added with the trackFullscreen parameter, the actor's
visibility will be updated automatically whenever its monitor's
fullscreen state changes. However as we currently ignore the fullscreen
state at the time the chrome is added, the initial visibility may well
be incorrect - fix this by updating the initial visibility as necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=749383
Since the introduction of per-source notification policy in commit
098bd4509b, the NotificationPolicy::enable-changed signal has been
used to track the 'enable' setting. However as we never actually
emitted that signal, this never worked without a restart - oops.
https://bugzilla.gnome.org/show_bug.cgi?id=749279
If we aren't the active session clutter can't animate and thus we
can't expect the shield to be shown before releasing the suspend
inhibitor so we should release it immediately when becoming inactive.
https://bugzilla.gnome.org/show_bug.cgi?id=749228
The whole point of holding a suspend inhibitor is to be able to lock
before suspending.
Currently, when resuming we immediately take the inhibitor without
checking that we're locked which means that we won't be able to
release this inhibitor if we don't unlock at least once.
To prevent that and to better match the inhibitor's intention in the
first place, we can tie the inhibitor with not being locked. In
practice, we also want to let the locking animation finish before
suspending, so we'll tie the inhibitor with not being active
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=749228
This could happen if we are VT switched away and an animated
activation is requested because we're preparing to enter sleep. Since
we don't animate in this case we'd never reach
_completeLockScreenShown() before coming out of sleep, at which point
we _inhibitSuspend() again and would leak the previous inhibitor.
https://bugzilla.gnome.org/show_bug.cgi?id=749228
Commit 08690d658f generalized the banner-blocking behavior of the
dateMenu to all menus that would obscure the banner. However setting
up the 'open-state-changed' handler only when an indicator is added
does not work for indicators that change their entire menu (like the
app menu) - we currently end up with menus with no connected signal
handler, and throw an error when trying to disconnect an invalid
signal ID.
To address this, add a new PanelButton::menu-set signal and use that
to set up the 'open-state-changed' handler.
https://bugzilla.gnome.org/show_bug.cgi?id=745910
We currently block banners while the time+date menu is open, as it
would obscure the notification. However it is not necessarily the
only menu for which this is the case, so generalize the behavior
to all menus that would overlap banners when open.
https://bugzilla.gnome.org/show_bug.cgi?id=745910
As notifications appear in the time+date dropdown's message list, there's
a strong relationship between notification banners and the menu. However
while the time+date menu is centered by default, which matches the banner
position, its actual position depends on the session mode - in particular
it is moved to the right in classic mode.
Reinforce the relationship in these cases by moving notification banners
underneath the time+date menu.
https://bugzilla.gnome.org/show_bug.cgi?id=745910
Unlike entries in the calendar's message list, banners are not subject
to the normal keynav chain, and making the banner actor itself unfocusable
allows for the focus to be moved to the action area when expanded.
https://bugzilla.gnome.org/show_bug.cgi?id=747205
Now that the tray is shown temporarily when a tray icon appears,
we can decrease its visible width when concealed to interfere less
with window content without hurting discoverability.
https://bugzilla.gnome.org/show_bug.cgi?id=746787
There is a balance to hit between discoverability and getting out
of the way, and the legacy tray currently fails in both regards.
To address the first issue, temporarily reveal the tray when a
new icon is added.
https://bugzilla.gnome.org/show_bug.cgi?id=746025
Resident notifications are not really a thing anymore with the new
design, so all the user sees are some notifications that mysteriously
cannot be closed. That's utterly confusing, stop doing that.
https://bugzilla.gnome.org/show_bug.cgi?id=746860
libcaribou was designed to generate X events which works under wayland
sessions for X clients but obviously doesn't work for wayland clients
and for shell chrome.
This patch adds a simple caribou display adapter which inherits from
its X display adapter and allows us to continue to work for X clients
and at the same time makes the OSK work on shell text entries by
sending key events directly to the focused text actor.
Making the OSK work for wayland clients requires much bigger changes
at various levels in the stack and either not using libcaribou or
re-working it substantially so that's left for future work.
https://bugzilla.gnome.org/show_bug.cgi?id=747274
Sources are destroyed with their last notification. This is usually the
correct behavior, however in case of chat sources, the corresponding
telepathy channel might still be open, and any further messages that
should trigger a notification are lost because chat sources are only
created when telepathy's channel dispatcher notifies us about a channel
(via ObserveChannels).
Loosing messages like this is unexpected, so keep chat sources around
even without notifications while the channel is open.
https://bugzilla.gnome.org/show_bug.cgi?id=747636
Currently the lifetime of a chat source and its single notification
are tied together. While this apparently makes sense, it means we
will lose all follow-up notifications when a source is destroyed
with the corresponding telepathy channel left open. We will fix this
soon by tying the source to the channel's lifetime rather than the
notification, prepare for this by recreating the notification if
necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=747636
