On 2017-01-30 13:10, Tobias Ellinghaus wrote:
Am Montag, 30. Januar 2017, 12:34:19 CET schrieb René Seindal:
On 2017-01-30 12:28, Tobias Ellinghaus wrote:
Am Montag, 30. Januar 2017, 12:04:03 CET schrieb René Seindal:
Hi
Ho do I make a long running Lua extension not block the darktable GUI?
It depends on what your code does and from where it is called. Some things
have to run in the gui thread and can't be unblocked, others can.
When you export files the export runs in the background somehow.
Exports are an example of what gets run in its own thread. So maybe show
some sample code.
The code takes the currently selected image in darktable, looks them up
in a shotwell sqlite3 database using luasql and updates ratings and tags
in darktable.
It is not something that can be handed off to a sub-process since it
updates darktable.
I have put in a progress bar (background job) but the progress bar
doesn't update and the cancel button doesn't work, because I can't find
a way to hand off control to the gui to update, while looping through
the images, looking stuff up in the other sqlite3 database.
The script is attached.
Just a general remark: Why do you do that inside darktable with a Lua script
instead of a small bash script that just gets all the relevant data from
shotwell's database and uses exiftool to create/update XMP files for the
images? I think I saw code like that in the past already. Someone even
mentioned that shotwell can also write XMP files itself, so maybe all you need
is enable that in shotwell and (potentially) rename the XMP files for darktable
to recognize them.
I would prefer letting darktable manage darktable data.
There are some scripts around that fiddle with the darktable database,
but it's only a source of problems. If darktable gives a way of
modifying that data in a safe manner, why should I go behind darktable's
back?
If I update XMP files I would have to reimport the files afterwards.
Shotwell doesn't write sidecars in consistent usable manner. There's no
option for it. It doesn't write sidecars for raw files. The only
option I'm aware of is to write metadata to jpegs, and if they're not
writable, it'll make a sidecar, but I don't want all my jpegs messed
with like that.
In the end the safest way seemed to open the shotwell database readonly
and let darktable update darktable data. That way I cause no harm.
That being said, I had a look at how other scripts use dt jobs and they handle
the cancel callback a little different, see for example
https://github.com/darktable-org/lua-scripts/blob/master/contrib/cr2hdr.lua
I don't know if that is relevant, maybe Jérémy can chime in?
I've had a look at many of these scripts but most of them are some kind
of wrapper around external programs, and they can use coroutine.yield to
yield to darktable waiting for the sub-process to finish.
This script does everything in the same process.
What I can't find is some way of giving the darktable GUI a chance to
update and respond to user actions, and the resume the script.
The only Lua API documentation I've found is for API version 3, but I
believe I'm using API version 4 now (darktable 2.2.1). Some of the
scripts on GitHub uses methods non described in the online documentation.
--
René Seindal - [email protected]
____________________________________________________________________________
darktable user mailing list
to unsubscribe send a mail to [email protected]
