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

[Daniel Caujolle-B. <seg...@cl...>]

Hi Guenter,

Le mar 10/06/2003 =E0 01:47, Guenter Bartsch a =E9crit :
> hallo daniel,
>=20
>=20
> > > > +#define XINE_VERBOSITY_NONE                0x000000
> > > > +#define XINE_VERBOSITY_LOG                 0x000001
> > > > +#define XINE_VERBOSITY_DEBUG               0x000002
> > >=20
> > > [...]
> > >=20
> > > > +          if((xine)->verbosity & verbose)      \
> > >=20
> > > i think this is a small mistake - verbosity is not a bit vector but=
 a
> > > simple integer number (measuring the level of verbosity)
> > >=20
> >=20
> > 	Err, not a real mistake, bug here VERBOSITY_DEBUG should be 0xFFFFFF=
,
> > this way, devels can use ORed VERBOSITY, so more VERBOSITY "levels" c=
an
> > be added (imagine you can trace demuxer only, or input player, and su=
ch
> > things).
>=20
> verbosity is not a tool for developers but for end-users so defining it
> as a bit verctor is way to complicated.
>=20

	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=3D25=
5
by themself.
	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".

> for developer debug-output #define LOG is to be used
>=20

	At developement/bugfix stage, yes. No to trace a new user/engine
problem.

--=20
73's de Daniel, F1RMB.

             -=3D- Daniel Caujolle-Bert -=3D- seg...@cl... -=
=3D-
                        -=3D- http://naboo.homelinux.org -=3D-