summaryrefslogtreecommitdiff
path: root/js
Commit message (Collapse)AuthorAgeFilesLines
* popupMenu: Replace ornament unicode with iconsmaniacx2023-05-172-8/+8
| | | | | | | | | | | | | Ported from Sam Hewett's Merge-Request. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2308#8714a3530d73823716c0f8334aceaabeaccd01b7 The CHECK ornament used in powerprofile and volume control is not very pleasant looking, specially if system font is changed. Replace CHECK and DOT unicode ornament with revelant icons in popupMenu. Solves issue: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6055 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2767>
* mpris: Fall back to app icon firstFlorian Müllner2023-05-151-0/+3
| | | | | | | | When no cover art is available, the app icon at least allows distinguishing between different players, so try falling back to that before using the generic icon name. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2755>
* mpris: Expose player appFlorian Müllner2023-05-151-8/+13
| | | | | | This will allow accessing it from the notification. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2755>
* polkitAgent: Fix closing dialog properlyJoan Torres2023-05-091-1/+0
| | | | | | | | When pressing the close button on the dialog the polkit request isn't completed leaving the polkit agent blocked unable to handle new requests. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2761>
* screencastService: Fixup pipeline fallback behaviorJonas Dreßler2023-04-261-2/+7
| | | | | | | | | | | Calling _teardownPipeline() before _tryNextPipeline() was actually not a good idea, it sets the pipelineState to STOPPED, which means we can't try any of the following pipelines anymore. Instead what we want to do is set the pipeline state of the old pipeline to NULL when trying a new one, without calling _teardownPipeline() for that. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2754>
* screenshot: Remove leftover code in property getterJonas Dreßler2023-04-261-3/+0
| | | | | | | According to Ivan (author of that piece of code), this is most likely a leftover from a refactor and has no purpose anymore, so remove it. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2753>
* Remove keyboard shortcut to open the app menu in the panelJonas Dreßler2023-04-262-15/+0
| | | | | | | | Now that the app menu indicator is no longer shown, it shouldn't be possible to toggle the popup menu via keyboard shortcut anymore, so remove the code and gsettings definitions for that. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2610>
* panel: Remove the appMenu indicatorJonas Dreßler2023-04-261-1/+1
| | | | | | | | | | | Over time the app menu has proved to be an issue and lately there has been some movement to fix that (see also https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/198). As a first step, let's stop showing the indicator (not removing the code yet) so that we can iterate on a more elegant solution. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2610>
* screencastService: Add dmabuf/GL pipelinerobert.mader@collabora.com2023-04-261-0/+9
| | | | | | | | | | | | | | This pipeline imports dmabufs and does format conversion using GL. The `video/x-raw(memory:DMABuf)` filter ensures format negotiation between `pipewiresrc` and Mutter will only succeed if Mutter advertises dmabuf support as well, falling back to the next pipeline otherwise. Using this pipeline frees Mutter from downloading buffer content on the main thread which can have a big impact on compositor performance. Doing format conversion on the GPU should further improve the overall performance on most hardware. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2597>
* screenshot: Also handle dbus service crashesJonas Dreßler2023-04-261-0/+10
| | | | | | | | | | When the screencast dbus service crashes due to gstreamer, we should also handle that and not pretend to continue recording. Let's listen to g-name-owner changes for that and then also send a notification about it. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2752>
* screenshot: Handle screencast errors properlyJonas Dreßler2023-04-261-2/+16
| | | | | | | Send a notification and remove the screencast inidicator when we hear about a screencast error from the dbus service. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2752>
* screencastService: Signal errors via the internal dbus interfaceJonas Dreßler2023-04-262-13/+23
| | | | | | | | Make sure gnome-shell gets notified of errors that happen during screen recording using the screencastService, so that it can properly notify the user about the error and tear down its state, too. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2752>
* screencastService: Do not try multiple pipelines on old Pipewire versionsrobert.mader@collabora.com2023-04-261-1/+4
| | | | | | | | | | Pipewire versions < 0.3.67 may not fail immediatly on negotiation errors, thus use the last/fallback pipeline directly. Technically, a similar recent version of Wireplumber is required as well, but we can't check that easily and the combination of old Wireplumber and new Pipewire is quite unlikely. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2609>
* screencastService: Add fallback mechanism for gstreamer pipelinesJonas Dreßler2023-04-261-33/+80
| | | | | | | | | | | | | | | | Introduce a fallback mechanism for gstreamer pipelines that allows to define multiple pipelines and prefer them over each other. The way this works is that we introduce a new STARTING PipelineState. While the Recorder is in that state, it is allowed to tear down the current pipeline and start another one whenever an error happens, this is used to try multiple pipelines in a fixed order until a working one is found. Right now there's just a single pipeline using the existing vp8 encoder, the actual new encoders and pipelines will be added in a separate commit. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2609>
* screencastService: Drop always-copy conditionrobert.mader@collabora.com2023-04-251-4/+0
| | | | | | | | | | | | | | | | | | | | | | The check for the Pipewire version was originally introduced in d32c0348 which states: > Since it is not clear yet when a proper solution will arrive, > this makes use of `always-copy` as a workaround for now and > should be reverted once it is no longer needed. The check for a stable Gstreamer version with the mention proper fix was introduced in d7b44319 and carried for the 43 cycle. By the time Gnome 44 will be released all distros should have had enough time to update their Gstreamer version - or backport the patches, in case of not ustream-supported versions. Thus lets drop it now. Note: `always-copy` is not suitable for dmabuf buffers as it copies via mmap. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2609>
* screencastService: Set PipelineState to PLAYING on actual state-changeJonas Dreßler2023-04-251-4/+22
| | | | | | | | | | | | | | | | Right now when we tell gstreamer to move the pipeline to the state PLAYING, we pretend that happens immediately and set our PipelineState to PLAYING right afterwards. In reality though it's more complicated than that: Gstreamer changes states asynchronously and set_state() returns a Gst.StateChangeReturn.ASYNC. In that case we should wait until the according STATE_CHANGED event happens on the bus, and only then set our PipelineState to PLAYING. Since the STATE_CHANGED event will also happen when set_state() returns SUCCESS, we can use the same async logic for that. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2197>
* screencastService: Handle more gstreamer errorsJonas Dreßler2023-04-251-2/+38
| | | | | | | | | Gstreamer can produce various errors, we shouldn't pretend those don't exist and go on as usual when one happens. Instead, when an error happens, tear down the pipeline, set our PipelineState to the new ERROR state and bail out with a proper error message. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2197>
* screencastService: Streamline teardown and error handlingJonas Dreßler2023-04-251-39/+63
| | | | | | | | | | | | | | | | | We're tracking three different state-machines in the Recorder object: The state of the gstreamer pipeline, the state of the screencast session, and the sender of our dbus invocation that might vanish. Properly handling errors that might appear in any of those three "black boxes" is not easy, especially tearing down the other two when one of them breaks. So refactor the error handling here: Add a single error path for each of those three states we're tracking, and make them all subsequently call the _bailOutOnError() method. From there we tear down the other states and call the error callbacks. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2197>
* screencastService: Add an ERROR state for the pipeline state trackingJonas Dreßler2023-04-251-0/+1
| | | | | | | This will be useful when we start actually listening for ERROR events on the gstreamer bus. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2197>
* screencastService: Use strings for statesJonas Dreßler2023-04-251-7/+7
| | | | | | | Using strings instead of numbers allows for easier debugging, it means we can just log the state itself. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2197>
* screencastService: Promisify Recorder start/stopRecording functionsJonas Dreßler2023-04-251-60/+58
| | | | | | | | | This will allow for cleaner error handling in the following commits. A benefit we get from it right now is having one less callback when calling startRecording/stopRecording(). Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2197>
* status/bluetooth: Use 'Alias' for item labelsFlorian Müllner2023-04-251-1/+1
| | | | | | | | | Unlike 'Name', the 'Alias' property can be changed by the user, so it's more suitable for user-visible labels. https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6626 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2751>
* portalHelper: Use libadwaita instead of plain Gtk4Florian Müllner2023-04-251-2/+3
| | | | | | | This gives us the proper platform stylesheet, as well as support for dark style and other platform features. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2690>
* portalHelper: Stop using a subtitleFlorian Müllner2023-04-251-58/+64
| | | | | | | | | | | | The pattern has become a lot less common, not least indicated by the removal of the HeaderBar:subtitle property. And in this case we are including an icon in the subtitle, which looks completely out of place. Address this by moving the URL/security information into a popover menu, inspired by the similar drop-down in GNOME Web. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2690>
* portalHelper: Port to Gtk4/WebKit6Florian Müllner2023-04-251-33/+25
| | | | | | | | WebKit was blocking the portal helper from being ported to Gtk4 together with other external tools. Now that WebKit6 is about to become stable, the port can go ahead. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2690>
* portalHelper: Don't use deprecated API during policy decisionFlorian Müllner2023-04-251-6/+7
| | | | | | | | | | NavigationPolicyDecision.get_request() is deprecated, and the method from the corresponding NavigationAction should be used instead. Rearrange the code to do that. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2690>
* portalHelper: Adjust coding styleFlorian Müllner2023-04-251-18/+21
| | | | | | | Most of the file already complies with the new style. Quickly change the last remaining bits of legacy style before making further changes. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2690>
* portalHelper: Stop monkey-patching String.format()Florian Müllner2023-04-251-7/+0
| | | | | | It's not used, so no need to set it up. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2690>
* portalHelper: Remove pointless destroyWindow() methodFlorian Müllner2023-04-251-7/+2
| | | | | | | | | Years ago, the function used to clean up the cache when the window was closed. But now that an ephemeral data manager is used, nothing is cached anymore and the function is left as a mere wrapper around this.destroy(). Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2690>
* screenshot: Use independent tooltips for the Screenshot/Screencast buttonsAutomeris naranja2023-04-251-15/+12
| | | | | | Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6189 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2683>
* environment: Remove old compatibility codeFlorian Müllner2023-04-251-6/+0
| | | | | | | | St.set_slow_down_factor() has been deprecated for over 3 years (since 3.34). That's plenty of time for extensions to switch to St.Settings.get().slow_down_factor. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2743>
* status/backgroundApps: Show spinner when closingFlorian Müllner2023-04-251-0/+29
| | | | | | | | | | | | | It can take a little while for an app to quit after the user clicked the close button, and another for the portal to pick up the change. In order to provide feedback to the user that the request is being handled, replace the close button with a spinner. https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6441 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2732>
* workspaceThumbnail: Use click actionFlorian Müllner2023-04-251-35/+13
| | | | | | | | Now that we have a convenient way of combining a draggable with a click action, we can port the code without making it more complicated. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2742>
* dnd: Add addClickAction() methodFlorian Müllner2023-04-252-37/+54
| | | | | | | | | | | | | | | | The events that the draggable uses to initiate a drag operation are the same as the ones a click action consumes for clicks. It is still possible to combine the two, but it's finicky and far from being straight-forward. To make this easier, add a dedicated addClickAction() method to draggables that takes care of the setup before adding the action to the draggable actor. In the longer term, we'll want to turn DND into an action, and have something like GTK's gesture group to allow combining actions that would otherwise step on each other's toes. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2742>
* popupMenu: Replace event handlers with click actionFlorian Müllner2023-04-251-56/+13
| | | | | | | | | | | | Actions provide a higher-level API than event handlers, not unlike GTK's event controllers (albeit less complete). Allowing them to take care of the low-level bits where possible is generally a good idea. Menu items are a very straight-forward case, with a good amount of code saving, so port them over. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2742>
* panel: Drop unnecessary captured-event handlerFlorian Müllner2023-04-251-9/+0
| | | | | | | | | | | | | The handler dates back to commit 50f248ec5b2a0 in 2011, and is part of the original hack of making the activities button a PanelMenu.Button while suppressing its menu. By now, panel buttons without a menu have been properly supported for years, but somehow that bit of the hack stuck around, even though it is no longer actually needed (probably since the introduction of DummyMenu. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2741>
* status/volume: Ignore capitalization for headphone detectionFlorian Müllner2023-04-211-1/+1
| | | | | | | | | When we can't detect a headphone by form factor, we do a string match on the port name. A match on 'Headphone' isn't less likely to be valid than a match on 'headphone', so make sure we ignore capitalization. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2691>
* autorunManager: Add missing await keywordBalló György2023-04-211-1/+1
| | | | | | This fixes a regression introduced in commit c6861c0a3d3db3b3f4343e38b08b48d18803b2fe Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2745>
* search: Expand search results viewSebastian Keller2023-04-211-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>
* scripting: Return promise in helper window wait functionsJonas Ådahl2023-04-201-2/+2
| | | | | | Otherwise they won't wait when doing e.g. `await waitTestWindows();`. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2722>
* tests/closeWithActiveWindows: Also test input method tear downJonas Ådahl2023-04-201-0/+7
| | | | | | | | | From a test case perspective, it's simple - make the test window have a text entry, and make sure we have a virtual keyboard making GTK3 enable the text entry. This would without a fix trigger https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6535. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2722>
* js/main: Unset input method on shutdownJonas Ådahl2023-04-201-0/+2
| | | | | | | | After shutdown, the Javascript context will be disposed, so we must make sure we remain the active input method after this point. Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6535 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2722>
* perf-helper: Allow creating window with text inputJonas Ådahl2023-04-201-1/+3
| | | | Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2722>
* tests/perf: Add test for shutdown with open windowJonas Ådahl2023-04-202-0/+30
| | | | | | | This would without the applied fix trigger https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6536. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2722>
* scripting: Allow avoiding exiting perf helperJonas Ådahl2023-04-201-3/+17
| | | | | | | This will help creating test cases where windows are open during shutdown. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2722>
* popupMenu: Only activate items that still have the pointerFlorian Müllner2023-04-201-0/+5
| | | | | | | | | | | | | | | | | | After the introduction of implicit grabs in Clutter, a release event will now always be delivered to the actor that received the corresponding press event. This results in surprising behavior when moving the pointer while pressed, as a button release will always activate the original item, even when the pointer moved to a different item or outside the menu altogether. Address this by checking the hover state (that is, whether the item contains the pointer actor) before activating it. https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6606 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2740>
* windowPreview: Ignore leave events after being destroyedSebastian Keller2023-04-181-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>
* dash: Do not destroy a dash label twiceMarco Trevisan (Treviño)2023-04-171-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>
* panelMenu: Fix keynav of menu-less buttonsFlorian Müllner2023-04-171-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>
* messageTray: Don't set _notificationRemoved if destroyed notification is queuedmsizanoen12023-04-171-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>
View Lorry Controller Status