Hi every one,
Sometimes darktable’s printing preset menu becomes too long… this (little) sofware permits to change it’s content.
Please read the README file, which I paste below:
This is dtpp 2025 November version for GNU/Linux.
(c) François Delègue 2025, GNU General Public License version 3.
Bugs, comments, suggestions: ecrire -at- francois --- delegue -.- fr.
dttp changes the presets displayed in darktable’s printing presets menu,
which may become very long. Of course dtpp stands for darktable
printing presets.
### Before using dtpp
Please read the `First run` item below.
### How this is done
To display the presets in the printing view menu, dartable looks
for records in `data.db` containing the string `print_settings`
in the column `operation` of the table `presets`.
dtpp changes this string to `print_settings_unset` for the choosen
presets, so darktable doesn’t display them.
dtpp restores the `print_settings` state when wanted, and never writes
writes anything else anywhere. It only reads the `name`, `op_params`
and `operation` columns in the `presets` table, only writes
the `operation` column.
It may drop an eventually duplicate preset if needed, see below.
### GUI and command line
Without argument the graphical user interface is launched,
two arguments are needed for the command line.
Running `dtpp -h` gives some help.
### Installation
Only the 1st step is needed. Installing in /opt/dtpp
is recommended but really not mandatory.
1. Copy the dtpp directory to /opt with root permissions:
$ cp -r /path/to/dtpp /opt/dtpp
or
# sudo cp -r /path/to/dtpp /opt/dtpp
2. Useful with the GUI,
a `dtpp.desktop` file is provided which makes dtpp appear
in the Utilities category of the desktop environment.
It is set for an installation in /opt/dtpp and must be copied
by an ordinary user:
# cp /opt/dtpp/dtpp.desktop $HOME/.local/share/applications
(For dtpp to be shown to any user of the computer,
copy dtpp.desktop to /usr/share/applications with root permissions.)
3. Useful with the command line,
add `:/opt/dtpp`, or another installation path,
to the PATH in ~/.bashrc:
export PATH=/yet/present/paths:/others/paths:/opt/dtpp
### Deinstallation
Activate all the presets (`Activate All` button in the GUI or
`dtpp set all` with the cmd line) then undo the installation steps above.
darktable’s database will remain as it was before dtpp’s usage.
### First run
Launched for the first time, dtpp makes a configuration file
named `dtpp.config` in `~/.config/dtpp/`, and also creates
this dtpp directory. The user is informed of this.
**Real darktable’s database is first used** and can be changed
for tests, to become confident with dtpp:
1. Leave dtpp before any presets activation/deactivation
then copy ~/.config/darktable/data.db somewhere,
2. Set the "somewhere" path in dtpp.config (information is provided)
then relaunch dtpp.
### GUI configuration
Things can be modified in dtpp.config about the GUI, please see
the comments in this file.
### Running
dtpp can be used when darktable is running. The SQLite3
operations are atomic by design. In the SQLite3 FAQ:
Multiple processes can have the same database open
at the same time. Multiple processes can be doing
a SELECT at the same time. But only one process
can be making changes to the database at any moment
in time, however.
When the activated presets are changed with dtpp, darktable
uses immediately the new activated presets list.
There is sometimes, rarely, a locked db message displayed
by dtpp when it tries to modify the presets activation.
Waiting a little and re-running the command,
or leaving darktable resolves this.
### Tests at launch
At launch dtpp tests:
—the schema and version of data.db (they must not have changed
since darktable 4.6.0),
—the root user (which is rejected),
—an existing dtpp process (for dtpp not to run twice),
-an eventually duplicate preset (which is dropped), see just below.
The presence of packages needed by dtpp (libsqlite3-dev, libgtk-3-dev)
isn’t tested as they come with darktable.
### A drawback and it’s management
A new printing preset can be created in darktable if it’s name
is yet the name of an unactive preset. This leads to a 'UNIQUE
constraint violation' in the database. To manage this situation:
-at launch, dtpp tests the duplication of presets names and drops
an unactive duplicate preset. An information is displayed
both to command line and GUI.
-with the GUI, the same test-with-drop-if-needed is done
before each update of the database (when dtpp is about
to change some presets activity) without information to the user.
If dtpp was launched in GUI mode by the command line,
an information s displayed.
### Compilation
gcc -std=c99 -Wall -Wl,--no-warn-execstack `pkg-config --cflags gtk+-3.0` \
-o dtpp dtpp.c -lsqlite3 `pkg-config --libs gtk+-3.0`
### TODO
Give the ability to select presets according to the installed printers.
### Future
darktable 5.2.0 introduced sub-menus for the module’s presets,
not (yet?) for the printing presets. If that changes in the future
dtpp will not be so helpful and at least will need to be modified.
With the hope that dtpp can be helpful…
as nobody else.
) -this thread was distracted from dtpp itself, lost into the hosting question remarks (?).