[Somewhat long post]
First of all congratulations on Kdenlive. It's easy enough for me to work with, and complex enough not to limit my creativity all too often.
In my latest video experiment, I wanted to add subtitles. Lots of subtitles. I didn't want draw each title manually using the title clip feature, so i wrote a python script that transforms lines of text into transparent .png drawings with titles/subtitles (by calling imagemagick to do the hard work). These clips then have to be inserted in the timeline manually. Once they have been inserted, you can regenerate them from the text files (e.g. to correct spelling errors, or to use a different language) and you're ready to re-render.
I think it shouldn't be too difficult extend this to generate .png files from existing subtitle file formats like *.srt or *.sub.
This script has taken away much of the time that is required to define titles/subtitles for me, but I'm dreaming about improving/extending it as follows (and I'd appreciate some advice in doing so):
Ideally, not only .png clips are generated from a text specification, but they are also inserted in the timeline based on time annotations (and perhaps also a default composite transition can be added to it to make it blend in with the video). For this to happen, right now I basically see two options:
1. the tool is completely separate from kdenlive; it reads the .kdenlive file, updates it as required behind kdenlive's back, and then finishes. The user has to reload the .kdenlive file to see the changes.
Pro: the tool can remain completely in python, remains completely decoupled from kdenlive
Con: the tool has to understand the file format used by kdenlive (which may evolve incompatibly at some point in time?), and has to somehow be aware of any implicit assumptions kdenlive may have made about its contents. The tool thus easily could get "out of sync" with the kdenlive distribution.
2. some kind of plug-in mechanism is used to communicate between the tool and kdenlive.
Pro: better integration with kdenlive is possible, leading to better end-user experience; if a well defined api can be used, there's less chance of sudden incompatibilities later on
Con: requires coding in C++ and requires being able to compile kdenlive, making contributing harder, the learning curve is steeper. Moreover, from what I read on the forum, the plug-in mechanism hasn't fully stabilized yet(?).
So now for the questions:
1. Are people interested in a tool like this? I'd be happy to share what I did so far, and explain how I use it.
2. Is one of my approaches the way to go? Or do you see other possibilities?
For your comments...