Pascal Obry (2019-Jun-10, excerpt): > Le lundi 10 juin 2019 à 15:05 +0200, dt-l...@stefan-klinger.de a > écrit : > > * Maybe "remove unused moduls" and "compress history stack" > > should be entirely separate operations? > > Yes for sure.
Being a good or bad idea in general is a different aspect from whether "remove unused moduls" should be an option to "compress history stack", or an entirely separate operation. I do not know what it should do exactly as a separate operation, which would make it different from "compress history stack" in a useful way. > Remove off module will bring nothing and you lose the actual setting > in this module. So generally that's just a bad idea. That's what I've built it for. Compressing the history stack always comes with a loss of information, namely all the settings of all modules except for their topmost entry on the stack. I assume that's the gist of compression. > You are going to "save" some disk space (which is very very cheap) > at the risk of losing some settings. This option is not about saving disk space, but rather about cleaning up. Removing disabled modules should (that's what it's for) loose all information wrt. a module, iff that module's top-most status is being disabled, and it thus does not contribute to the final image. This includes disabled extra module instances. It's even undoable. -- http://stefan-klinger.de o/X I prefer receiving plain text messages, not exceeding 32kB. /\/ \ ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
