- Dec 05, 2015
-
-
- Oct 28, 2015
-
-
Aurimas Černius authored
-
- Oct 16, 2015
-
-
Kjartan Maraas authored
-
- Oct 15, 2015
-
-
Florian Müllner authored
Update NEWS.
-
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.
-
- Oct 13, 2015
-
-
Florian Müllner authored
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
-
Florian Müllner authored
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 e92d204d 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
-
- Oct 11, 2015
-
-
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
-
- Oct 05, 2015
-
-
- Aug 05, 2015
-
-
Ray Strode authored
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 3c8c5a55 that leads to the user session crashing when the login screen is reactivated. https://bugzilla.gnome.org/show_bug.cgi?id=753181
-
Ray Strode authored
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
-
- Jul 31, 2015
-
-
Florian Müllner authored
-
Florian Müllner authored
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
-
- Jul 26, 2015
-
-
- Jul 24, 2015
-
-
Ray Strode authored
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
-
Ray Strode authored
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
-
Ray Strode authored
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
-
Ray Strode authored
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
-
- Jul 23, 2015
-
-
Bastien Nocera authored
ff1b76f4 made gnome-shell stop looking at the org.gnome.SettingsDaemon.Cursor service's property values, but we still monitored the service itself. https://bugzilla.gnome.org/show_bug.cgi?id=752779
-
- Jul 02, 2015
-
-
Florian Müllner authored
Update NEWS.
-
Florian Müllner authored
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
-
- Jun 26, 2015
-
-
The code to figure how how much room that banner had was wrong. This commit fixes it. https://bugzilla.gnome.org/show_bug.cgi?id=751517
-
We are pointlessly calling g_settings_list_keys() twice, without freeing the result from the first call.
-
Rui Matos authored
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
-
- Jun 02, 2015
-
-
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 032a688a. https://bugzilla.gnome.org/show_bug.cgi?id=750287
-
- May 21, 2015
-
-
Florian Müllner authored
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
-
Florian Müllner authored
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
-
- May 14, 2015
-
-
Florian Müllner authored
Update NEWS.
-
Florian Müllner authored
Since the introduction of per-source notification policy in commit 098bd450, 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
-
Rui Matos authored
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
-
Rui Matos authored
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
-
- May 13, 2015
-
-
Rui Matos authored
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
-
- May 11, 2015
-
-
- May 10, 2015
-
-
- May 03, 2015
-
-
- Apr 30, 2015
-
-
Florian Müllner authored
Commit 08690d65 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
-
- Apr 27, 2015
-
-
Rui Matos authored
This allows mutter to ignore these events for the purpose of keeping idle time. https://bugzilla.gnome.org/show_bug.cgi?id=748541
-
-
- Apr 25, 2015
-
-
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
-