Re: Ideas and graph

[bartscgr t-online de (Guenter Bartsch)]

hi bastien,

> > the config option complexity problem is beind addressed in the new api
> > where each config option is associated with a "experience level" option
> > so beginners will only see few config options while experts can still
> > have full control over everything. i think nautilus for example uses a
> > similar aproach.
> 
> It was ditched, because it should just work

humm - but there are things that cannot be auto-detected. 4-channel
surround playback is one such example. you can ask the audio driver
wheter it supports 4-channel playback, however there is no way to find
out if the user has actually connected 4 speakers.

devices are another example - it is hard to find out where the dvd drive
is (but one can do better than xine currently does, adding better
detection code is on my todo-list) but as soon as the user has more than
one such drive you need a config option so the user can specify which
drive to use for dvd / vcd playback.

another problem is that the xine config system is also used as a registry
for storing internal values - while personally i'm not happy with this,
some frontends (e.g. xine-ui) do this. for these cases i think it is a
good idea to hide these "options" (like demux strategy, suffixes...)
using the exp_level mechanism.

> > but i'm happy to see your aproach on this, of course :-)
> 
> Xine is already very good at working out of the box. 

it is definitely the goal to make this even better. the problem is, that
not everything can be detected reliably. broken drivers are one such
example like x-drivers that crash when doing Xv or sound daemons like esd
which do not handle latency issues.

cheers,

   guenter

--
Steinbach's Guideline for Systems Programming:
        Never test for an error condition you don't know how to
handle.