On Jun 7, 2010, at 2:24 PM, Danny Sung wrote: > > > Actually I really like this idea. This would effectively introduce what > could be a plugin architecture for popt. Ideally this should be done in a > way where someone could create say an XML output and release a separate > library called popt_help_xml or something. >
But the issue becomes Where do I get an additional "void *" from? in order to do rc = (*callback) (..., callback_context); The existing --help callbacks are per-table, not per-item, and so that forces the insanity of 1 option per-table in order to use. There are other, --help i18n insanities, with the exisiting POPT 1.0 callbacks too. > One of the concepts I've been playing around with is having the help system > double as a mechanism for programs to figure out what options other programs > have. > > For example, it seems common place these days to write GUI shells on top of > command-line utilities. However, it's difficult to know what exact > parameters are available for a specific build without a run-and-test > operation. > > So this mechanism would allow someone intrepid developer (or perhaps GUI > framework people like gnome/kde) to establish a standard for doing this sort > of thing. > > > > The plugin/callback thing goes even further though. Even your optionTable > could support something like this. So in the case of your auto-increment > feature... this could actually be a "plugin" to popt, allowing someone else > (either the app developer) or a plugin author to write. > > If done well, it's possible you'll start getting developers join you by > submitting plugins to the "default" installation. > > Also, I don't know how others feel about this. But if it makes things any > easier (esp. if it makes it easier for the app developer), I'm actually sort > of okay with an external utility generating the options table, and just > allowing me to #include it in my source. > Generating the options table form *WHAT*? If you have well defined markup from which a popt table can be generated, I'd rather see that utility internal to POPT itself, not external where noone else benefits from its existence. Nothing in the previous statement precludes anyone from generating POPT tables however they wish externally. Just internal can/will be maintained and tested and ... whatever else is needed. ATM, I know of no well-defined markup, nor any attempt to automatically generate POPT tables using an external utility. Translation: Show me the code. ______________________________________________________________________ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org