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
