[vlc-devel] [PATCH] FIX: Dshow "none" device open (#2201). Some cleaning

[Laurent Aimar]

Hi,

On Tue, Feb 17, 2009, basos g wrote:
> 2009/2/14 basos g <noxelia at gmail.com>:
> > 2009/2/12 basos g <noxelia at gmail.com>:
> >> 2009/2/11 Rémi Denis-Courmont <rem at videolan.org>:
> >>> Le mercredi 11 février 2009 16:15:48 basos g, vous avez écrit :
> >>>> These 2 patches address the issue in dshow as well as some other fixes
> >>>>
> >>>> -Fix dshow "none" deivice be recognized as none
> >>>>  Note that another patch concerning var_optionParse string
> >>>>  dequoting should be applied for this to be fixed
> >>>>  ( the concept is not to provide quoted strings to dshow options )
> >>>>  -Account for the case when BOTH devices could not be opened
> >>>>    (file an error, instead of seeming to play)
> >>>>  -Cleaned a little
> >>>>  -Added dbg and error msgs
> >>>>  -Added coments
> >>>
> >>> I am not against removing quotes there, but we have to be consistent.
> >>> Discarding quotes is wrong. There has to be a way to pass a value that does
> >>> include quotes.
> >>>
> >>> --
> >>> Rémi Denis-Courmont
> >>> http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary
> >>> _______________________________________________
> >>> vlc-devel mailing list
> >>> To unsubscribe or modify your subscription options:
> >>> http://mailman.videolan.org/listinfo/vlc-devel
> >>>
> >>
> >> The point is that for the dshow we don't need quotes.
> >> Do we need them elsewhere ?
> >> I think quotes mean: take the hole following string including spaces.
> >> As long as the delimiting is done correctly i am not sure that we
> >> actualy need the quotes inside psz_data.
> >>
> >> eg.
> >>
> >> :adev="Create sound blaster" :vdev="vid1" :type=pal etc
> >>
> >> here psz_value for adev should be
> >> Creative sound blaster
> >> and not
> >> "Creative sound blaster"
> >>
> >
> >
> > So whats the point about quotes ? Do we need them ( e.g. is there a
> > case that in-string quotes are NEEDED ?
> >
> > Note that these 2 patches fix a (small) bug and i don't expect that
> > you want it to be ignored ?
> >
> 
> Someone to check this ?
> It does not seem to break sthing.
> 
> I re-sent the var_optionParse patch with a more clean way (str_dequote
> help funtion was added).
> 
> NOTE that i could make this patch like str_quote(ing) all vars from
> dshow filter.
> But i doubt that any other input option user module actually needs
> quotes inside psz_data. So i propose to dequote every input string..

 Sorry for the late review,

 I do not think it is valid.
 I am pretty sure it is an interface(qt4) problem that add quotes where it
should not.

Regards,

-- 
fenrir