desktop-portal: Desktop Portal.

[ desktop, flatpak, gui, library, mit, portal, xdg ] [ Propose Tags ]

A Haskell wrapper for the XDG Desktop Portal DBUS API.

[Skip to Readme]


Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees


  • No Candidates
Versions [RSS],,,,,,,,,,,
Change log
Dependencies base (>=4.7 && <5), binary (>= && <0.9), bytestring (>= && <0.12), containers (>=0.6.7 && <0.7), data-default-class (>= && <0.2), dbus (>=1.3.0 && <2), directory (>= && <1.4), filepath (>= && <1.5), modern-uri (>= && <0.4), network (>= && <3.2), random (>= && <1.3), text (>=2.0.2 && <2.1), unix (>= && <2.9) [details]
License MIT
Category GUI, XDG, Flatpak, Desktop, Portal
Home page
Bug tracker
Source repo head: git clone
Uploaded by garethdanielsmith at 2023-12-29T15:32:17Z
Downloads 324 total (15 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2023-12-29 [all 1 reports]

Readme for desktop-portal-

[back to package description]

Haskell Desktop Portal

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).

Current Status

  • Unstable. Functionality and API may change considerably.


  • 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.

API Documentation

See the generated docs on Hackage.

Example Code

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

Development Guide

How to contribute

  • 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.

General Guidelines

  • 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.

To format the source code

# Should use Ormolu
ormolu --mode inplace $(find . -name '*.hs')