From: Siggi L. <si...@us...> - 2002-06-28 22:48:01
|
On Sat, 29 Jun 2002, Guenter Bartsch wrote: > > Correct me if I'm wrong, but these applications are not forced to call > > xine_save_config() after changing the plugins. > > true - but if they don't do that, the user will loose all config options > he/she has changed. Hmmm, so we would need a method to select different config files for different UIs? [...] > i think it's as easy to store a false pointer in the config structs as it > is to use such a pointer as a parameter Okay, you're right. I forgot we're talking C here #-) > i think explicit parameters are much easier to understand than having to > set some obscure config options. Okay, my thought was that strings are generally safer to use than pointers to (unknown) structs, especially on library version changes, but this might not really be true... [...] > > I had the same idea. However, new_xine reads a bit more like English, and > > but it breaks the naming conventions used throughout the header. > consistency is one of the most important goals for the new api. Hmmm, but then again, that function is different, and this naming change makes it stand out. But as I said, thats just cosmetic... > > I'd explicitly declare the parameter list void ;-) > > I never got it why people write foo(void) instead of foo() - isn't that > just the same for any recent c-compiler ?! Nope. foo() is equivalent to "int foo(...)", ie, the function accepts _any_ parameter list without checking. Modern compilers may generate a warning for parameterless function prototypes, though... > > Hey, I found "aural" much more expressive (and funny) than "data". > > yes, but it collieded for the video case with the "visual" integer param oops, my mistake! I mixed those up... [return int in xine_init] > agreed (although personally is still believe in "never check for an error > condition you don't know how to handle) That's easy: if (xine_init(xine){ fprintf(stderr, "failed to initialize xine. Aborting.\n"); exit(1) } > > I don't really like this interface as the UI has to fiddle with > > xine-private pointers, but I could live with it... > > yes, it really could lead to some problems in the future. what's really > needed here is a ao/vo driver abstraction layer, just like the one built > for the config stuff. but as this is (1) performance critical and (2) I > don't want to re-invent X11, I'll not push this any further at this point. Okay. We have xine-lib 2.0 for that ;-) > thanks for your comments, Thanks for your work! Siggi |