Hi,
Christian Thaeter schrieb:
Burkhard Plaum wrote:
[...]
My suggestion is the following:
- Define a set of abstracted widgets, which are already sufficient
for > 95% of all plugins. The advantages are:
* Those plugins never have to mess around with a GUI.
* Those plugins can more easily be used by other apps.
* If config widgets for those plugins are built by the core, we
already have a consistant "look and feel"
- Define a parameter type "complex", in which case the plugin has to
provide
* a config widget for that parameter
* Methods for reading/writing values of this type from/to project files
* A method for automating the parameter along the timeline (if that makes
sense).
- If it turns out, that a such a "complex" parameter type is not so special
(i.e. it's used by more than one plugin), it can be moved to the core
easily.
I'd rather separate plugin rendering functionality, parameter passing
and the gui.
IMO GUI and rendering can (and should) be separated. But
- parameters are affected by the GUI
- rendering is affected by parameters
- parameters can change during rendering
For rendering we already concluded to use gavl to pass data arround, I
didn't yet checked if gavl has some provisions for passing
metadata/parameters along, if not, this might be a nice feature someday.
For passing additional data, you have 2 options:
typedef struct
{
gavl_video_frame_t * frame;
/* Other data like timecodes, parameters whatever */
} cinelerra_video_frame_t;
or:
gavl_video_frame_t * frame;
cinelerra_frame_data_t * data;
/* Initialize data and frame */
frame->priv = data;
If it turns out, that one priv pointer isn't enough, I can add a priv2
pointer :) gavl never touches these anyway.
Distributed plugins which just do the work on a renderfarm will just
work, the GUI is only needed for the front node where the user sits.
Agree.
Next the GUI should be written application specific, this is a part of
the plugin you have either to port; Or we agree on a common widget
interface as you sketched above. One just has to define and implement
this interface (Hands up please).
I did this for gmerlin:
http://gmerlin.sourceforge.net/doc/gmerlin/group__parameter.html
For each parameter type, I have:
- Routines for file I/O with libxml2
- gtk-2 configuration widgets
- Routines for reading values from commandline arguments
- A test-tool for all parameter routines, which I use to
keep the stuff valgrind-clean.
A typical plugin needs to implement just 2 functions:
const bg_parameter_info_t * get_parameters(void * priv)
{
/* Normally a one-liner which returns some statically defined array */
}
void set_parameter(void * priv, const char * name,
const bg_parameter_value_t * val);
This is what I can offer. Maybe it can be used directly (in which case
it would need some polishing and cin-3 needs to be a gtk-2/libxml2 app),
or ported or just serve as an example.
But writing such a thing once is enough for this life, at least for me :)
Burkhard
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
