Project

General

Profile

Feature #8585

presets handling

Added by Zeus Panchenko about 7 years ago. Updated about 5 years ago.

Status:
Triaged
Priority:
Medium
Assignee:
-
Category:
General
Target version:
Start date:
Due date:
% Done:

20%

Affected Version:
System:
bitness:
64-bit
hardware architecture:
amd64/x86

Description

when db removal necessity arise, we need to handle presets to be not lost and to able to be imported back after db re-creation

may be to handle them like styles are handled?


Related issues

Duplicated by darktable - Feature #8788: save presets (and any non-database-specific settings?) outside of the database Duplicate 06/19/2012
Duplicated by darktable - Feature #9296: allow export/import of presets Duplicate 03/15/2013
Duplicated by darktable - Feature #9702: Module presets should be stored elsewhere than in library.db Duplicate 12/02/2013

History

#1 Updated by Tobias Ellinghaus about 6 years ago

  • % Done changed from 0 to 20
  • Target version changed from --- to Future
  • Priority changed from Low to Medium
  • Status changed from New to Triaged

#2 Updated by Tobias Ellinghaus about 6 years ago

From IRC discussion:

<parafin> we really should split presets from db before next release
<houz> maybe not split but do something like with xmp files: write to both db and external file. on startup the db should be purged (wrt. presets) and the files should be read

#3 Updated by Pascal de Bruijn almost 6 years ago

I agree that exporting our presets just as we do with the styles is a good idea with regard to database failure survivability.

But I don't think we should always import that on startup.

Our database is the leading source of information (for example like with the .xmp's), so to keep things clear it should be either leading for everything or nothing in my opinion.

#4 Updated by Dave Woodfall about 5 years ago

Tobias Ellinghaus wrote:

From IRC discussion:

<parafin> we really should split presets from db before next release
<houz> maybe not split but do something like with xmp files: write to both db and external file. on startup the db should be purged (wrt. presets) and the files should be read

The problem here is that presets are global, not connected to one image like xmp data. They would be better off in an presets.db or similar IMHO.

Also available in: Atom PDF