Hi Bastian, nice idea. As SANE is already network capable to provide connected scanners to the network, (simply a network device) it make not really sense, to provide sane(d) via Flatpak in my eyes.
however, having SANE-based applications like XSane/ scan-image as Flatpak version, maybe a nice idea. But for this you don't need to modify saned. ... Or do I miss here something? Kind regards. Jörn-Ingo Weigert Am Do., 17. Sept. 2020 um 12:32 Uhr schrieb Bastien Nocera < [email protected]>: > Hey, > > I wanted to finally start looking at how to properly integrate SANE- > based scanning applications into Flatpak[1]. > > I looked at 2 different ways to implement this: > > - either the drivers are bundled with the application itself, and we > need to punch holes for those drivers to be able to communicate with > the hardware (eg. network, or USB[2]), > - or just as for a lot of other drivers, we can expect the drivers to > live on the host side, with the distribution, and we'd communicate with > those drivers (free or proprietary, like the ones for Epson V600...) > through a service that's outside the sandbox. > > I think that the latter is the best one to put in place, especially if > we want to support more complicated setups like networked scanners, > multi-function devices, and proprietary drivers. > > The idea would be to reimplement the client (based on the "net" driver) > to use D-Bus and reimplement or extend the server ("saned") to use D- > Bus. > > Would the SANE project want to ship those in its own repositories? Are > there are dependencies that wouldn't be acceptable? I plan on using > systemd's D-Bus library, sd-bus, as it doesn't require a GLib mainloop > like the very capable GDBus, so would be less disruptive when loaded > into apps. Should I extend saned, or write a new daemon? > > Cheers > > [1]: https://github.com/flatpak/xdg-desktop-portal/issues/218 > [2]: https://github.com/flatpak/xdg-desktop-portal/issues/227 > > >
