4 ms·

I agree that collaboration is always desirable, and that common standards are beneficial to everyone. But the GTK filepicker is simply an embarrassment, there'

I agree that collaboration is always desirable, and that common standards are beneficial to everyone. But the GTK filepicker is simply an embarrassment, there's no other word for it. For all of the effort that has been spent on everything else Gnome-related, adding thumbnails to the filepicker would have been an extremely easy win. The current implentation is at Win 3.x levels of design and experience.

Cloudef 5y ago
I've always wondered why file picker has to be so tightly integrated into GUI toolkit. Separate program outputting the selected path(s) sounds like much nicer design, and makes it easier to implement alternative file pickers.
- prussian 5y ago
  I believe that is the purpose of the xdg portals specification. https://flatpak.github.io/xdg-desktop-portal/portal-docs.html https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
  - Cloudef 5y ago
    Not really >The FileChooser portal allows sandboxed applications to ask the user for access to files outside the sandbox. The portal backend will present the user with a file chooser dialog. In addition it being a dbus api for communicating outside a sandbox
    - prussian 5y ago
      Not really how? https://github.com/ranchester2/nautilus-as-file-chooser-poc https://github.com/ranchester2/nautilus-as-file-chooser-poc This is a standardized GTK workflow that works in and out of flatpak.
      - Cloudef 5y ago
        I was under impression the backend has to implement all of the API to do that. Nice to know it's enough to have dbus service that listens to a single call. I might do this to replace file picker on my machine. It's still baffling however, how fork + exec <-> pipe can't be used for this. Especially considering that under all that dbus cruft the PoC essentially does this: https://github.com/ranchester2/nautilus-as-file-chooser-poc/blob/master/portal/file_chooser.py#L18-L19 https://github.com/ranchester2/nautilus-as-file-chooser-poc/...
        BrightGlow 5y ago
        Using fork and exec with a pipe is not going to work within a sandbox. That "cruft" is necessary for the thing to work...
        Cloudef 5y ago
        I get why they invented this for flatpak (Even though it still could be done with processes and namespaces), but my original point was wondering why they did not originally use fork, exec and pipe.
        BrightGlow 5y ago
        Because the goal was to make an API that works the same both inside the sandbox and outside the sandbox. Edit: It wouldn't work with just processes and namespaces because you need a way to talk to a resource with a privilege level above the current mount namespace.
        Cloudef 5y ago
        Right, the child process can't escape the sandbox. I guess IPC here is the only sane choice.
    - mid-kid 5y ago
      It was indeed designed to be a portal for escaping the sandbox, but this has the nice side-effect of allowing the file dialog to be implemented by whatever program is called through D-Bus. This is already being used in KDE distributions to show the KDE file picker in firefox, where it would've required patching firefox back in the day.

Cloudef 5y ago

I've always wondered why file picker has to be so tightly integrated into GUI toolkit. Separate program outputting the selected path(s) sounds like much nicer design, and makes it easier to implement alternative file pickers.

prussian 5y ago
I believe that is the purpose of the xdg portals specification. https://flatpak.github.io/xdg-desktop-portal/portal-docs.html https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
- Cloudef 5y ago
  Not really >The FileChooser portal allows sandboxed applications to ask the user for access to files outside the sandbox. The portal backend will present the user with a file chooser dialog. In addition it being a dbus api for communicating outside a sandbox
  - prussian 5y ago
    Not really how? https://github.com/ranchester2/nautilus-as-file-chooser-poc https://github.com/ranchester2/nautilus-as-file-chooser-poc This is a standardized GTK workflow that works in and out of flatpak.
    - Cloudef 5y ago
      I was under impression the backend has to implement all of the API to do that. Nice to know it's enough to have dbus service that listens to a single call. I might do this to replace file picker on my machine. It's still baffling however, how fork + exec <-> pipe can't be used for this. Especially considering that under all that dbus cruft the PoC essentially does this: https://github.com/ranchester2/nautilus-as-file-chooser-poc/blob/master/portal/file_chooser.py#L18-L19 https://github.com/ranchester2/nautilus-as-file-chooser-poc/...
      - BrightGlow 5y ago
        Using fork and exec with a pipe is not going to work within a sandbox. That "cruft" is necessary for the thing to work...
        Cloudef 5y ago
        I get why they invented this for flatpak (Even though it still could be done with processes and namespaces), but my original point was wondering why they did not originally use fork, exec and pipe.
        BrightGlow 5y ago
        Because the goal was to make an API that works the same both inside the sandbox and outside the sandbox. Edit: It wouldn't work with just processes and namespaces because you need a way to talk to a resource with a privilege level above the current mount namespace.
        Cloudef 5y ago
        Right, the child process can't escape the sandbox. I guess IPC here is the only sane choice.
  - mid-kid 5y ago
    It was indeed designed to be a portal for escaping the sandbox, but this has the nice side-effect of allowing the file dialog to be implemented by whatever program is called through D-Bus. This is already being used in KDE distributions to show the KDE file picker in firefox, where it would've required patching firefox back in the day.