Re: [xine-devel] #ifdef LOG and xine->verbosity >= xxx change proposal [sample]

[<bar...@t-...>]

hallo daniel,

> > > > > +#define XINE_VERBOSITY_NONE                0x000000
> > > > > +#define XINE_VERBOSITY_LOG                 0x000001
> > > > > +#define XINE_VERBOSITY_DEBUG               0x000002
> > > > 
> > > > [...]
> > > > 
> > > > > +          if((xine)->verbosity & verbose)      \
> > > > 
> > > > i think this is a small mistake - verbosity is not a bit vector but a
> > > > simple integer number (measuring the level of verbosity)
> > > > 
> > > 
> > > 	Err, not a real mistake, bug here VERBOSITY_DEBUG should be 0xFFFFFF,
> > > this way, devels can use ORed VERBOSITY, so more VERBOSITY "levels" can
> > > be added (imagine you can trace demuxer only, or input player, and such
> > > things).
> > 
> > verbosity is not a tool for developers but for end-users so defining it
> > as a bit verctor is way to complicated.
> > 
> 
> 	Err, at contrary, i think verbosity is a devel tool. Why? because users
> don't take care about xine's console output, they even lauch xine from
> their desktop, without terminal emulator. They only use verbosity to
> report bugs, unplayable streams and such problems. Look at lastest
> reports they made on -user mailing list, they start to use verbosity=255
> by themself.

in gxine that would mean they'd have to put '-v' 255 times on the command
line :))

> 	Anyway, verbosity policy usage is up to UI, so i don't see any
> complication here. UI can permit some numeric or "verbosity level
> names".

how could a frontend decide how the xine engine interprets verbosity
values?

anyway, switching from a numerical comparison (which is the current
implementation) to a bit vector intepretation would be an api change
(not api syntax but api semantics)

guenter

-- 
Succumb to natural tendencies.  Be hateful and boring.