Burkhard Plaum wrote:
> Hi,
>
> Christian Thaeter schrieb:
>
>> Moreover when plugins want to provide gui's on themself (dialog window
>> for configuration, timeline rendering, mask overlays, patchbay
>> widgets,...) these should/must use the toolkit a upcoming gui uses. So
>> we have the choice of either decide on a tookit or we wrap an tookit
>> abstraction and some custom widgets we need into a glue layer.
>>
>> The later would be a major task with much work to do for something which
>> likely never happens (porting the gui to another tookit).
>
> 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.
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.
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.
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).
Making it application specific is currently the low hanging fruit, time
will show, when a common interface becomes available new plugins could
use that and old ones could be ported over. Anyways this will ensure
that the approach is sufficent for 100% of all plugins.
Christian
_______________________________________________
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
