Community meeting on 14th March 2024

Announcements
7
  • Name/IRC nick: nephros
  • Topic: XDG Desktop Portals
  • Some details about the topic:
    Sorry for the wall-of text below. Most of it is informational-only/General Discussion, specific questions to Jollyboys in Part 2, below.
  • Approx. time needed: 10 Minutes for answers? Plus General Discussion
  • Substitute (optional): Meeting time is always hard for me to meet because of dayjob. I will try to, but can not guarantee that I will be able to comment. I can guarantee to be lurking/following the discussion as best I can and if necessary respond later.

Part 1: Informational: State of the PoC
The Proof-of-concept implementation of XDG Desktop Portals has been begun and has reached a stage where it at least can do some things. This follows the suggestions/agreements reached in the previous Meeting discussion.

  • An analysis/comparison of the specification and existing Sailfish OS functionality has been done and documented here. At the moment this has been done solely by me and is not aligned with anyone or anything (so it’s basically my opinion), but may serve as a starting point.
  • Low-hanging-fruit implementations have been done: Wallpaper, Screenshot, and Email portals (and Access as a dependency of Screenshot), leveraging existing SFOS interfaces.
  • A real-world demo/use case which shows why Portals are useful has been brought forth by community developer piggz: Kirigami-based apps (from Chum) currently display Kirigami-native file picker dialogs, which are not usable on Sailfish OS. The PoC implementation of the FileChooser portal solves this by enabling Kirigami apps to use Portals to launch a SFOS-native dialog.
    This implementation (and to a degree the others) shows a point where additions from Jollyboys would be needed: it requires UI components to be available, which act similarly to the dialogs from e.g. lipstick-{security,bluetooth}-ui, and lipstick-windowprompt.
    (Note that a very similar use-case exists for the mozilla-based Browser, which also has the capability to use portals. This may present the opportunity to reduce Browser-specific UI components if implemented more generically.)

Interested developers from the Community and from Jollyboys are invited to have a look. Basic instructions for testing are available here.

Part 2: Questions to Jollyboys

Assuming there is interest from the Jollyboys side to collaborate on this effort, please provide guidance on:

a) Naming things: I have chosen the name Amber for the implementation. I did not want to use things like Jolla, Sailfish, or Chum/Community (or legacy names like Nemo) because the aim is for everybody to collaborate on this, and there is some existing “middleware-like” components in SFOS called Amber.
The name appears in the binary names, D-Bus names, config directives (and obviously the package name). Are we ok to continue to use that name, e.g. because of existing conventions re. the Amber name? Suggestions for a better name otherwise?
b) Licensing: because I took some things from existing portal implementations of the KDE and lxqt projects, licensing for the c++ parts is currently a mix of LGPL2+ and LGPL3+. My own additions of UI components are currently Apache-2.0. Any objections/comments on that in the ligtht of mayyybe shipping this with SFOS proper at some point?
c) Technical details I: one of the dbus-services involved needs an environment variable set (XDG_CURRENT_DESKTOP), and this should be available to other software as well. Which is the correct place to do that? Is it ok/sufficient to place a file at /var/lib/environment/compositor/foo.conf?
d) Technical details II: The upstream portal systemd units currently use PartOf=graphical-session.target to launch. I understand this target currently does nothing on SFOS. Which unit/target would be the correct one?
e) Any other comments on this in general and how to proceed?

Part 3: Questions to everybody

  1. Continuing development Where shall the main codebase live?
    • leave as-is on github.com/nephros, do the usual PR/issue stuff, otherwise this stays as nephros pet project
    • moving a dedicated public github organisation
    • moving sailfishos-chum github organisation
    • some kind of secret-cabal type of arrangement
    • other
  2. Other important things to add?

Part 4: Informational: Future outlook and challenges

In order to keep this Topic brief (I failed, I know) I have listed some of the outlook and future benefits/challenges here. Interested parties are again invited get some further infos there.

References:

8 Likes