Grouping of global variables

[thom-le]

Hi,

a suggestion for the global section of the config files, plus an optional extension at the end.

Groups inside <global>

In our project the global section of a single config file holds around twenty entries: directories, a few numbers, five loopType definitions and five plotMapLayerType definitions. In the GUI they appear as one flat list, and nothing tells the reader which entries belong together. A <group> element with a label, collapsible in the tree, would help a lot, something like:

<global>
  <group label="directories">
    <filename label="borderDir">border</filename>
    <filename label="demDir">dem</filename>
    <filename label="gravityDir">gravity</filename>
  </group>
  <group label="plotLayers">
    <plotMapLayerType label="layerCoast">...</plotMapLayerType>
    <plotMapLayerType label="layerBorderIn">...</plotMapLayerType>
  </group>
  <filename label="tmpDir">tmp/050groopsRadialBasis</filename>
</global>

This would also make the file itself easier to read. Nothing would change semantically — the entries end up in the same map as today, the grouping is purely for the reader. It would also make a group easy to copy from one config file to the next, which is how we would use it across our ten files.

Groups should be allowed to nest, so that a larger group can itself be structured. If the loop over the children is written recursively, that comes for free.

Implementation

Config::Config fills stack.top().links from the <global> children; the existing loop would become the tail of a recursive function:

std::function<void(XmlNodePtr)> addChildren = [&](XmlNodePtr node)
{
  while(XmlNodePtr grp = node->getChild("group"))   // nested groups
    addChildren(grp);

  for(XmlNodePtr &child : node->getChildren())      // same body as today
  {
    XmlAttrPtr label = child->getAttribute("label");
    if(!label)
      throw(Exception("elements in global must have attribute 'label'"));
    child->setName(label->getText());
    stack.top().links[child->getName()] = child;
  }
};

addChildren(global);

Since getChild removes the node from the tree, the group loop and the ordinary loop do not interfere — the current code already relies on that. And since links stores whole subtrees, complex types need no special handling: loopType, plotMapLayerType and parametrizationGravityType can sit in a group like simple values, and link="layerCoast" resolves as before.

Optional: a group whose content comes from a file

A computing pipeline consists of a few config files whose global sections are identical in large parts: the same directories, the same maximum degree, the five plot layers character for character. Today every change has to be made ten times, and a typo in one of them is easy to miss. If a group could take its content from another config file, that would be solved:

<group label="project">
  <inputfile>config/projectVariablesEAlpG.xml</inputfile>
</group>

where the referenced file is an ordinary GROOPS config containing only a <global> section and no programs, so it can be opened and edited in the GUI like any other file. In the recursive function above this is one additional branch: read the file, take its <global> node, and recurse into it.

The precedence would follow from the existing design without any extra rule: links is a std::map and assignment overwrites, so entries defined locally after the group override the inherited ones, and commandlineGlobals still overrides everything.

Open questions

• For the optional part: path resolution of the referenced file — relative to the working directory or to the including config? Both are available, workingDir and groopsConfigFile are set in the constructor. And a guard against a file including itself.
• For the GUI: how inherited entries should be shown, and that they must be left untouched on save.

One thing to add: Idea comes from me, suggestion of the change comes from KI (Claude Opus 5 max).

Thanks and best regards
Thomas

[tmayerguerr]

Hi Thomas,

Thank you for your contributions and ideas.

Groups inside :
From the documentation variables:

Variables can be declared anywhere in the configuration file. Variables in locations other than the global section have a local scope and hide global variables or variables from a hierarchy level above. They are valid after declaration until the end of the hierarchy level is reached or a new variable with the same name is declared.

Some thoughts: If I can group variables in global, why not elsewhere too? But grouping variables runs counter to the concept of local scope. I understand your idea, but I think it makes the underlying concept in GROOPS even harder to understand.

Optional: a group whose content comes from a file
I actually think that’s a very good idea. There used to be a rudimentary version of this in GROOPS. However, it was subsequently removed as there was no support for it in the GUI. As you’ve already said, variables and links should be selectable. Unfortunately, implementing this in the GUI is not straightforward. However, when I have some spare time, I’ll give it some more thought again.

Best regards
Torsten