Hi Mayank, On Tue, Jun 21, 2016 at 2:32 PM, Mayank Agrawal <[email protected]> wrote:
> for the v.buffer (v.buffer --interface-description), there is option for > "input vector map" and "output vector map" (screenshot > <https://cloud.githubusercontent.com/assets/12744703/16241571/e05a7402-380b-11e6-9701-9c211da3ebc3.png>). > When you see the xml > <https://gist.github.com/mayank33/5dccaa844787abee280c0291a1561ed2>, then > you will notice "input vector map" is under label > <https://gist.github.com/mayank33/5dccaa844787abee280c0291a1561ed2#file-buffer-xml-L12> > tag > and "output vector map" is under description > <https://gist.github.com/mayank33/5dccaa844787abee280c0291a1561ed2#file-buffer-xml-L95> > tag. > Though both are shown at same place in dialog box. Same thing is done at > many places in different modules. I want to know whether it is on purpose > or some kind of error as this makes the parsing of xml for generation of > dialog box, a little bit tricky. At some places, description tag is used > and somewhere label tag is used. Also any help in this regard(parsing) will > be highly appreciated. > The current definition of the option label and description is that description is filled out and when it is very long, label is filled out as well to provide a shorter text which can be shown in things like GUI. The same applies also to flag and module. Both of them can be empty (which is of course not good, but it is supported by --help). It may be obvious that the definition is actually a legacy thing because originally there was only description, so the modules usually define just that. The label is a later addition which is not always present. This is of course not ideal but that's the current backwards compatible state. The right way to implement it for the (relatively short) labels in GUI is to use label if available and use description if it is not. When the manual page or --help are created, both are used if present, first label followed by description. Hope this helps, Vaclav
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
