desktop-portal: Desktop Portal.

A Haskell wrapper for the XDG Desktop Portal DBUS API.

[Skip to Readme]

Modules

For package maintainers and hackage trustees

Candidates

Versions [RSS]	0.0.1.0, 0.1.0.0, 0.1.1.0, 0.2.0.0, 0.2.1.0, 0.2.2.0, 0.3.0.0, 0.3.1.0, 0.3.2.0, 0.4.0.0, 0.5.0.0, 0.6.0.0, 0.6.0.1, 0.6.0.2, 0.7.0.0, 0.8.0.0, 0.8.0.1
Change log	ChangeLog.md
Dependencies	base (>=4.7 && <5), binary (>=0.8.9.1 && <0.9), bytestring (>=0.12.1.0 && <0.13), containers (>=0.6.8 && <0.7), data-default (>=0.7.1.3 && <0.8), dbus (>=1.3.9 && <1.4), directory (>=1.3.9.0 && <1.4), filepath (>=1.5.0.0 && <1.6), modern-uri (>=0.3.6.1 && <0.4), network (>=3.2.7.0 && <3.3), os-string (>=2.0.0 && <2.1), random (>=1.2.1.3 && <1.3), text (>=2.1.1 && <2.2), unix (>=2.8.6.0 && <2.9) [details]
License	MIT
Author
Maintainer	garethdanielsmith@gmail.com
Category	GUI, XDG, Flatpak, Desktop, Portal
Home page	https://app.radicle.xyz/nodes/ash.radicle.garden/rad:z36pipjz8YLAs3m9boMmJCQgPuKnJ
Bug tracker	https://app.radicle.xyz/nodes/ash.radicle.garden/rad:z36pipjz8YLAs3m9boMmJCQgPuKnJ/issues
Source repo	head: git clone https://ash.radicle.garden/z36pipjz8YLAs3m9boMmJCQgPuKnJ.git
Uploaded	by garethdanielsmith at 2024-12-21T20:08:20Z
Distributions
Downloads	585 total (61 in the last 30 days)
Rating	(no votes yet) [estimated by Bayesian average]
Your Rating	λ λ λ
Status	Docs available [build log] Last success reported on 2024-12-21 [all 1 reports]

A Haskell wrapper for the XDG Desktop Portal DBUS API. Like libportal, but written in Haskell. Primarily intended to support applications packaged as Flatpaks (see monomer-flatpak-example).

Q. Why does this not use Template Haskell to generate interface code from the XML API definitions?
A. The Portal API does not lend itself to code generation because inputs and outputs are mostly informally defined via vardicts rather than via simple positional parameters. Also the XML definitions are LGPL, which would make this library LGPL too.

See the generated docs on Hackage.

The monomer-flatpak-example app includes example code for many of the APIs.

If you just want to add a wrapper for an API method that is not currently supported, open a PR.
If you want something less straightforward, open an issue to discuss it.

Module/function/field names should mimic the underlying portal API as much as possible.
Functions should generally be tested (see existing tests for examples).
API methods that take or return a variable set of values via a vardict should be translated into Haskell functions that take records called ...Options and return records called ...Results.
...Options records should have a Default instance where all fields have a reasonable empty value.
Record fields should not have unique prefixes.
API methods that return URIs that are known to always be file: URIs should be wrapped with functions returning System.OsPath. If they are not known to be file URIs, then Text.URI.URI should be returned.

./scripts/format.sh # format the source code
./scripts/publish.sh # publish to hackage