Pages: 1
Not related to https://bbs.archlinux.org/viewtopic.php?id=313883, AFAIK.
OS: Arch Linux x86-64
DE: XFCE 4.20
DE themes used: Adwaita (day), Adwaita-Dark (night)
Some problems appeared since update to xdg-desktop-portal 1.22.0. Downgrading to 1.20.4 fixes all of these.
Problem 1
In the Open/Save GTK dialog, pressing the Enter key when the text field has the focus does nothing anymore (it does not act as if I click on “Open“ or “Save”). I have to click on “Save” to confirm.
Plus, when a file already exists with the same name, there is no overwriting confirmation dialog anymore: it saves it immediately.
Problem 2
Open GIMP (set to theme “System” and color scheme “System colors”).
With Adwaita (light), it should open with a light theme, and switch to a dark theme only with Adwaita-Dark.
Instead, it always opens with a dark theme (I have to set it to “Light colors” to force it to switch to the light theme).
Problem 3
Open LibreOffice.
With Adwaita-Dark, even if Tools > Options > Appearance > Use white document background is disabled, it still shows the document backgound in white and not dark.
Trit wrote:
In the Open/Save GTK dialog, pressing the Enter key when the text field has the focus does nothing anymore
Cannot repro. Hitting Enter WFM.
Trit wrote:
when a file already exists with the same name, there is no overwriting confirmation dialog anymore
Cannot repro. Overwrite confirmation dialog appears.
Trit wrote:
Open GIMP (set to theme “System” and color scheme “System colors”).
Cannot repro. Light color scheme persists app restarts.
Trit wrote:
Open LibreOffice.
With Adwaita-Dark, even if Tools > Options > Appearance > Use white document background is disabled, it still shows the document backgound in white and not dark.
Cannot repro. After prompting for restart of the app, document color is dark.
Are you sure the portals are running?
systemctl --user status xdg-desktop-portal.service xdg-desktop-portal-gtk.service
Do you have screenshots of the dialogs w/ either version?
1a) might just be focus policy (stealing prevention/window parenting) but the rest, notably the overwrite behavior, sounds as if you're using a completely different implementation.
seth wrote:
1a) might just be focus policy (stealing prevention/window parenting) but the rest...
Nope. Both 1a and 1b are consistent with the default behavior of native fallback dialogs, aka window class "GTK Application".
I suspect OP is aware of the recent breakage, but did not implement a working override for xdg-desktop-portal.service.
I've no portal, if I hit ctrl+s and then enter this webpage gets saved. If I repeat that I get asked about the overwrite.
Also why would the native/fallback dialog ignore the color schemes?
seth wrote:
I've no portal, if I hit ctrl+s and then enter this webpage gets saved. If I repeat that I get asked about the overwrite.
1a) Trigger a download... e.g. download a package tar. Hitting Enter should be ignored with no portal*.
1b) Name the download. Download it a 2nd time with the same modified name. No confirmation, and * (1).* is appended to the filename.
Having just recently lived a year without portals this was the (annoying) behavior I'm familiar with.
* It's also application-dependent. I use Brave/Chromium. I suspect you're using Firefox.
Window class "GTK Application" is the last stop when a GTK app cannot find a portal or app-native file chooser.
seth wrote:
Also why would the native/fallback dialog ignore the color schemes?
This I've no clue how it's even related.
I simply attempted to repro the OP's claims and could not repro #2 or #3.
Vivaldi, and the dialog gets the focus and save is the active button - this might completely hinge on the window managers focus management, though.
1b) actually differs between page saving (collision resolution) and link download "(1)"
seth wrote:
this might completely hinge on the window managers focus management, though.
Possibly. Focus stealing prevention is disabled in my envs... i.e. focus stealing is enabled:
Hypr:
hl.config({
misc = {
focus_on_activate = true
},
})Sway:
focus_on_window_activation focusFrom taming these dialogs with window rules, in order of preferred precedence (portal -> app -> fallback):
Hypr (including old hyprlang rules from before my move to portals):
hl.window_rule({ match = { class = "xdg-desktop-portal-gtk", title = ".*wants to.*" }, float = true, center = true, size = "1280 1024" })
windowrule = float on, center on, size 1280 1024, match:class brave, match:title .*wants to.*
windowrule = float on, center on, size 1280 1024, match:class GTK Application, match:title .*wants to.*Sway:
for_window [app_id="xdg-desktop-portal-gtk"] floating enable, border pixel 2, resize set 1200 960
for_window [app_id="brave" title="wants to"] floating enable, resize set 1200 960
for_window [app_id="GTK Application"] floating enable, resize set set 1200 960seth wrote:
1b) actually differs between page saving (collision resolution) and link download "(1)"
Yes, that's why I differentiated the two scenarios.
EDIT: Before we confuse anybody, per #2, with functional portals "collision resolution" works as expected in both scenarios.
Last edited by tekstryder (Today 00:08:09)
I just updated again to 1.22.0 and… it’s fine, now. No errors. Weird, but I won’t complain! ^^
tekstryder wrote:
Are you sure the portals are running?
systemctl --user status xdg-desktop-portal.service xdg-desktop-portal-gtk.service
Both are active and running.
seth wrote:
1a) might just be focus policy (stealing prevention/window parenting) but the rest, notably the overwrite behavior, sounds as if you're using a completely different implementation.
I always used the official repo packaged versions for xdg-desktop-portal.
Command output:
$ pacman -Qs portal
local/libportal 0.9.1-3
GIO-style async APIs for most Flatpak portals
local/libportal-gtk3 0.9.1-3
GIO-style async APIs for most Flatpak portals - GTK 3 backend
local/libportal-gtk4 0.9.1-3
GIO-style async APIs for most Flatpak portals - GTK 4 backend
local/xdg-desktop-portal 1.22.0-1
Desktop integration portals for sandboxed apps
local/xdg-desktop-portal-gtk 1.15.3-1
A backend implementation for xdg-desktop-portal using GTKI don’t understand what happened for the first update to be broken, but it looks like downgrading and updating again fixed the bug. Solved for me, a priori.
EDIT: I spoke too soon, because I did not have restarted the services yet, and one of them is broken:
$ systemctl --user status xdg-desktop-portal.service xdg-desktop-portal-gtk.service
○ xdg-desktop-portal.service - Portal service
Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal.service; static)
Active: inactive (dead)
juin 13 16:41:42 Primula systemd[665]: Dependency failed for Portal service.
juin 13 16:41:42 Primula systemd[665]: xdg-desktop-portal.service: Job xdg-desktop-portal.service/start failed with result 'dependency'.
juin 13 16:43:24 Primula systemd[665]: Dependency failed for Portal service.
juin 13 16:43:24 Primula systemd[665]: xdg-desktop-portal.service: Job xdg-desktop-portal.service/start failed with result 'dependency'.
juin 13 16:43:24 Primula systemd[665]: Dependency failed for Portal service.
juin 13 16:43:24 Primula systemd[665]: xdg-desktop-portal.service: Job xdg-desktop-portal.service/start failed with result 'dependency'.
juin 13 16:43:24 Primula systemd[665]: Dependency failed for Portal service.
juin 13 16:43:24 Primula systemd[665]: xdg-desktop-portal.service: Job xdg-desktop-portal.service/start failed with result 'dependency'.
juin 13 16:44:31 Primula systemd[665]: Dependency failed for Portal service.
juin 13 16:44:31 Primula systemd[665]: xdg-desktop-portal.service: Job xdg-desktop-portal.service/start failed with result 'dependency'.
● xdg-desktop-portal-gtk.service - Portal service (GTK/GNOME implementation)
Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal-gtk.service; static)
Active: active (running) since Sat 2026-06-13 16:41:42 CEST; 6min ago
Invocation: 69eb0121f84043feaf6448e8dcde7891
Main PID: 70956 (xdg-desktop-por)
Tasks: 6 (limit: 4615)
Memory: 5.4M (peak: 5.7M)
CPU: 124ms
CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/xdg-desktop-portal-gtk.service
└─70956 /usr/lib/xdg-desktop-portal-gtk
juin 13 16:41:42 Primula systemd[665]: Starting Portal service (GTK/GNOME implementation)...
juin 13 16:41:42 Primula systemd[665]: Started Portal service (GTK/GNOME implementation).Went back to 1.20.4, for now, with both services active and running well.
Screencaps can be seen here (1.22.0, broken):
https://rehost.diberie.com/Picture/Get/f/521162
https://rehost.diberie.com/Picture/Get/f/521163
For comparison, what it should have been (1.20.4, OK):
https://rehost.diberie.com/Picture/Get/f/521166
https://rehost.diberie.com/Picture/Get/f/521167
Last edited by Trit (Today 15:07:42)
tekstryder wrote:
I suspect OP is aware of the recent breakage, but did not implement a working override for xdg-desktop-portal.service.
Trit wrote:
spoke too soon, because I did not have restarted the services yet, and one of them is broken
This is well understood. Downgrading isn't a viable "solution".
I suggest you go back and check the forum thread you linked in the OP:
• https://bbs.archlinux.org/viewtopic.php?id=313883
Implement the drop-in service override whilst awaiting a longer-term solution either from upstream (highly unlikely):
• https://github.com/flatpak/xdg-desktop- … 4651275776
Or via Arch packaging patch:
I’ll try it. I was thinking it was possibly not related because I’m using XFCE and not Sway or Hyprland, but as it seems to be linked anyway…
Just so you know: the Enter key doing nothing in Save dialog seems to only occur in Vivaldi. It still worked in other apps (like Mousepad).
This issue affects any minimal compositor environment that does not reach graphical-session.target.
As for non-functional Enter key...
I was living with that behavior with Brave when I had no portals installed, before they were foisted upon us recently by GTK4.
Last edited by tekstryder (Today 15:43:50)
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。