SnoopJTIL that the directories that `snapd` binds are just hard-coded, right in the guts of the thing
"no user would ever want to access files in other places than these" - apparently, some number of people at canonical
Daniel Gibson@SnoopJ
if it lets you select files with a filepicker (instead of dragging them from the file manager onto the window), that *might* work with other directories
if it lets you select files with a filepicker (instead of dragging them from the file manager onto the window), that *might* work with other directories
@Doomed_Daniel unfortunately not, it's a "feature" of the sandboxing that access is denied across the board
@SnoopJ
weird, it *should* work, I think it goes through some kind of portal that has more access rights than the process itself.
I have a Chromium snap installed and in GMail I can't drag'n'drop a file from /tmp/ to attach it, but the "attach files" button which opens a file picker *does* work
@SnoopJ of course it could be that Slack uses the filepicker of its UI toolkit instead of the portal - but I thought it used Electron which should use the same shit as Chromium?
I know of this portal stuff (xdg-desktop-portal) from https://github.com/btzy/nativefiledialog-extended which can use either Gtk3 or the D-Bus based portal on Linux - another advantage of the portal is that it uses a "native" filepicker depending on your desktop, e.g. KDE/Qt one when using KDE. But maybe it's less flexible
GitHub - btzy/nativefiledialog-extended: Cross platform (Windows, Mac, Linux) native file dialog library with C and C++ bindings, based on mlabbe/nativefiledialog.
Cross platform (Windows, Mac, Linux) native file dialog library with C and C++ bindings, based on mlabbe/nativefiledialog. - btzy/nativefiledialog-extended