Effect and EffectParameters

[Richard]

> I would say that my point is also about knowing what are the  
> effects we
> commit to have in all backends...
> Can we be sure to have such controls everywhere? What happens if a  
> backend
> doesn't support it? Aren't we supposed to have more effects?
>

After giving it some tought, I think there are a number of "standard"  
effects that developers would like to know about more specifically,  
such as brightness control. Otherwise, would'nt it be hard to use  
those effects in an applications, other than present them as a list  
to the user to choose from?

Those "special" effects can be constructed using the  
BackendInterface::createObject, like today, and if the backend don't  
support them, let it return 0. I would also suggest something like  
the following in class Effect:

enum ExectionOrder {PreEffect, InEffect, PostEffect};
ExectionOrder getSupportedExectionOrder();

that lets the backend decide how and when the effect can be applied  
in the chain (if done on the renderer, then it will typically be  
either PreEffect or PostEffect). The frontend will then make sure  
that all pre-effects get executed before the in-effect etc, even  
tough they might appear in a different order in the effect list.


> On the use-cases (poll ;) ): who is actually using the
> brightness/deinterlace control on their video playback ? I've never  
> done
> that in any media player which anyway rarely offer those features  
> (at least
> under Windows).
>

I agree that the size of phonon is important, but on the other hand,  
it is supposed to be a multimedia framework. So I don't think we  
should just strip off all things that are not very mainstream.

Actually, when creating small movieclips indoors with e.g. mobile  
phones, they tend to be very dark. I happend to adjust the brightness  
a lot when viewing them afterwards (in e.g. windows mediaplayer. You  
just have to search a bit before you find those controls :)


> Well wait a minute ;). The thing is that DirectShow (and I guess maybe
> quicktime) offer an built-in way to configure effects showing nice  
> dialogs.
> And of course people will ask to have those dialogs instead of the  
> built-in
> EffectWidget.
>

Agree!


> So I think we should have a way to call the backend configuration  
> dialog and
> the current EffectWidget could be the fallback implementation  
> inside the
> backend plugin.
>

Agree! Altough, if the backend doesn't have a 'native' dialog, then  
just return 0 from the backend, and let the client application decide  
what to do (It seems unneccesary to have to write such a dialog for  
every backend. Besides, what presented in the dialog should  
correspond to the chosen effects used, if you ask me.
And I think one dialog for all effects should suffice, rather than  
provide a separate widget for all effects. The application developer  
can easily do this himself (with his own stylesheets etc)...


> Maybe we could have something as simple as Effect::configure
>

Why not just use the BackendInterface::createObject as usual...

-Ric