Open svin24 opened 4 years ago
im pretty sure this is limited by chromium/nodejs/Electron which is what the steam application is using.
Hi, I'd like to chime in on this issue, because it's actually pretty important for a few reasons.
First off, Steam's custom file and directory choosers stink. They show hidden files and folders by default, they start in a really inane location, and they are bound to any container they happen to be running in. Any time I have to use Steam's choosers, I'm having a bad time.
Second, there are many benefits to switching to xdg-dekstop-portal's file chooser portal. The first one is that you get a native dialog to whatever desktop environment the user is running. GNOME's chooser, KDE's chooser, and for users running in minimalist environments, there's even a terminal-based chooser. The second is that all the issues with Steam's built-in choosers disappear because it's not being used anymore.
The third is that the portal has special functionality when the app calling out to it is containerized, like in a Flatpak. The community-maintained Flathub package for Steam currently has to be used with Flatseal if you want to keep your games in a location other than ~/.var/app/com.valvesoftware.Steam
, and then you have to use Steam's chooser to add it as a library folder. But there is a special feature for the directory chooser; any location chosen with it will be remembered and auto-mounted for every subsequent run of the Flatpak. I learned about this a while back with an issue for an AppImage software center in Flathub. If the directory chooser portal is used, then use of Flatseal to safely expose game library directories should no longer be needed at all, dramatically improving the out-of-the-box experience.
This wouldn't be the case on any modern Linux system, but if the xdg-desktop-portal was just entirely absent, you could fall back to the built-in chooser. There is also a shortcut for implementing the portal in case Steam's toolkit is indeed a limiting factor; AppImagePool just calls out to Zenity to do file picking, which already integrates the chooser portals. Zenity is in the FreeDesktop.org runtime.
I'm personally of the mind that Steam-as-Flatpak is a good future to work toward for non-SteamOS distros. I've used it for years on all my setups to great success. So I have particular investment in seeing this improved.
Doesn't Steam already use xdg-desktop-portal for Steam Remote Play? If they can add support for xdg-desktop-portal in remote play, why can't they support portals for native file dialogs?
Hopping on to show my support for using xdg-dekstop-portal
's file chooser.
Okay, so that shiny new beta has file chooser portal integration! That's awesome!! Huge ups to you all for taking this on.
I decided to try removing the permissions I added to Steam's Flathub package via Flatseal, and instead use the portal to select my main game folder. It sorta works, but mostly doesn't. So, the document portal creates a new mountpoint at /run/user/1000/doc/b5a99c0e
where the folder I selected is bind-mounted there. If I select "browse folder" from the three-dot menu, my file manager opens up and shows me the steamapps subdirectory and everything that's already in there. And when I exit and relaunch steam, the directory is re-mounted just fine. But Steam thinks there are no games in there!
When I run Steam in the terminal, I notice a bunch of error messages for each app manifest in the library: flock /run/user/1000/doc/b5a99c0e/pc/steamapps/appmanifest_207140.acf LOCK_SH failed. errno = 38
and they're not separated by line breaks.
As this is one of the factors that was severely hampering the experience for the Flathub package, I'd love to do what I can to help get this working. What else do you need from me? I can get on Flathub's matrix channel tomorrow and see what they know; if there is something Steam should be doing differently, or if a bug should be filed in xdg-desktop-portal.
im pretty sure this is limited by chromium/nodejs/Electron which is what the steam application is using.
I just wanted to note that this was incorrect in 2020, it mostly used a custom UI built on top of SDL2, but they've been moving it over to CEF/Awesomium since. It started with the friends list and the library folder overview, the latest beta client almost exclusively uses the new web-based UI.
I decided to try removing the permissions I added to Steam's Flathub package via Flatseal, and instead use the portal to select my main game folder. It sorta works, but mostly doesn't.
@HugLifeTiZ This seems to be the very issue I encountered upon a clean install of the Steam Flatpak the other day. I quickly realized that the portal doesn't work as intended, but even after overriding the permissions, and reinstalling the games, Proton refused to work. It took even more tinkering to make everything operable.
@kisak-valve Apologies for the mention, but could this be escalated? This here is a footgun.
The Flatpak portal issues are probably on xdg-desktop-portal to address somehow. Error code 38 means not implemented, which means they just didn't implement file locking for the document portal. Valve could submit a PR to xdg-desktop-portal implementing file locking, or they could just not try to lock files.
In any case, for now, you still have to use filesystem overrides. They should be done before you add the relevant paths to your library. I think it will still try to use the document portal to access the library if you add the filesystem override afterward.
Your system information
Please describe your issue in as much detail as possible:
It would be better if the user could opt in to use more system native options like the GTKfilechooser, the QT file chooser. They dont have to be required to install steam just let the user call them if they are available.