On Fri, Nov 16, 2012 at 11:55:34AM +0000, Måns Rullgård wrote: > Diego Biurrun <di...@biurrun.de> writes: > > On Fri, Nov 16, 2012 at 10:33:38AM +0000, Måns Rullgård wrote: > >> Diego Biurrun <di...@biurrun.de> writes: > >> > On Fri, Nov 16, 2012 at 10:06:16AM +0000, Måns Rullgård wrote: > >> >> Diego Biurrun <di...@biurrun.de> writes: > >> >> > On Wed, Nov 14, 2012 at 02:56:05PM +0100, Luca Barbato wrote: > >> >> >> On 11/14/2012 02:38 PM, Diego Biurrun wrote: > >> >> >> > Now the difference between "all" and "everything" seems arbitrary. > >> >> >> > Why don't we just set clear semantics on what we call "parts" and > >> >> >> > "components" or "components" and "subcomponents"? > >> >> >> > >> >> >> From an usability point of view you are not going to change that > >> >> >> option, > >> >> >> the best is to clarify it making so from reading --help you would not > >> >> >> expect it to disable something it does not. > >> >> > > >> >> > The usability is what I am trying to fix here, among other things. > >> >> > Having > >> >> > both --disable-everything and --disable-all as options is a usability > >> >> > nightmare. I'd have to look up which option did what myself in a few > >> >> > weeks time after implementing them... > >> >> > > >> >> > So what's bad about --disable-components or --disable-subcomponents? > >> >> > More importantly, what about those names is worse than what we have > >> >> > right now: --disable-everything? > >> >> > >> >> For better or worse, we have --disable-everything now, and people are > >> >> using it. Changing it to an equally arbitrary name will only make those > >> >> people angry. > >> > > >> > I suspect that I am one of the main users of that option, but anyway.. > >> > Your remark misses the context of my proposal, which does not eliminate > >> > --disable-everything. > >> > >> It changes the meaning of it, which is even worse. > > > > The semantics of --disable-everything are broken to begin with, so this > > hardly counts. > > Broken how?
It does not disable everything, contrary to what the name suggests. Diego _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
