[Linux] The file selection dialogue sucks. Like seriously.
One thing I personally dislike about the file selection dialogue is that you can't select another partition with one click like on the Windows client. That's annoying when I want to install games from a backup because I keep my game backups on a separate NTSC partition.
I don't think it should be too difficult to enable a drive selection similar to that of the Windows client because file browsers like Nautilus always show the available drives/partitions in the sidebar and they mount them automatically on selection. That would be really convenient, along with the already suggested selections like the user's home directory and other important directories.
@darealshinji, something like "df | grep -E "/dev/sda_|/dev/sdb_" (hda, hdb, hdc, hdd...)
" ?
@Tea23, current file selection is not so bad that it needs to be replaced by GTK/Qt but still some things can be done better:
- +1 for defaulting to /Pictures (see " cat $HOME/.config/user-dirs.dirs | grep "XDG_PICTURES_DIR"
" since this name is translated by default, e.g. I have ~/Obrazy instead) (or last used path?)- and all useful dirs on list (/. ~/images, ~/downloads, ~/documents etc.)
- Thumbnails: what about showing 128x128px popup of image under mouse pointer? ( I hope you get it )
- Ctrl-H for toggilng visibility of hidden files, for less junk on list (you usually search in "normal" folders but .local/steam is useful too)
- Filetype - I would suggest instead of dropdown something like "supported images" text and check file mimetype (yay for libfile-mimeinfo-perl and its mimetype command )
- About DUH-DING™ - for me most irritating is fact that when you minimize Steam with opened file selector when you click Steam on toolbar it plays DUH-DING™
I was just about to open a new issue for a feature request but then found this one :)
When clicking "choose file" to upload a profile picture it starts in some steam folder - I don't know where I am exactly because the path isn't shown anywhere. Starting in the users $HOME would make it easier to get where you want to go. Remembering the last used location would be even better.
If you want to parse the XDG directories you can use this code:
https://cgit.freedesktop.org/xdg/xdg-user-dirs/tree/xdg-user-dir-lookup.c
Or in case you want a more C++-ish solution:
https://gist.github.com/darealshinji/e5e6f85264a2c40eb26474d734f9d892
Also clicking to sort by Date Modified has no effect, further impacting usability.
I'm not sure the Gtk file picker is a 100% ideal solution as it currently doesn't fully support thumbnails either.
Would be nice to have drag and drop as an alternative method of selecting files, but this does not appear to be functioning under Linux Steam client.
Since this has been open for almost 3 years now can we get someone assigned to push something experimental to Beta? The Steam File Pickers flaws have only been amplified now that you are forced to use it if you want to upload something to Steam Chat.
GTK and QT offer good choices, although even just improving the current one built into steam would be better than nothing.
I too would like to see some work done on this. Simply defaulting to the Pictures folder is a huge step forward.
This is still a huge problem. We just tried to share a few screenshots and nobody of the linux users where able to find the directory. You literally need to know the FHS of linux.
6 years later and we're still dealing with the trash file selector? Every time I want to send an image via Steam chat, I need to fully traverse to my home directory, and the client doesn't remember the last directory I selected a file from. It's cumbersome as all hell. If I was able to use GNOME's/GTK's default file picker, it would make life so much easier. Like. There's still no image preview either.
Considering how long this issue has been open, I'm not convinced that this issue will ever be fixed.
One year later and the filepicker is still the most outdated part of the whole steam client.
Why is it so hard to get a new one?
+1
Waiting for this to change. Use XDG Portals :p
+1 Current one is terrible
Hint: parsing the XDG config file works really well using the MIT licensed simpleini library.
Possibly resolved? Using the newest steam client beta 1682634349, the file picker now uses native desktop file chooser portals. However, the portal seems to only allow selecting exes.
Can you click that x in the triangle-square to clear the filter?
Thank you to whomever worked on using portals file picker :pray:
Couple of issues I noticed in Steam beta 1682634349 Flatpak on Fedora 38:
- The file picker for selecting an executable to add a non-steam game only allows
.exe - In Steam Chat, "Upload an image" does nothing
- Adding a new library folder shows the file picker but nothing happens after selecting a folder
KDE File picker works on Steam Beta version 1682723851 (native package steam-runtime from Arch Linux), as intended. Thanks for the dev that worked on this, probably beacause of the Steam Deck <3
Does it use the Gtk file choosers on Gtk-based desktops?
Hello @darealshinji, the expectation with the current Steam client beta is that xdg-desktop-portal should be called where appropriate. It's not tightly bound to a specific file chooser implementation.
@kisak-valve I see. Is xdg-desktop-portal part of steam runtime? Because I didn't know about it an it's not installed on my system by default.
Hello @darealshinji, the expectation with the current Steam client beta is that xdg-desktop-portal should be called where appropriate. It's not tightly bound to a specific file chooser implementation.
this seems really stupid because desktop portals are mostly a flatpak thing and you're using them outside of that
i also haven't found it mentioned anywhere outside of this thread
but whatever
desktop portals are mostly a flatpak thing
Thats not true. It came up as part of the flatpak movement, yes, but nowadays portals are a very useful generic API to go with for everything. As you don't need to implement desktop or framework specific things anymore, but just generic ones that will work everywhere. So going with it is the best thing.
The filepicker after Valve removed all the bad parts:
(using Hyprland desktop portal here, which doesnt provide a filepicker as of now)
I can confirm the issue that @exit91 has. When using i3 Tiling Window Manager there is no way to add folders or see folders. This happens on the steam package from the package manager with all the necessary fonts installed.
Since now steam depends of the XDG Desktop Portal to open the necessary file picker from the DE (Ex: GNOME, KDE) the old one steam file selection was deprecated and that is the reason why it looks like that.
Nothing extracted yet.
I mean come on. What. Granted I'm using a custom skin but take away the gradient and it's basically the default thing.
It opens up viewing the Steam installation directory by default. Going up does NOT take you to /home and it stops at what I think might me $STEAMROOT. In the path selection dropdown at the top you can only select / and no useful locations like ~/ or ~/Pictures or whatever. If you're choosing your avatar, you don't get thumbnails and have to rely on a tiny and hard to navigate list of filenames.
Just use the desktop's native toolkit if it's available. Choose GTK first because that has the best file selection dialogue. Then go Qt (which is almost as terrible as Steam's own one, but y'know). If no toolkit is available go with Steam's in built one, but at least add in a file preview / thumbnail so we can see what file we're selecting for avatar. It also has no way to filter by file type, the dropdown for that is completely empty and doesn't even open.
Aside from the DUH-DING noise this is definitely the worst part of the Steam client. Incidentally, opening the file selection deactivates the client and replaces it with DUH-DING. As we discovered with game cache validation which has now been fixed, there is literally no reason to EVER disable the ENTIRE client and blow peoples' eardrums out with the DUH-DING which still needs killing a horrible death in the fiery pits of hell.