summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Update Brazilian Portuguese translationgnome-43Leônidas Araújo2023-05-151-193/+201
|
* Bump version to 43.543.5Florian Müllner2023-04-256-4/+23
| | | | Update NEWS.
* autorunManager: Add missing await keywordBalló György2023-04-251-1/+1
| | | | | | | This fixes a regression introduced in commit c6861c0a3d3db3b3f4343e38b08b48d18803b2fe Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2745> (cherry picked from commit 1ee070a14bf1a0682c6e301b1aa0e54a69d0bef7)
* search: Expand search results viewSebastian Keller2023-04-251-1/+6
| | | | | | | | Otherwise the search results can end up only as large as their content. Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5924 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2744> (cherry picked from commit f6a8b6327652bf714090e98902e7621e0e840e6e)
* ci: Make fringe meson-install arguments optionalFlorian Müllner2023-04-252-7/+21
| | | | | | | | | | Both the subdir and prepare arguments are very specific to building the extensions-tool subproject stand-alone. In order to make the script more generic, turn those required arguments into optional --subdir and --prepare ones. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712> (cherry picked from commit ea629cabbfa51d5ad2a521970f6c5288346e55fe)
* ci: Add --help option to meson-install scriptFlorian Müllner2023-04-251-1/+9
| | | | | | | | It's not really necessary in an internal script, but it's easy enough and doesn't hurt *shrug* Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712> (cherry picked from commit d97c667937a76de843fe8637915acf91b8b55799)
* ci: Use built-in option parsing in meson-installFlorian Müllner2023-04-251-3/+20
| | | | | | | | | This is less concise than the current ad-hoc parsing, but gets us error handling ("unknown option --foo") and is easier to extend. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712> (cherry picked from commit cdd8d335870481a3a994ab4673dc44e97a78e761)
* ci: Make sure to always clear meson-install checkout dirFlorian Müllner2023-04-251-6/+5
| | | | | | | | | | | | | We currently remove the directory at the end of the script, but that code is only reached when all previous operations were successful. Address this by first using an absolute directory path in /tmp instead of a "random" location based on the CWD, then set a trap to remove it on exit. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712> (cherry picked from commit fac05b182cd3e19199014e35fd5387a32d98d11e)
* ci: Fix meson-install usage checkFlorian Müllner2023-04-251-6/+16
| | | | | | | | | | | | | | | | | | | The script has four mandatory arguments, and also accepts optional build options that are passed on to meson. Checking for the number of arguments *before* filtering out the optional ones means that `./install-meson-project.sh -Done=1 -Dtwo=2 -Dthree=3 -Dfour=4` is considered valid, even though not a single required argument is passed. Fix this by filtering out the arguments before doing the usage check. As it is a nice touch to have usage information at the top of the script, move the message into a usage() function at the top. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712> (cherry picked from commit 919812a851857ec66ec02d29bb25025f9c2f8205)
* ci: Stop running meson without subcommandFlorian Müllner2023-04-251-1/+1
| | | | | | | | Invoking meson with no command is deprecated in favor of `meson setup`. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712> (cherry picked from commit a5aeb6a3e6375be379a121dfb913da6017563ef3)
* subprojects: Stop running meson without subcommandFlorian Müllner2023-04-252-2/+2
| | | | | | | | Invoking meson with no command is deprecated in favor of `meson setup`. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712> (cherry picked from commit 6398ee8dc5090742417f95efde70e608cc2391df)
* shell-app-system: Give priority to .desktop IDs that should be shownMarco Trevisan (Treviño)2023-04-251-2/+17
| | | | | | | | | | | | If we have multiple desktop ID's that share the same startup-wm class and none of them is actually matching the desktop-id, then we should exclude the ones that should not be shown in the current desktop. This will help preventing cases such as the previous one in case no desktop file ID would match the startup-wm-class exactly. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2721> (cherry picked from commit 12bb3a601d590206c77d51be15ebc1890d1373a5)
* shell-app-system: Do not compare startup-wm classes with full desktop IDsMarco Trevisan (Treviño)2023-04-251-1/+21
| | | | | | | | | | | | | | | | | | | When fetching the desktop ids into a map of startup-wm classes we meant to give the ones that match the desktop ID more priority, however this did not happen because we were always comparing a desktop file id, including the `.desktop` suffix, with a wm-class that generally does not include that. This is the case of gnome-system-monitor, that provides two desktop files, one of which is OnlyShowIn=KDE but both have the same StartupWMClass and thus the first parsed is preferred, even though its desktop-id is gnome-system-monitor-kde. As per this, remove the .desktop suffix when comparing it with the startup-wm-class, keeping the old check just in case. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2721> (cherry picked from commit e7a09946ca44a4f4fae6fa847f08e681cfd877cb)
* windowPreview: Ignore leave events after being destroyedSebastian Keller2023-04-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | When a WindowPreview is being destroyed, the class default handler for the `destroy` signal is responsible for destroying its child actors. This happens after the emission of the `destroy` signal, i.e. after `WindowPreview::_onDestroy()` has been run. The destruction of the WindowPreview's child actors now triggers a re-pick, but due to WindowPreview having already being marked as `CLUTTER_IN_DESTRUCTION`, it will not be picked, resulting in a `leave` event if the cursor was on top of the WindowPreview at the time `destroy()` was called on it. So this leads to `WindowPreview::vfunc_leave_event()` being run after `WindowPreview::_onDestroy()`, which means the idle started by the leave event handler will not be removed and ends up accessing actors after they have already been destroyed. Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5512 Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6065 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2738> (cherry picked from commit 4bbf6d497d34793693e5ac24fbe23854b481002b)
* dash: Do not destroy a dash label twiceMarco Trevisan (Treviño)2023-04-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Dash labels are children of the main uiGroup and so could be destroyed before their logical-owner DashItemContainer during shutdown. This implies that we could destroy them twice. To avoid this, unset them when destroyed. This is mostly visible when using dash-to-dock, but it's still technically possible with upstream code: ** Message: 19:57:49.847: Shutting down GNOME Shell (gnome-shell:2788214): Gjs-CRITICAL **: 19:57:49.933: Object St.Label (0x55b33668eab0), has been already disposed — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs. == Stack trace for context 0x55b3345fd3d0 == #0 7ffeabd810d0 b /data/GNOME/gnome-shell/js/ui/dash.js:86 #1 55b335b62f88 i /data/GNOME/JHBUILD_HOME/.local/share/gnome-shell/extensions/dash-to-dock@micxgx.gmail.com/docking.js:487 #2 7ffeabd838f0 b self-hosted:1121 #3 55b335b62ec8 i /data/GNOME/gnome-shell/js/ui/layout.js:240 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2739> (cherry picked from commit 8bf06bfc9f87c665959e1ff3240f227e5cf224df)
* panelMenu: Fix keynav of menu-less buttonsFlorian Müllner2023-04-251-0/+3
| | | | | | | | | | | | | | | | The left/right navigation between top bar buttons is usually handled by a key-press handler on the button's menu. However when a DummyMenu is used, the button itself serves as fake menu actor and will get grabbed when "opening" the menu. Due to that grab, the event is not propagated to the stage, and regular keynav does not work. To avoid the focus getting stuck in that case, add an explicit key-press handler that bypasses the grab. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2734> (cherry picked from commit ecb274cee066591591127e03e10a582e9f2c0397)
* messageTray: Don't set _notificationRemoved if destroyed notification is queuedmsizanoen12023-04-251-3/+2
| | | | | | | | | | | | | | | | | | When the user clears all notifications from the notification menu UI, it's possible for a queued notification to be destroyed after the currently displayed notification. The removal of the currently displayed notification is not processed until the notification menu is closed (due to `this._bannerBlocked`). By then, it's possible that `_notificationRemoved` has already been overwritten when `_onNotificationDestroy` is invoked with another (queued) notification. This eventually results in a notification banner that cannot be removed by the user as the notification object needed to do so has already been destroyed. Fix this by only assigning to `_notificationRemoved` if `this._notification == notification`. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2736> (cherry picked from commit cde7d44a28688cd925bac45ebfa2bb0e7dd46860)
* misc/objectManager: Fix emission of object-removed signalJonas Dreßler2023-04-251-1/+1
| | | | | | | | | | | | | | | | Emitting this signal is broken right now: We check for a length of 0 on this._objects[objectPath], but the `this._objects[objectPath][interfaceName] = null` we do before the check doesn't actually remove the key, it only sets the value to null, leaving the key around and thus the amount of entries in the object doesn't change. Fix that by using the delete statement instead, "delete" properly removes the key and thus affects the amount of entries in the object, making our length === 0 check effective. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2730> (cherry picked from commit 8431e7ae51fb9007a815f8e72592df529ce44ba3)
* screenshot: Get cursor texture from windowIvan Molodetskikh2023-04-251-1/+5
| | | | | | | | | | When a window is in the background and should not have the cursor on top of it, its _cursor will be null. By getting the texture through it, we add this extra check, which was missing before, leading to a cursor drawn at 0, 0 on windows where it should not have been drawn. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2702> (cherry picked from commit 237c3e958db16bb4aa2aa575085e2e249cdee67e)
* workspacesView: Update visibility after updating workspacesFlorian Müllner2023-04-251-1/+1
| | | | | | | | | | | | | When the number of workspaces changes, it is possible that one of the visible (non-active) workspaces is removed, and another invisible workspace moves in its place. Make sure that workspaces are shown as necessary in this case. https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6519 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2699> (cherry picked from commit 95386a14235155e4390253c77ede8877b525b9e3)
* modalDialog: Fix fading out dialogFlorian Müllner2023-04-251-1/+1
| | | | | | | | | | | The dialog's state property has been read-only since commit 2f6323afc, but the callback at the end of the fade transition still tries to set the value directly. https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6506 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2696> (cherry picked from commit 5766d4111ac065b37417bedcc1b998ab6bee5514)
* appDisplay: Avoid using an undefined _swipeTrackerDaniel van Vugt2023-04-251-1/+2
| | | | | | | | It might have been deleted already during shutdown by `_onDestroy()`. Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6512 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2693> (cherry picked from commit b8013704cffbdedd2f82bcf38a556c6a74754615)
* status/location: Handle geoclue not being activatableWill Thompson2023-04-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In GNOME OS, due to a misconfiguration, geoclue was configured without systemd support. In that configuration, geoclue does not install its systemd .service file (geoclue.service) but it (incorrectly) includes the following line in its D-Bus service file: SystemdService=geoclue.service As a result, when dbus-daemon tried to activate it at gnome-shell's request, it would fail with: Unit geoclue.service not found Then, GeoclueAgent._onGeoclueVanished() would be called, as the name_vanished_handler passed to Gio.bus_watch_name(). This is consistent with Gio.bus_watch_name()'s documentation: > You are guaranteed that one of the handlers will be invoked after > calling this function. But that function assumed that this._managerProxy is defined, leading to: JS ERROR: TypeError: this._managerProxy is undefined _onGeoclueVanished@resource:///org/gnome/shell/ui/status/location.js:163:9 Fix this by checking for nullishness of this._managerProxy. (Strictly speaking, it's undefined rather than being null, but other code in this file already uses the vaguer '!= null' test, which considers undefined to be null.) Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2689> (cherry picked from commit ab0c795e814e631b144f18cc495c6f9225be8964)
* screenshot: Use meta_window_has_pointer () for pointer checkIvan Molodetskikh2023-04-251-1/+1
| | | | | | | | | | https://gitlab.gnome.org/GNOME/mutter/-/commit/909616b20876478bc56932cd18c8e85e982645f6 seems to have wrapped window actors in a container, so the actor.has_pointer check started failing. Instead, switch to meta_window_has_pointer () which doesn't rely on window actor implementation details. We check for existence of has_pointer first just in case someone attempts to run gnome-shell 44.1 with mutter 44.0 which does not have the function exported publicly yet. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2710> (cherry picked from commit 4daea0ccaeda3d752a9630437f65cfea100e63fa)
* Update Chinese (China) translationBoyuan Yang2023-04-101-178/+188
|
* Update Abkhazian translationNart Tlisha2023-04-051-117/+4266
|
* Bump version to 43.443.4Florian Müllner2023-03-196-4/+19
| | | | Update NEWS.
* overview: Hide when failing to take grab at end of startup animationSebastian Keller2023-03-191-0/+1
| | | | | | | | | Otherwise keyboard input would be going to whatever window was preventing us from taking the grab while it is obscured by the overview. (cherry picked from commit 56478f21e6641478f7509527fd3ed40169b2ec67) Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2704>
* overview: Don't claim to be SHOWN when HIDDEN during startup animationSebastian Keller2023-03-191-0/+6
| | | | | | | | | | | | | | When the overview gets hidden during the startup animation, the callback would still change the state to SHOWN, despite the overview not being shown. This can happen for example if a `monitors-changed` signal triggers a relayout during startup. See: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2514#note_1683525 (cherry picked from commit bb42973730a1a96881cb63bf7c1e9fdc68fb9fba) Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2704>
* dnd: Handle dragActorSource getting destroyedJonas Dreßler2023-03-191-0/+9
| | | | | | (cherry picked from commit de08ec915fd3de1bfd6488f14e0c8f8ae7250701) Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2704>
* status/network: Fix WirelessNetwork related leaksSebastian Keller2023-03-191-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NetworkManager frequently refreshes the list of available access points. For some reason this often ends up removing some or all access points only to add them back in a later refresh later. With the exception of the currently connected access point, which is never removed. When all access points of a WirelessNetwork have been removed, it gets destroyed by NMWirelessDeviceItem::_removeAccessPoint(). This however does not happen for the currently connected network due to the always present access point. If this network now happens to consist of multiple access points, the "unused" NMAccessPoints will get removed and added in these refreshes, without the WirelessNetwork getting destroyed. Whenever such an unused access point is added, due to the use of signal tracking this leaks the NMAccessPoint and SignalTracker until the WirelessNetwork is destroyed. However when the NMWirelessDeviceItem is destroyed, for example due to suspending, it stops tracking access point changes, ensuring that the condition for the WirelessNetwork being destroyed can not occur anymore. Even with just two access points, such as can be found in 2.4GHz+5GHz home routers this issue leaks hundreds of NMAccessPoints and SignalTrackers per day. As well as a small number of WirelessNetworks which are also kept alive by the SignalTrackers. To fix this disconnect from the access point when it gets removed and destroy all remaining networks when the NMWirelessDeviceItem is destroyed. (cherry picked from commit feb1c57ddee323813e53e3bd20297590cd4b3b74) Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2704>
* Update French translationAlan Paris2023-03-081-192/+185
|
* Update Hungarian translationBalázs Úr2023-03-021-146/+182
|
* Update Serbian translationМирослав Николић2023-02-261-115/+128
|
* Update Lithuanian translationAurimas Černius2023-02-191-104/+111
|
* Update Polish translationPiotr Drąg2023-02-181-141/+170
|
* Update German translationTim Sabsch2023-02-181-174/+182
|
* Update Slovenian translationMartin2023-02-151-1345/+166
|
* Update Indonesian translationKukuh Syafaat2023-02-151-98/+112
|
* Update Ukrainian translationYuri Chornoivan2023-02-141-111/+125
|
* Update Portuguese translationHugo Carvalho2023-02-141-108/+118
|
* Update Georgian translationEkaterine Papava2023-02-141-83/+119
|
* Update Finnish translationJiri Grönroos2023-02-141-171/+168
|
* Update Turkish translationSabri Ünal2023-02-141-152/+194
|
* Update Swedish translationAnders Jonsson2023-02-141-102/+112
|
* Bump version to 43.343.3Florian Müllner2023-02-146-4/+25
| | | | Update NEWS.
* gdmUtil: Fix SignalTracker leak in ShellUserVerifierSebastian Keller2023-02-131-0/+1
| | | | | | | | | | ShellUserVerifier was connecting to UserVerifierChoiceList signals using SignalTracker, but never disconnected those, leading to the corresponding SignalTracker being leaked. Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6395 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2637> (cherry picked from commit 1236bf8f095cca5cc15d5ce012ac4dbc8ff5da6f)
* authPrompt: Manually destroy inactive/unused entrySebastian Keller2023-02-131-0/+5
| | | | | | | | | | | | | AuthPrompt creates two entries, one for text and one for passwords, but only ever one is used as child widget. This would lead to the other one not getting destroyed when the the AuthPrompt is destroyed. This now manually destroys the inactive one when the AuthPrompt is destroyed to avoid that leak. Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6395 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2637> (cherry picked from commit 572d011894c9b490b8a17ad7db6adec335fbb017)
* overview: Skip SHOWN to SHOWN when changing from app grid to overviewSebastian Keller2023-02-131-1/+3
| | | | | | | | | | | | Switching between the app grid and the window picker in the overview via gestures results in _gestureEnd() getting called with endProgress !== 0 in both cases, which leads to it calling _showDone(). This then unconditionally changes the state to SHOWN, which in this situation is already the current state. Since the previous commit this results in a warning, so check if we are already in the SHOWN state. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2514> (cherry picked from commit f5d793647ba0f813d65241cd53cdc418a9d54498)
* overview: Validate transitions of the `shown` stateSebastian Keller2023-02-131-9/+51
| | | | | | | | | | | | | | | | | | | | | | There have been several bugs in the past that caused invalid transitions of the `shown` state, such as going from `showing` to `showing`. These cause consecutive emissions of the `showing` signal, which can confuse other classes such as the search controller which connects to the stage `key-press-event` on showing and disconnects again on `hiding`. Having two consecutive `showing` signals will cause it to connect twice, and only disconnect once when hiding the overview again. This will lead to key presses getting repeated in the search until the session is restarted. Because there is no obvious connection to how and when this issue got triggered, this now adds some validation code that only allows valid transitions and throws an error otherwise so we get a backtrace of the code actually causing the problem. This does not fix the issue(s) causing the invalid state transitions, it only adds a way of tracking them down. Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4651 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2514> (cherry picked from commit a91b6439ba457a33cd09d498cb96d1b02e1832e7)
View Lorry Controller Status