xdg-desktop-portal-gnome issueshttps://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues2024-03-20T03:15:25Zhttps://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/126disable request breaks Input Capture portal2024-03-20T03:15:25ZFerdinand Schoberdisable request breaks Input Capture portalWhen [disable](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.InputCapture.html#org-freedesktop-portal-inputcapture-disable) is invoked on an input capture session, it is left in a broken state and input eve...When [disable](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.InputCapture.html#org-freedesktop-portal-inputcapture-disable) is invoked on an input capture session, it is left in a broken state and input events are no longer sent to the connected eis socket.
[This repository](https://github.com/feschber/ashpd-mre) demonstrates the problem:
- The input capture works until the session is disabled and reenabled.
- Calling `release` is no problem and works as expected.
- Once the `disable` request is sent, the input capture stops sending events to the ei client.
This is especially confusing because an `activated` signal is still being sent and the pointer is locked.
The behaviour is in clear contradiction to the [freedesktop API documentation](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.InputCapture.html#org-freedesktop-portal-inputcapture-disable):
```
"Input events will not be captured until a subsequent org.freedesktop.portal.InputCapture.Enable call."
```
The only workaround I could come up with is to never call `disable` and instead recreate the session everytime.
Since the `xdg-desktop-portal-gnome` implementation does not allow to set pointer barriers while input capturing is enabled, changing the pointer barriers requires a `disable` request and since that does not work the session needs to be recreated in order to set new pointer barriers, causing the "allow input capture" popup to appear everytime!
This last point is a seperate issue, where the implementation also deviates from the documentation:
```
"Setting pointer barriers immediately suspends the current session and the application must call org.freedesktop.portal.InputCapture.Enable after this method."
```
In the documentation, it sounds like setpointerbarriers should work when the session is enabled and suspend it instead of throwing an error, while gnome silently ignores the request and logs an error.
I asked on the Gnome-Shell matrix chat and was told this is a somewhat known issue and that I should CC you, @whot .https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/125[xdg-desktop-portal-gnome-45.1-1] Fedora + Wayland + Pipewire + Camera2024-03-12T16:10:16ZJoel Winarske[xdg-desktop-portal-gnome-45.1-1] Fedora + Wayland + Pipewire + CameraFedora 39 + Wayland Session
I am getting a very frequent coredump. It started around the time I was testing with the Camera app. I had deleted this file:
```
/home/joel/.local/share/flatpak/db/devices
```
File was re-created.
```
...Fedora 39 + Wayland Session
I am getting a very frequent coredump. It started around the time I was testing with the Camera app. I had deleted this file:
```
/home/joel/.local/share/flatpak/db/devices
```
File was re-created.
```
Module xdg-desktop-portal-gnome from rpm xdg-desktop-portal-gnome-45.1-1.fc39.x86_64
Stack trace of thread 7090:
#0 0x00007f9cef477834 __pthread_kill_implementation (libc.so.6 + 0x90834)
#1 0x00007f9cef4258ee raise (libc.so.6 + 0x3e8ee)
#2 0x00007f9cef40d8ff abort (libc.so.6 + 0x268ff)
#3 0x00007f9cf0555056 g_assertion_message.cold (libglib-2.0.so.0 + 0x20056)
#4 0x00007f9cf05b6ad7 g_assertion_message_expr (libglib-2.0.so.0 + 0x81ad7)
#5 0x000055fbbf0131e8 main (xdg-desktop-portal-gnome + 0x211e8)
#6 0x00007f9cef40f14a __libc_start_call_main (libc.so.6 + 0x2814a)
#7 0x00007f9cef40f20b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2820b)
#8 0x000055fbbf0132f5 _start (xdg-desktop-portal-gnome + 0x212f5)
Stack trace of thread 7097:
#0 0x00007f9cef4eebed __poll (libc.so.6 + 0x107bed)
#1 0x00007f9cf05ebeb4 g_main_context_iterate_unlocked.isra.0 (libglib-2.0.so.0 + 0xb6eb4)
#2 0x00007f9cf0592447 g_main_loop_run (libglib-2.0.so.0 + 0x5d447)
#3 0x00007f9cf047b592 gdbus_shared_thread_func.lto_priv.0 (libgio-2.0.so.0 + 0x11c592)
#4 0x00007f9cf05c1523 g_thread_proxy (libglib-2.0.so.0 + 0x8c523)
#5 0x00007f9cef475897 start_thread (libc.so.6 + 0x8e897)
#6 0x00007f9cef4fc80c __clone3 (libc.so.6 + 0x11580c)
Stack trace of thread 7096:
#0 0x00007f9cef4eebed __poll (libc.so.6 + 0x107bed)
#1 0x00007f9cf05ebeb4 g_main_context_iterate_unlocked.isra.0 (libglib-2.0.so.0 + 0xb6eb4)
#2 0x00007f9cf058ead3 g_main_context_iteration (libglib-2.0.so.0 + 0x59ad3)
#3 0x00007f9cf058eb29 glib_worker_main (libglib-2.0.so.0 + 0x59b29)
#4 0x00007f9cf05c1523 g_thread_proxy (libglib-2.0.so.0 + 0x8c523)
#5 0x00007f9cef475897 start_thread (libc.so.6 + 0x8e897)
#6 0x00007f9cef4fc80c __clone3 (libc.so.6 + 0x11580c)
Stack trace of thread 7095:
#0 0x00007f9cef4fa60d syscall (libc.so.6 + 0x11360d)
#1 0x00007f9cf05e8b2d g_cond_wait (libglib-2.0.so.0 + 0xb3b2d)
#2 0x00007f9cf055c22b g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x2722b)
#3 0x00007f9cf05c5393 g_thread_pool_spawn_thread (libglib-2.0.so.0 + 0x90393)
#4 0x00007f9cf05c1523 g_thread_proxy (libglib-2.0.so.0 + 0x8c523)
#5 0x00007f9cef475897 start_thread (libc.so.6 + 0x8e897)
#6 0x00007f9cef4fc80c __clone3 (libc.so.6 + 0x11580c)
```
![image](/uploads/eefb70ce20b3269f9c030a1cf4f2ecc5/image.png)https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/124Regression in the Print portal's dialog ?2024-03-05T06:00:19ZLarina LoriaselRegression in the Print portal's dialog ?# The issue :
I have found out that the GTK print portal's dialog has regressed functionality compared to KDE's or GTK3/native print dialogs.
So far I have tested this on :
1. Evince (Flathub)
2. Okular (Flathub)
3. Evince (Fedora nativ...# The issue :
I have found out that the GTK print portal's dialog has regressed functionality compared to KDE's or GTK3/native print dialogs.
So far I have tested this on :
1. Evince (Flathub)
2. Okular (Flathub)
3. Evince (Fedora native, inside a distrobox)
## Here is the print dialog for Evince (Flathub) :
![Screenshot_from_2024-03-05_11-25-00](/uploads/123144c9be9decfacc72ec7597a51339/Screenshot_from_2024-03-05_11-25-00.png)
## Here is the print dialog for Okular (Flathub) :
![Screenshot_from_2024-03-05_11-30-42](/uploads/0b504080dd05d36574df63b481d22d37/Screenshot_from_2024-03-05_11-30-42.png)
## Here is the print dialog for Evince (Fedora native) :
![Screenshot_from_2024-03-05_11-47-40](/uploads/28504aec1c7ef8a97409d3043ee56ebc/Screenshot_from_2024-03-05_11-47-40.png)
As you can see, I cannot configure the "Only print" option in Evince (Flathub) which uses the print portal.
My printer only prints single-sided, so I have to manually duplex print (manually print all the odd pages first, then all the even pages).
The Print dialog of GNOME's desktop portal being broken has resulted in me unable to print double-sided documents via manual duplex printing.
Meanwhile, both Okular (Flathub) and Evince (Fedora native) have functioning "Only print" option.
The print portal issue also appears when using the NAPS2 Flatpak ( https://www.naps2.com/download )
My printer model is Epson L3110, the driver is downloaded from fedora repos, epson-inkjet-printer-escpr
# System Details Report
---
## Report details
- **Date generated:** 2024-03-05 11:49:34
## Hardware Information:
- **Hardware Model:** Hewlett-Packard HP ProBook 4540s
- **Memory:** 6.0 GiB
- **Processor:** Intel® Core™ i5-3210M × 4
- **Graphics:** Intel® HD Graphics 4000 (IVB GT2)
- **Disk Capacity:** 256.1 GB
## Software Information:
- **Firmware Version:** 68IRR Ver. F.68
- **OS Name:** Fedora Linux 39.20240304.0 (Silverblue)
- **OS Build:** (null)
- **OS Type:** 64-bit
- **GNOME Version:** 45.4
- **Windowing System:** Wayland
- **Kernel Version:** Linux 6.7.6-200.fc39.x86_64https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/122Context menu entries are greyed out on grid view2024-02-16T20:58:00ZFelix Häckerhaeckerfelix@gnome.orgContext menu entries are greyed out on grid view![image](/uploads/4ecd1bdb431e36e21191446b40cd9bd6/image.png)
List view works:
![image](/uploads/14c54b26a70805dff67d062455777b4b/image.png)
Looks like some actions / signals aren't connected for the grid view
```
xdg-desktop-portal-g...![image](/uploads/4ecd1bdb431e36e21191446b40cd9bd6/image.png)
List view works:
![image](/uploads/14c54b26a70805dff67d062455777b4b/image.png)
Looks like some actions / signals aren't connected for the grid view
```
xdg-desktop-portal-gnome-45.1-1.fc39.x86_64
```https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/121GNOME Background Apps (Flatpak) did not shown the correct number of apps2024-02-16T11:25:10ZMoritz SGNOME Background Apps (Flatpak) did not shown the correct number of apps### Affected version
- Arch Linux
- GNOME 45.4 (Wayland)
- Same issue with disabled extensions
- Same issue on X11
### Bug summary
I have 3 Flatpak apps (pika backup, geary, keepassxc) that start automatically. However, when I start G...### Affected version
- Arch Linux
- GNOME 45.4 (Wayland)
- Same issue with disabled extensions
- Same issue on X11
### Bug summary
I have 3 Flatpak apps (pika backup, geary, keepassxc) that start automatically. However, when I start GNOME, I always see only one application (Pika Backup) at the beginning, even though the others are running (checked with btop). When I briefly bring one application to the foreground, GNOME seems to update and then displays all 3.
### Steps to reproduce
1. Reboot
2. Check Background Apps (1)
3. Open one of the background apps
4. ... GNOME seems to update the background processes now ...
5. Check Background Apps (3)
### What happened
Only 1 app is shown
### What did you expect to happen
3 apps should shown
### Relevant logs, screenshots, screencasts etc.
![Bildschirmaufzeichnung_vom_2024-02-16__00-06-00](/uploads/94eb77fd8e446636f73a19ed1fd88787/Bildschirmaufzeichnung_vom_2024-02-16__00-06-00.webm)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/12045.1: is not gcc 14.x ready2024-01-31T15:03:32ZTomasz Kłoczko45.1: is not gcc 14.x readyLooks like last version build fails with latest gcc 14.x which is now used in fedora rawhide.
<details>
<summary>Build fails with</summary>
```console
[tkloczko@pers-jacek x86_64-redhat-linux-gnu]$ ninja -k 0
[1/2] Compiling C object s...Looks like last version build fails with latest gcc 14.x which is now used in fedora rawhide.
<details>
<summary>Build fails with</summary>
```console
[tkloczko@pers-jacek x86_64-redhat-linux-gnu]$ ninja -k 0
[1/2] Compiling C object src/xdg-desktop-portal-gnome.p/inputcapture.c.o
FAILED: src/xdg-desktop-portal-gnome.p/inputcapture.c.o
/usr/bin/gcc -Isrc/xdg-desktop-portal-gnome.p -Isrc -I../src -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gio-unix-2.0 -I/usr/include/gtk-4.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo -I/usr/include/graphene-1.0 -I/usr/lib64/graphene-1.0/include -I/usr/include/gtk-4.0/unix-print -I/usr/include/gsettings-desktop-schemas -I/usr/include/gnome-desktop-4.0 -I/usr/include/libadwaita-1 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -DHAVE_GTK_X11 -DHAVE_GTK_WAYLAND -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O2 -g -grecord-gcc-switches -pipe -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdata-sections -ffunction-sections -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -flto=auto -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -Wall -Werror=format-security -Os -mfpmath=sse -msse -msse2 -mfpmath=sse -msse -msse2 -mfpmath=sse -msse -msse2 -MD -MQ src/xdg-desktop-portal-gnome.p/inputcapture.c.o -MF src/xdg-desktop-portal-gnome.p/inputcapture.c.o.d -o src/xdg-desktop-portal-gnome.p/inputcapture.c.o -c ../src/inputcapture.c
In file included from /usr/lib64/glib-2.0/include/glibconfig.h:9,
from /usr/include/glib-2.0/glib/gtypes.h:34,
from /usr/include/glib-2.0/glib/galloca.h:34,
from /usr/include/glib-2.0/glib.h:32,
from ../src/inputcapture.h:21,
from ../src/inputcapture.c:21:
../src/inputcapture.c: In function ‘input_capture_dialog_handle_free’:
../src/inputcapture.c:92:20: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
92 | g_clear_pointer ((GtkWindow**)&dialog_handle->dialog, gtk_window_destroy);
/usr/include/glib-2.0/glib/gmacros.h:871:47: note: in definition of macro ‘G_STATIC_ASSERT’
871 | #define G_STATIC_ASSERT(expr) _Static_assert (expr, "Expression evaluates to false")
| ^~~~
../src/inputcapture.c:92:3: note: in expansion of macro ‘g_clear_pointer’
92 | g_clear_pointer ((GtkWindow**)&dialog_handle->dialog, gtk_window_destroy);
| ^~~~~~~~~~~~~~~
In file included from /usr/include/glib-2.0/glib/gatomic.h:30,
from /usr/include/glib-2.0/glib/gthread.h:34,
from /usr/include/glib-2.0/glib/gasyncqueue.h:34,
from /usr/include/glib-2.0/glib.h:34:
../src/inputcapture.c:92:20: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
92 | g_clear_pointer ((GtkWindow**)&dialog_handle->dialog, gtk_window_destroy);
/usr/include/glib-2.0/glib/glib-typeof.h:39:36: note: in definition of macro ‘glib_typeof’
39 | #define glib_typeof(t) __typeof__ (t)
| ^
../src/inputcapture.c:92:3: note: in expansion of macro ‘g_clear_pointer’
92 | g_clear_pointer ((GtkWindow**)&dialog_handle->dialog, gtk_window_destroy);
| ^~~~~~~~~~~~~~~
../src/inputcapture.c: In function ‘create_input_capture_dialog’:
../src/inputcapture.c:412:46: error: passing argument 2 of ‘gtk_window_group_add_window’ from incompatible pointer type [-Wincompatible-pointer-types]
412 | gtk_window_group_add_window (window_group, dialog);
| ^~~~~~
| |
| GtkWidget * {aka struct _GtkWidget *}
In file included from /usr/include/gtk-4.0/gtk/gtk.h:304,
from ../src/inputcapturedialog.h:21,
from ../src/inputcapture.c:22:
/usr/include/gtk-4.0/gtk/gtkwindowgroup.h:71:70: note: expected ‘GtkWindow *’ {aka ‘struct _GtkWindow *’} but argument is of type ‘GtkWidget *’ {aka ‘struct _GtkWidget *’}
71 | GtkWindow *window);
| ~~~~~~~~~~~~~~~~~~~~^~~~~~
../src/inputcapture.c:433:3: warning: ‘gtk_widget_show’ is deprecated: Use 'gtk_widget_set_visible or gtk_window_present' instead [-Wdeprecated-declarations]
433 | gtk_widget_show (dialog);
| ^~~~~~~~~~~~~~~
In file included from /usr/include/gtk-4.0/gtk/gtkapplication.h:26,
from /usr/include/gtk-4.0/gtk/gtkwindow.h:32,
from /usr/include/gtk-4.0/gtk/gtkaboutdialog.h:29,
from /usr/include/gtk-4.0/gtk/gtk.h:33:
/usr/include/gtk-4.0/gtk/gtkwidget.h:271:12: note: declared here
271 | void gtk_widget_show (GtkWidget *widget);
| ^~~~~~~~~~~~~~~
ninja: build stopped: cannot make progress due to previous errors.
```
</details>https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/118Major VRAM + RAM leak in FileChooser Portal2024-01-31T23:58:45ZJohnny A.Major VRAM + RAM leak in FileChooser PortalTook a while to figure out why my system was constantly running out of VRAM.
It's a leak in xdg-desktop-portal-gnome. The leaked memory is never returned. And it is a _major_ impediment for game performance. Not to mention that AI tools...Took a while to figure out why my system was constantly running out of VRAM.
It's a leak in xdg-desktop-portal-gnome. The leaked memory is never returned. And it is a _major_ impediment for game performance. Not to mention that AI tools will _constantly_ complain about "no available VRAM" due to xdg-desktop-portal-gnome hogging it all.
I run into this issue every day, since its memory leak grows so fast.
- Affected systems: Fedora 38, Fedora 39, both using Xorg.
- `/usr/libexec/xdg-desktop-portal-gnome --version: xdg-desktop-portal-gnome 45.1` (Fedora 39), `xdg-desktop-portal-gnome-44.2-1.fc38` (Fedora 38).
- `sudo dnf list "gtk4*": 4.12.4-1.fc39`
Every time the FileChooser dialog opens, it leaks memory proportional to how many thumbnails are in the dialog. Scrolling past the thumbnails further leaks a bit more memory (compared to just closing the dialog immediately).
I wrote a small test application and recorded the VRAM + RAM growth over time. In this particular example, it grows VRAM by 25-30 MiB per dialog (~25 MiB if you close it immediately, ~30 MiB if you scroll past more thumbnails before closing it), but there's some variability going on because I have actually seen it grow by 100+ MiB VRAM *every* time the FileChooser is used, in other sessions!
I've recorded video of the leak in action. At the end, **xdg-desktop-portal-gnome is using 5202 MiB VRAM and 2740 MiB System RAM,** and those numbers will just continue growing over time as the system is being used more.
If this particular example video had grown at the higher "~100 MiB VRAM leak per dialog" rate which I have *often* observed, then we would actually have ended up at **20808 MiB VRAM leaked.** Which I have encountered many times, and that is indeed a problem for computer stability. ;)
Releasing the leaked memory can only be done via `systemctl restart --user xdg-desktop-portal-gnome`.
Test application and video are attached below. Hopefully they help with debugging.
[portalleak.py](/uploads/e0f5764a0e4a1624379884ae6117e63f/portalleak.py)
![xdg-gnome-leak](/uploads/ef2b8c86057e06e53b317a91b922010c/xdg-gnome-leak.mp4)https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/114"Allow remote interaction" popup triggers for no good reason2024-01-11T19:25:08ZMatti Pulkkinen"Allow remote interaction" popup triggers for no good reason![Screenshot_from_2023-12-16_22-25-14](/uploads/8a8bd898b65acb234627f36d29bf374c/Screenshot_from_2023-12-16_22-25-14.png)
This popup triggers for me quite often even though I'm not using any remote desktop functionality. For some reason...![Screenshot_from_2023-12-16_22-25-14](/uploads/8a8bd898b65acb234627f36d29bf374c/Screenshot_from_2023-12-16_22-25-14.png)
This popup triggers for me quite often even though I'm not using any remote desktop functionality. For some reason it seems to trigger especially if I input anything on a game controller while not focused on a game window.
As mentioned, I don't use remote desktop functionality, and I have never done that on this PC. I'm not familiar with this technology, so apologies if this issue is sparse with details. I'll be happy to add anything as requested.
<details><summary>System info</summary>
```
System:
Kernel: 6.6.6-200.fc39.x86_64 arch: x86_64 bits: 64 Desktop: GNOME v: 45.2
Distro: Fedora release 39 (Thirty Nine)
Machine:
Type: Desktop Mobo: ASRock model: X570 Taichi serial: <superuser required>
UEFI: American Megatrends v: P5.50 date: 10/13/2023
Battery:
ID-1: hidpp_battery_0 charge: 92% condition: N/A
CPU:
Info: 8-core model: AMD Ryzen 7 5800X3D bits: 64 type: MT MCP cache:
L2: 4 MiB
Speed (MHz): avg: 2317 min/max: 550/4550 cores: 1: 3598 2: 4448 3: 3598
4: 3596 5: 3597 6: 550 7: 550 8: 550 9: 550 10: 550 11: 550 12: 3597
13: 3600 14: 3598 15: 3599 16: 550
Graphics:
Device-1: AMD Navi 31 [Radeon RX 7900 XT/7900 XTX] driver: amdgpu v: kernel
Device-2: Realtek [] driver: snd-usb-audio,uvcvideo type: USB
Display: wayland server: X.Org v: 23.2.2 with: Xwayland v: 23.2.2
compositor: gnome-shell driver: X: loaded: amdgpu
unloaded: fbdev,modesetting,radeon,vesa dri: radeonsi gpu: amdgpu
resolution: 1: 2560x1440~120Hz 2: 2560x1440~75Hz
API: OpenGL v: 4.6 vendor: amd mesa v: 23.3.0 renderer: AMD Radeon RX
7900 XT (radeonsi navi31 LLVM 17.0.6 DRM 3.54 6.6.6-200.fc39.x86_64)
API: EGL Message: EGL data requires eglinfo. Check --recommends.
Audio:
Device-1: AMD Navi 31 HDMI/DP Audio driver: snd_hda_intel
Device-2: AMD Starship/Matisse HD Audio driver: snd_hda_intel
Device-3: HP [] driver: cdc_acm,hid-generic,snd-usb-audio,usbhid type: USB
Device-4: Realtek [] driver: snd-usb-audio,uvcvideo type: USB
API: ALSA v: k6.6.6-200.fc39.x86_64 status: kernel-api
Server-1: PipeWire v: 1.0.0 status: active
Network:
Device-1: Intel Wi-Fi 6 AX200 driver: iwlwifi
IF: wlp5s0 state: down mac: <filter>
Device-2: Intel I211 Gigabit Network driver: igb
IF: enp7s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Bluetooth:
Device-1: Intel AX200 Bluetooth driver: btusb type: USB
Report: btmgmt ID: hci0 state: up address: <filter> bt-v: 5.2
Drives:
Local Storage: total: 3.64 TiB used: 2.47 TiB (67.8%)
ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 990 PRO 4TB size: 3.64 TiB
Partition:
ID-1: / size: 3.64 TiB used: 2.47 TiB (67.8%) fs: btrfs dev: /dev/dm-0
ID-2: /boot size: 973.4 MiB used: 351.3 MiB (36.1%) fs: ext4
dev: /dev/nvme0n1p2
ID-3: /boot/efi size: 598.8 MiB used: 17.4 MiB (2.9%) fs: vfat
dev: /dev/nvme0n1p1
ID-4: /home size: 3.64 TiB used: 2.47 TiB (67.8%) fs: btrfs dev: /dev/dm-0
Swap:
ID-1: swap-1 type: zram size: 8 GiB used: 20.8 MiB (0.3%) dev: /dev/zram0
Sensors:
System Temperatures: cpu: 37.0 C mobo: 37.0 C gpu: amdgpu temp: 74.0 C
Fan Speeds (rpm): fan-1: 574 fan-2: 0 fan-3: 884 fan-4: 541 fan-5: 539
fan-6: 2596 fan-7: 520 gpu: amdgpu fan: 899
Info:
Processes: 521 Uptime: 20h 37m Memory: total: 32 GiB available: 31.27 GiB
used: 10.22 GiB (32.7%) Shell: Zsh inxi: 3.3.31
```
</details>https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/111[Keyboard Navigation] Clunky controls to Share/Cast windows2023-12-21T09:13:45ZAman Das[Keyboard Navigation] Clunky controls to Share/Cast windowsCurrently, the Screen Share/Cast dialog box requires one to select the desired App with a mouse click and then click the "Share" button.
Many people share the screen while using other input methods. I use a graphics tablet while teaching...Currently, the Screen Share/Cast dialog box requires one to select the desired App with a mouse click and then click the "Share" button.
Many people share the screen while using other input methods. I use a graphics tablet while teaching and need to share the screen frequently.
I am afraid this dialog alone leads to a lot of unnecessary strain on my wrists, since I am in a hurry to not lose precious online teaching time.
Using a keyboard, only the first window can be selected. (Shift+Tab moves up to the "Share" button)
This dialog is an essential piece of GNOME experience.
Given the recent work on ["Open With" dialogs](https://gitlab.gnome.org/Teams/Design/os-mockups/-/commit/9e2bed6f37030dbf7d82087623f266d3c012c949), I think this dialog also deserves usability improvements.
Summary:
- The "Screen Share" dialog box requires mouse and 2 clicks.
- This creates friction, especially for those sharing the screen regularly.
- Double Click/Tap to select and share the window/monitor would be a godsend.
- Keyboard control is broken, only the first item in the list can be selected via keyboard.
![Screenshot_from_2023-12-02_02-39-38](/uploads/32f8b72caa4302c42e6abb62416371ff/Screenshot_from_2023-12-02_02-39-38.png)https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/115Location portal doesn't show what the location is2023-12-31T17:05:37ZAllan DayLocation portal doesn't show what the location isThe current location portal dialog asks to share the location, but doesn't show what the location is. This is an issue for a few reasons:
* From a privacy perspective, it's not clear what information you're agreeing to share
* The use...The current location portal dialog asks to share the location, but doesn't show what the location is. This is an issue for a few reasons:
* From a privacy perspective, it's not clear what information you're agreeing to share
* The user has no way of knowing if the current location is wrong - which can cause issues if the location is way off
Adding a location preview to the dialog would solve these issues and is consistent with how other platforms present location permission:
![image](/uploads/bc9dae066398e3c558ed4cb1319270dd/image.png)
(See [the portals mockups](https://gitlab.gnome.org/Teams/Design/os-mockups/-/blob/master/portals/portals.png?ref_type=heads) for up to date guidance.)https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/106Screenshot: "Grab after a delay of" isn't using AdwSpinRow2023-11-07T00:38:54ZAutomeris naranjaScreenshot: "Grab after a delay of" isn't using AdwSpinRow## Affected version
Main (Git)
## Description
In the Screenshot window, the "Grab after a delay of" option isn't using AdwSpinRow:
![image](/uploads/6cb19ae23a84389a9418bf7a4a0ddf3e/image.png)## Affected version
Main (Git)
## Description
In the Screenshot window, the "Grab after a delay of" option isn't using AdwSpinRow:
![image](/uploads/6cb19ae23a84389a9418bf7a4a0ddf3e/image.png)https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/104xdg-desktop-portal-gnome 45.0 causing long delays in app launch on X11 and Wa...2024-01-02T19:19:29ZKen Gilmerxdg-desktop-portal-gnome 45.0 causing long delays in app launch on X11 and Wayland sessions in Debian and UbuntuRegolith is a "hybrid" DE that bridges GNOME to tiling window managers i3 (x11) and Sway (Wayland). N.B. Regolith does not use `gnome-shell`, but does use other GNOME components such as `gnome-control-center`. In testing the next Rego...Regolith is a "hybrid" DE that bridges GNOME to tiling window managers i3 (x11) and Sway (Wayland). N.B. Regolith does not use `gnome-shell`, but does use other GNOME components such as `gnome-control-center`. In testing the next Regolith release, [an issue](https://github.com/regolith-linux/regolith-desktop/issues/936) was found in that apps take very long to start.
In researching the problem, very [helpful](https://github.com/linuxmint/cinnamon/issues/11857) information was found (provided by @smcv) for how other DEs are migrating to this version of `xdg-desktop-portal-gnome`. However, I'm unable to find a configuration that resolves the issue for Regolith, for either session. I've tested variations on Cinnamon and [Budgie's](https://github.com/BuddiesOfBudgie/budgie-desktop/blob/main/data/budgie-portals.conf) and [Sway](https://github.com/emersion/xdg-desktop-portal-wlr)'s config without success.
Regolith x11 XDG_CURRENT_DESKTOP: `Regolith:GNOME-Flashback:GNOME` (last element is set by `gnome-session`, does not seem to be changeable)
Regolith Sway XDG_CURRENT_DESKTOP: `Regolith:sway:GNOME`
Though this issue manifests itself in both sessions, it's expected that `xdg-desktop-portal` configuration will vary between the two sessions. Any fixes or suggestions to resolve this issue in both/either of these sessions would be greatly appreciated.https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/101"to open file.extension" sentence2024-03-03T16:26:17ZGhost User"to open file.extension" sentenceHello, the following sentence is in src/appchooserdialog.ui:85
```xml
<property name="title" translatable="yes">No Apps Available</property>
<property name="description" translatable="yes">No apps installed that are able to open file.ex...Hello, the following sentence is in src/appchooserdialog.ui:85
```xml
<property name="title" translatable="yes">No Apps Available</property>
<property name="description" translatable="yes">No apps installed that are able to open file.extension.
You can find more apps in Software.</property>
```
A teammate suggested changing its translation to "this file extension" would be more appropriate.https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/100App chooser: can't search for apps2023-10-29T23:54:10ZAutomeris naranjaApp chooser: can't search for apps## Affected version
xdg-desktop-portal-gnome-45.0-1.fc39.x86_64
## Description
When choosing an app, there is no search function:
![image](/uploads/0ec95bc6555f5630bca60ae6c6b68dfb/image.png)
Searching would be useful here when the ap...## Affected version
xdg-desktop-portal-gnome-45.0-1.fc39.x86_64
## Description
When choosing an app, there is no search function:
![image](/uploads/0ec95bc6555f5630bca60ae6c6b68dfb/image.png)
Searching would be useful here when the app list is long.https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/98Set Background window: allow cropping a wallpaper before applying it2023-10-06T23:11:48ZAutomeris naranjaSet Background window: allow cropping a wallpaper before applying it## Affected version
xdg-desktop-portal-gnome-45.0-1.fc39.x86_64
## Description
When setting a background, it isn't possible to crop the image according to the screen aspect ratio. It would be great to have this.## Affected version
xdg-desktop-portal-gnome-45.0-1.fc39.x86_64
## Description
When setting a background, it isn't possible to crop the image according to the screen aspect ratio. It would be great to have this.https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/96Last folder is not remembered with 45.beta2023-10-05T11:55:57ZAbrar AhmedLast folder is not remembered with 45.betaThere seems to have been a regression somewhere. I'm running Fedora 39 Silverblue and the portal doesn't seem to remember the last location any more. Can easily be reproduced with any flatpak app that uses the portal. Amberol, Text Edito...There seems to have been a regression somewhere. I'm running Fedora 39 Silverblue and the portal doesn't seem to remember the last location any more. Can easily be reproduced with any flatpak app that uses the portal. Amberol, Text Editor etc.https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/95Expose `button-layout` key on Settings portal2023-08-13T18:47:21ZDallas StrouseExpose `button-layout` key on Settings portalSee https://github.com/flatpak/xdg-desktop-portal/pull/996 for context.
All that needs to be done is to convert the gsettings key to a tuple of string arrays, which should be fairly easily scriptable, and to expose it via `org.freedeskt...See https://github.com/flatpak/xdg-desktop-portal/pull/996 for context.
All that needs to be done is to convert the gsettings key to a tuple of string arrays, which should be fairly easily scriptable, and to expose it via `org.freedesktop.appearance button-placement`https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/94xdg-desktop-portal-gnome making Firefox to start really slow, about 30 second...2023-12-21T02:29:22ZHei Torxdg-desktop-portal-gnome making Firefox to start really slow, about 30 seconds to start.I don't know from when it started not starting instantly. Maybe a month ago. But when I deleted `xdg-desktop-portal-gnome` firefox started instantly. As this package might be interesting for other software, I reinstalled it and used the ...I don't know from when it started not starting instantly. Maybe a month ago. But when I deleted `xdg-desktop-portal-gnome` firefox started instantly. As this package might be interesting for other software, I reinstalled it and used the option `widget.use-xdg-desktop-portal.settings=0` in the tab `about:config` in Firefox as described here:
https://bbs.archlinux.org/viewtopic.php?id=275618
and here:
https://www.reddit.com/r/firefox/comments/vqr0zu/firefox_nightly_very_slow_to_start_on_linux/
Some people may be facing the same problem, so I'm just reporting. Hope you guys can fix this soon, if there is anything to fix in xdg-desktop-portal.
Cheers.https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/92filechooser and document portal acts weirdly with symlink2023-07-27T08:01:40ZZhafran Rama Azmifilechooser and document portal acts weirdly with symlink## System Information
Distro : Arch Linux
GNOME : 44.3
Display Server : Wayland
## Version
xdg-desktop-portal = 1.16.0
xdg-desktop-portal-gtk = 1.14.1
xdg-desktop-portal-gnome = 44.1
## Description
So I have a folder `~/.local/shar...## System Information
Distro : Arch Linux
GNOME : 44.3
Display Server : Wayland
## Version
xdg-desktop-portal = 1.16.0
xdg-desktop-portal-gtk = 1.14.1
xdg-desktop-portal-gnome = 44.1
## Description
So I have a folder `~/.local/share/anime-game-launcher`
I symlink this to `~/.var/app/moe.launcher.an-anime-game-launcher/data/anime-game-launcher`
On GNOME, if I try to open `~/.var/app/moe.launcher.an-anime-game-launcher/data/anime-game-launcher/config.json`
after adding a filesystem override to `~/.local/share/anime-game-launcher`, it fails to open
but if i block `~/.local/share/anime-game-launcher`, it opens fine
![Bug on GNOME](https://user-images.githubusercontent.com/80886145/256280144-2a38bb16-4acf-4afe-a4d3-46d53759dfae.webm)
does not happen on `xdg-desktop-portal-kde`
![No Bug on KDE](https://user-images.githubusercontent.com/80886145/256282889-b65c6ccd-450c-45b1-b6aa-994d2e0ce320.webm)
- Permission of affected file : 0644/-rw-r--r--
- Permission of folder of the affected file : 0755/drwxr-xr-xhttps://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/93Screen share dialog resets selection on window title change2024-03-22T22:42:02ZRussell SmallScreen share dialog resets selection on window title change### Affected version
Arch Linux running Gnome 44 (Mutter v44.3-1)
### Bug summary
When selecting a window to screen share via Open Broadcaster Software (OBS)'s Window Share (Pipewire) feature, Mutter's Screen Share menu will reset your...### Affected version
Arch Linux running Gnome 44 (Mutter v44.3-1)
### Bug summary
When selecting a window to screen share via Open Broadcaster Software (OBS)'s Window Share (Pipewire) feature, Mutter's Screen Share menu will reset your selection to the first option whenever any window's title changes.
### Steps to reproduce
1. Using Gnome on Wayland, run OBS side by side with an application which has a dynamic title (I.E. Firefox, Gnome Files), as well as a few other windows to populate the Select Window menu.
2. Add a Window Capture (Pipewire) component to OBS, and open the Select Window menu.
3. Select a window to screen share but do not click Share or Close.
4. Change the title of a different window through any means (Open a folder in Gnome Files, browse to another page in Firefox)
Observe that your selected window has been reset.
### What happened
The selected window in the Screen Share menu has been reset - To either nothing, or the first option depending on if the menu has focus.
### What did you expect to happen
I expect the selected window to remain selected in the Screen Share Menu.
### Relevant logs, screenshots, screencasts etc.
Video of the issue in real time: https://youtu.be/TYGY32GLsBU
OBS Project Issue where they suggested I reach out here: https://github.com/obsproject/obs-studio/issues/9281
<!-- Do not remove the following line. -->