A desktop entry gives a software centre a name and a one-line Comment, and nothing else — no description, no licence, no age rating, no statement of what hardware the interface was laid out for. GNOME Software and Discover both show an application with no metainfo as an unexplained icon, and both packages this repository produces were in that position. packaging/paris.tourolle.darkroom.metainfo.xml is the AppStream component, and it is installed by the PKGBUILD as well as by the Flatpak manifest because the description, the licence fields and the OARS rating are facts about the application rather than about how it was packaged. Writing it twice is how the two packages start disagreeing. Two things in it are easy to get wrong and are commented in place. The two licence fields differ on purpose: metadata_license covers the file itself and has to permit the unconditional redistribution and reformatting a catalogue does, which GPLv3 does not, so it is CC0-1.0; project_license is the application's own and reads GPL-3.0-or-later to match D8. And the component id is not a fifth name but the same string as the desktop basename, the Flatpak application id, and the app_id dr_ui::run sets — a rename that misses one costs the icon or the association, and neither failure announces itself. D15's decision that the target devices are a tablet and a desktop is stated as a display_length requirement rather than left implicit, so a software centre does not offer this on hardware where the photograph and the parameter panel cannot both be on screen. Validates clean under appstream-util validate-relax; appstreamcli --pedantic reports only that the gitea URLs are unreachable from a machine that cannot see that host. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
98 lines
3.9 KiB
XML
98 lines
3.9 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!-- Copyright 2026 Duncan Tourolle -->
|
|
<component type="desktop-application">
|
|
<!--
|
|
The component id, the .desktop basename and the Flatpak application id are
|
|
one string, not three that happen to agree. `dr_ui::run` sets the same
|
|
string as the Wayland app_id and winit's WM_CLASS, so a rename that misses
|
|
one of them costs the icon in the shell, the association in the software
|
|
centre, or both, and neither failure names itself.
|
|
-->
|
|
<id>paris.tourolle.darkroom</id>
|
|
|
|
<!--
|
|
Two licence fields, two different things, and they are meant to differ.
|
|
`metadata_license` covers *this file* — software centres redistribute and
|
|
reformat catalogue metadata, so it has to be under something that permits
|
|
that unconditionally, which GPLv3 does not. `project_license` is the
|
|
application's own licence and is the one that must read GPL-3.0-or-later
|
|
to match D8 and the workspace manifest.
|
|
-->
|
|
<metadata_license>CC0-1.0</metadata_license>
|
|
<project_license>GPL-3.0-or-later</project_license>
|
|
|
|
<name>DarkRoom</name>
|
|
<summary>Non-destructive RAW photo library and editor</summary>
|
|
|
|
<description>
|
|
<p>
|
|
DarkRoom catalogues, culls and develops RAW photographs. Edits are stored
|
|
as a graph of operations beside the original rather than baked into it,
|
|
so every change stays reversible and the file the camera wrote is never
|
|
rewritten.
|
|
</p>
|
|
<p>
|
|
The library can live in a plain directory — a local disk, an external
|
|
drive, an NFS or SMB mount — or on a Nextcloud server, browsed and edited
|
|
without downloading whole RAW files first.
|
|
</p>
|
|
<p>Where it differs from the tools it sits beside:</p>
|
|
<ul>
|
|
<li>Culling shows the camera's embedded preview immediately and replaces it with a full render when one is ready, so moving to the next frame does not wait on a demosaic</li>
|
|
<li>Sidecars are the record of an edit; the catalog is a cache that can be deleted and rebuilt</li>
|
|
<li>The develop pipeline runs on the GPU through Vulkan, including drawn masks — a working Vulkan driver is required, not merely preferred, because there is no CPU renderer behind it</li>
|
|
<li>Faces are detected and grouped locally — nothing is uploaded to identify anybody</li>
|
|
</ul>
|
|
</description>
|
|
|
|
<launchable type="desktop-id">paris.tourolle.darkroom.desktop</launchable>
|
|
<provides>
|
|
<binary>darkroom-desktop</binary>
|
|
</provides>
|
|
|
|
<url type="homepage">https://gitea.tourolle.paris/dtourolle/DarkRoom</url>
|
|
<url type="bugtracker">https://gitea.tourolle.paris/dtourolle/DarkRoom/issues</url>
|
|
<url type="vcs-browser">https://gitea.tourolle.paris/dtourolle/DarkRoom</url>
|
|
|
|
<developer id="paris.tourolle">
|
|
<name>Duncan Tourolle</name>
|
|
</developer>
|
|
|
|
<categories>
|
|
<category>Graphics</category>
|
|
<category>Photography</category>
|
|
</categories>
|
|
|
|
<keywords>
|
|
<keyword>RAW</keyword>
|
|
<keyword>photography</keyword>
|
|
<keyword>develop</keyword>
|
|
<keyword>darkroom</keyword>
|
|
<keyword>catalog</keyword>
|
|
</keywords>
|
|
|
|
<!--
|
|
D15 decided the target devices are a 12-inch tablet and a desktop, with no
|
|
phone. Stating that here is what stops a software centre offering the
|
|
application on hardware the interface was never laid out for: the develop
|
|
view puts a photograph beside a parameter panel, and below roughly 768
|
|
logical pixels there is no arrangement of the two that is worth using.
|
|
`recommends` rather than `requires` for the input devices — touch alone is
|
|
usable, it is simply not what the sliders were designed around.
|
|
-->
|
|
<requires>
|
|
<display_length compare="ge">768</display_length>
|
|
</requires>
|
|
<recommends>
|
|
<control>pointing</control>
|
|
<control>keyboard</control>
|
|
<control>touch</control>
|
|
</recommends>
|
|
|
|
<content_rating type="oars-1.1"/>
|
|
|
|
<releases>
|
|
<release version="0.9.0" date="2026-08-29"/>
|
|
</releases>
|
|
</component>
|