From: <bar...@t-...> - 2002-07-02 19:08:30
|
hi daniel, On Tue, 2 Jul 2002, Daniel Caujolle-Bert wrote: > About the xine_cfg_entry_t datatype, i thing xine_value_t shouldn't a > pointer, that about many memory allocations. right. changed :) > I also added a 'const' declaration of xine_cfg_entry_t functions, > which i think it's correct since clients should free() or modify any > returned data. for update_entry, they have to change the contents ... besides that, you know, i don't like the const keyword - a pointer is a pointer ;> > I also think we need a xine_config_reload_config() fonction, (it's > already present in current API), which permit to get rid of all changes > mades, or to be sure all changes has been updated (after a save() call). > I noticed some /missing/ when you harass config stuff, and the only way > to ensure about change is to save() then read(). ok. > LOGO mrl fixed :-) :)) miguel was the first one who told me that :) > > xine_check_version() readded, it's nice to provide this function, that > avoid all UIs to reimplement it (since ALL UIs use it, as i see in srcs, > plus, it's a trivial function ;-) ). ok - although i don't understand why this is necessary - i thought this is the linker's / libtool's job now? btw: gnome-xine doesn't use it > Another thing, i see all capabilities has been removed. I don't > know why, at least it is needed by audio mixer stuff. audio mixer ?! these capabilities are xine-internal stuff, i don't think any of them should be handed through to the ui cheers, guenter -- God may be subtle, but He isn't plain mean. -- Albert Einstein |