[vlc-devel] commit: Don't ignore-config on the webplugin (Jean-Baptiste Kempf )
remi at remlab.net
Sun Oct 4 20:13:11 CEST 2009
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.
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.
More information about the vlc-devel