Andreas Schulz wrote: > Here comes libIrremotes, that allows > to put Pronto hex codes into the Logitech database.
scanf_pronto_hex, printf_pronto_hex: It seems like accepting a "FILE *file" or "int fd" instead of "char *filename" would be more flexible, and avoid all the special-cases for stdout. For APIs that return pointers to memory, please define whether the client or library is reponsible for de-allocating the memory, and when this will occur. Please provide an API for clients to call to do this if required. It'd be nice if all symbols (types, values, functions, etc.) were all prefixed with e.g. "IRR_"/"irr_" to ensure they never conflict with any other library. When calling pronto_to_pulses, how does one initialize the pronto_hex structure? Is there some kind of standard representation for the data in that structure that a user would use? If so, it seems that libIRRemotes should provide a function to parse that user input and convert it to pronto_hex, rather than making each client application write that code themselves. Is this library intended to support anything other than Pronto codes (e.g. CIR, RC5, ... encode/decode)? If not, naming the library something with "pronto" in the name seems like a good idea (ignoring trademark issues anyway.) At least, something much less generic would be good. Doesn't the LIRC project have a library that does this kind of thing already, that could be re-used instead of re-inventing the wheel? In fact, don't they have a big database of key codes that might be useful? ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
