[vlc-devel] commit: Don't ignore-config on the webplugin (Jean-Baptiste Kempf )

[Rémi Denis-Courmont]

Le dimanche 4 octobre 2009 20:25:03 Rafaël Carré, vous avez écrit :
> Le 02/10/2009 15:15, Rafaël Carré a écrit :
> > On Thu, 1 Oct 2009 15:08:51 +0200
> >
> > Jean-Baptiste Kempf <jb at videolan.org> wrote:
> >> On Thu, Oct 01, 2009 at 03:07:15PM +0200, Rafaël Carré wrote :
> >>>> This is bad, because many times you customize your vout
> >>>> configuration to make it work.
> >>>
> >>> This must mean the vout modules are broken
> >
> > Well we can study possible workarounds
> 
> Have you started something on nefrir's proposal ?
> 
> (Reading the config for webplugins, but with a blacklist of options
> which would stay as the default, like fullscreen)

Any option that has a user-visible effect would need to be blacklisted. Quite 
a lot of options would be affected... In fact, even vout and aout are affected 
due to the WAV file audio output, yuv, vmem video outputs and such. Also, what 
if VLC is configured to use x11/wingdi to work around the overlay not working 
with the video projector (but working fine on the main display)? Does that 
mean the web browser must use the slow output too - why?

And then, some options are very "arguable". Should equalizer settings be 
allowed or not? What if the web page specifies its own values for a safe and 
not-black-listed setting? In principle, we would have to "merge" the settings. 
Couch cough.

This concept looks like yet another intractable hack. I hope it does not 
further raise the barrier to the very much needed overhaul of the 
configuration and variable subsystem :( If you really want to configure the 
web browser plugin, then we really need a separate configuration. This is 
quite easy on the core side - we just need to read/write a separate file.

But even then, most users don't know about those video output tricks anyway, 
so this will hardly solve the problem. I mean, it might look like it would 
solve for forum users, but that's a very small proportion of the whole user 
base. In other words, the choice really is between getting the default 
settings right out of the box, or loosing the affected users anyway. Hence, I 
believe that hacking the configuration system again is not the right direction 
at all. I'm fine with a separate configuration for the web plugins, but I 
strongly doubt it solves the problem J-B was concerned with.

Blacklisting broken hardware vendors, outputting in a slow but safe way by 
default, asking the user to check, or sanity checking at run-time seems like 
more likely options.

-- 
Rémi Denis-Courmont
http://www.remlab.net/