On 06/05/2010 8:56 AM, Jeff Johnson wrote:

Anything you want to see in POPT 2.0? I'm collecting features ...

Since you're collecting features... =)

One thing I'd like is to extend the help/usage capability just a little.

So I'd like to be able to have more descriptive usage parameters (eg. to cover left-over arguments). I addition it'd be nice to have a little description/summary of what the program to do. I realize you can do this with a custom help function. But it'd be nice if these were standard elements.

Other niceties might be:
- a way to indicate parameters enabled by default (eg. having a '*' next to them in the help)

- An additional structure that could provide detailed help on argDescription elements. For example, rpm has an option:
      --queryformat=QUERYFORMAT        use the following query format
It'd be nice if there were a section of help that could describe what QUERYFORMAT could be. So obviously it's not going to be a full man page, but perhaps it could just show supported % format options or something like that. I use something like this in my code, but I have specific keys like "[replaceme]" that I convert. And I put just the acceptable keys in the help cause I just need a quick reminder of what they are. But it clutters the option help a little. I'd be fine with specifying "FORMATSTRING" in the option help. Then have perhaps an arg help down below that shows what values FORMATSTRING understands.

I'm not sure exactly how you could support these without breaking compatability with existing apps. Perhaps a new datatype something like:

enum poptOptionType {

union poptDetailedOption {
   poptOptionType optType;
   struct poptShortOption;
   struct poptArgHelp;
   struct poptUsageHelp;

struct poptShortOption {  /* same as poptOption but with a type field */
    poptOptionType optType;
    const char * longName;
    char shortName;
    int argInfo;
    void * arg;
    int val;
    const char * descrip;
    const char * argDescrip;

I'm not sure this would give the desired effect.. but the thought would be that it'd turn your options table to something like this:

poptDetailedOption optionsTable[] = {
        { POPT_OPTION, "bps", 'b', POPT_ARG_INT, &speed, 0,
        "signaling rate in bits-per-second", "BPS" },
{ POPT_ARG, "FORMATSTRING", "Possible formatting options are [foo] [bar]" },
        { POPT_USAGE, "infile [outfile]" },
{ POPT_SUMMARY, "This program converts your data to something...." },

I don't think the union will allow it to look exactly like that. In fact it may not even be possible to initialize it that way(?) Maybe we'd have to do something wonky with macros to make it look nice. But you get the idea.

If you wanted to get really fancy the "POPT_USAGE" example I gave could be separated into something like this:
        1 /* required */,
        "specify input filename",
        "stdin" /* default value */
        0 /* optional */,
        "file to output" /* description */
        "stdout" /* default value */

This would allow the autohelp to generate "standard" extra arg displays (eg. [] for optional parameters, etc.).

Admittedly this feature may be a bit questionable as many programs may have rather complex "extra args". But I think a lot of programs fall into this simple category as well.

Anyway, just a few thoughts...

POPT Library                                           http://rpm5.org
Developer Communication List                       popt-devel@rpm5.org

Reply via email to