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.
Thinking about distributed rendering, plugins should of course never assume an
X11-connection.
Burkhard
_______________________________________________
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
