Re: GOption extension
- From: Matthias Clasen <mclasen redhat com>
- To: gtk-devel-list gnome org
- Subject: Re: GOption extension
- Date: Wed, 25 Aug 2004 20:20:23 -0400
Am Mittwoch, den 25.08.2004, 21:35 +0900 schrieb Masatake YAMATO:
> Hi,
>
> I've just found the replacement for popt is introduced to glib.
> I have some proposals to GOption extension.
>
> 1. Replacement for help print function
> 2. Type extension
>
>
> 1. Replacement for help print function
>
> In current implementation, the function for --help is
> statically defined. I think it is nice if I can replace
> it at runtime. Example:
>
> [jet localhost glib]$ pkg-config --help
> Usage: pkg-config [OPTION...]
> --version output version of pkg-config
> --modversion output version for package
> --atleast-pkgconfig-version=VERSION require given version of
> ...
>
> [jet localhost glib]$ export GTK_MODULES=install-xml-help
> [jet localhost glib]$ pkg-config --help
> <GOptionUsage command="pkg-config">
> <option long-name="version" argument="NONE"/>
> <option long-name="modversion" argument=="NONE"/>
> <option long-name="atleast-pkgconfig-version" argument=="STRING" argument-name="VERSION"/>
> ...
> </GOptionUsage>
>
> In this example, the print function is replaced by install-xml-help module.
> The newly introduced print function prints the help message in XML format.
> The XML formatted help message will be useful to generate GUI for the
> target command automatically; and to generate zsh completion rules
> automatically.
>
>
> 2. Type extension
>
> GOptionArg supports only following types.
> typedef enum
> {
> G_OPTION_ARG_NONE,
> G_OPTION_ARG_STRING,
> G_OPTION_ARG_INT,
> G_OPTION_ARG_CALLBACK,
> G_OPTION_ARG_FILENAME,
> G_OPTION_ARG_STRING_ARRAY,
> G_OPTION_ARG_FILENAME_ARRAY
> } GOptionArg;
>
>
> I think it is nice to extend these types. So the automatically
> generated GUI or completion rules can use the type information.
> e.g. hostname, installed package name, etc.
>
I don't think this is worth the effort. Automatically generated GUIs
will never be as good as real interfaces, not the least because the
cmdline is not very good as an interface between a backend and a GUI.
If a commandline tool is valuable enough to be brought onto the desktop,
you should invest the effort to give it a polished interface. And
even if we added this to GOption, that wouldn't give you a single
autogenerated GUI, since all the legacy cmdline tools would have to be
ported to GOption first...
If there was an accepted "XML cmdline description language", we might
consider adding a --xml-help option, but using a loadable module for
that is just overengineered.
Matthias
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]