Issues with GROOPS GUI Latest Version – GROOPS 2024-06-24 Release

[grkal]

Dear GROOPS Team,

The reason for sending this message is due to some issues that I have been facing with the latest GUI version (after GROOPS 2024-06-24 release) when using GROOPS configuration files of relatively large size which I have created for some specific tasks related to data handling/processing.

The GROOPS version that I'm currently using is after commit "cee7961" on 20/09/2024.

The same scripts have been tested both in a Linux platform (compilation of source code included in “gui” folder after commit "cee7961" on 20/09/2024) and in a Windows platform (use of precompiled libraries included in “groopsGui-2024-06-24-win64.exe” file provided with GROOPS 2024-06-24 release) with the same issues being present.

In order to practically demonstrate the issues that I have faced so far with the latest GUI version, I created two GROOPS configuration files which you will find inside the attached “IssuesWithGroopsGui20240624Release.zip” file; “GroopsLargeSizeFile.xml” file and “GroopsSmallSizeFile.xml” file. Both scripts are doing the simple task of going over a loop containing a manual list of filenames and creating an empty file with the corresponding filename in case it does not already exist. The only difference between them is their size with the first one replicating a GROOPS file of a relatively large size (292 KB – which I would not regard as a large file size but the issues occur even in files of this size); the disabled “GroupPrograms” program included in the “GroopsLargeSizeFile.xml” file was created so as to increase the file size.

The global variables mentioned below are included in both scripts.

The issues which I have encountered so far are as follows:

1. Editing the values of global variables of some specific types takes unexpectedly quite some time to be executed with the new GUI version; this task was performed almost instantly with the previous GUI version (GROOPS 2023-08-25 release). So far, I've noticed this type of behavior when trying to edit a global variable of "string", "time" or "filename" type. For example, changing the value of the global variable "OperatingSystem" ("string" type) from "Windows" to "Linux” takes quite some time to be executed.

   It seems that with each edit, i.e. typing of a new letter, the whole .xml file is reevaluated and this causes the longer execution time. On the other hand, when editing the "string" config element of "manualList" option of a "loopType" global variable ("Loop" class), e.g. the “loopMyManualList” global variable, the edit is performed almost instantly (as expected).

2. Additionally, adding/copying a new global variable/program in a script of large size causes the same type of behavior, i.e. it takes quite some time for the new global variable/program to be added/copied. This task was also performed almost instantly with the previous GUI version.

3. The "Ctrl+Shift+Up/Down: Move unbounded list element (e.g. program, layer) up/down" keyboard shortcut does not seem to work anymore in the global variables section which was helpful to quickly rearrange the order of global variables.

4. The same configuration files (which have a relatively large size) take considerably more time to be opened in the new GUI version compared to the previous GUI version.

5. Finally, another remark is related to an issue which was also present in the previous GUI version but the new GUI version treats it differently. Specifically, a global variable of "string" type is not offered as an option in the drop-down list of the "string" config element of "stringMatchPattern" option of "conditionType" global variable ("Condition" class).

   In the previous GUI version, if the user had set the name of the global variable without brackets the configuration file would not show any problem in the syntax of the configuration file; in the new GUI version, though, it is treated as a broken link. As an example, you will see in my attached scripts the "conditionIsWindowsBrokenLink" global variable where a broken link message is appeared when the “OperatingSystem” global variable has been set as the value of the "string" config element without brackets.

   This is not exactly a problem, since the configuration file is executed normally if the broken link message is ignored but I would like to point out this behavior of the new GUI version. I think that the broken link message appears in the new GUI version because the “OperatingSystem” global variable is not offered as an option in the drop-down list of the "string" config element; as a result, someone could claim that the broken link message of the new GUI version is correct. Is my understanding correct?

In conclusion, I believe that it would really help if the aforementioned issues would be resolved, otherwise handling of configuration files with relatively large size has become really difficult with the new GUI version.

For the time being, I have found as a workaround to the aforementioned issues the use of the previous GUI version for the latest GROOPS version. I know that by using the previous GUI version I do not have access to some important features which have been added with the latest GUI version, with the declaration of a variable locally instead of only globally being the most important one, but could there be any other potential issues I might face if I use an older GUI version with newer GROOPS ones?

Thank you very much in advance for your time and I am looking forward to your feedback.

Best regards,
Grigorios Kalimeris
Chair of Astronomical and Physical Geodesy
Technical University of Munich

IssuesWithGroopsGui20240624Release.zip

[tmayerguerr]

Dear Grigorios,

Thank you for the detailed report. I pushed a new version of the GUI in the main branch. Can you compile the GUI yourself? Building the Windows installer is always a bit complicated.

• Ctrl+Shift+Up/Down not working for variables: hopefully fixed.

• Broken links: Should work now.
  The distinction between different numeric types (int, double, ...) and also different string types (string, filename, ...) is more or less obsolete in GROOPS, as they all run through the same parser. I have modified the GUI so that the links of all numeric/string variables to all adequate elements are offered.

• Slow performance when evaluating variables:
  The evaluation of variables has become much more complicated with the new version, as you can now define variables not only in the global section but at any point (with local scope). Nevertheless, I have managed to improve the performance somewhat. Personally, I don't like very large scripts, as I then easily lose track. I divide longer processes into several files (01groopsConfig, 02groopsConfig, ...). That's why I didn't notice the slow performance.

Best regards
Torsten

[grkal]

Dear Torsten,

Excuse me for my late reply; last week was a little bit difficult to find the time needed in order to test the modifications which took place in the GROOPS GUI and provide you with a detailed feedback.

First of all, thank you very much for promptly making these modifications in the GROOPS GUI.

I tested the modified GUI version in both a Windows platform and a Linux platform. My feedback is as follows for the two operating systems:

• Windows Operating System

  I managed to compile the GUI myself. So far, I have been installing the GUI by using the precompiled binaries included in the respective execution file given with each new release of GROOPS.

  Unfortunately, the performance of the GUI when it’s compiled by the user instead by using the precompiled binaries is a lot worse regardless of the GUI version. I tested different GUI versions which led to the same conclusions.

  Specifically, handling of GROOPS configuration files of relatively large size is really difficult; sometimes when trying to perform certain edits, like adding new global variables, the GUI crushes. In general, the speed of every edit is a lot slower compared to that one of the GUI which is installed with the precompiled binaries.

  As a result, until a new Windows installer for the GUI will be published in the future, I’ll be using the previous GUI version (GROOPS 2023-08-25 release) for the latest GROOPS version.

  I know that by using the previous GUI version I do not have access to some important features which have been added with the latest GUI version, with the declaration of a variable locally instead of only globally being the most important one.

  However, could there be any other potential issues I might face if I use an older GUI version with newer GROOPS ones?

• Linux Operating System

  I will give my feedback over each of the issues I mentioned in my first message.

1. Issue: Editing the values of global variables of some specific types takes unexpectedly quite some time to be executed with the new GUI version

   Feedback: Fixed – It would be nice if an even better performance could be achieved in the future

   With the modifications which took place the performance of this task indeed has been improved substantially. It is a lot easier now to perform this kind of edit. Again, it takes some time but it is by a wide margin less than the one needed before the modifications took place.

2. Issue: Adding/copying a new global variable/program in a script of large size takes quite some time for the new global variable/program to be added/copied

   Feedback: Fixed – It would be nice if an even better performance could be achieved in the future

   With the modifications which took place the performance of this task indeed has been improved. Again, it takes some time but it is definitely easier now to perform this kind of edit.

3. Issue: The "Ctrl+Shift+Up/Down: Move unbounded list element (e.g. program, layer) up/down" keyboard shortcut does not seem to work anymore in the global variables section

   Feedback: Fixed – It would be nice if an even better performance could be achieved in the future

   This issue indeed has been fixed with the modifications which took place. This task was performed almost instantly with the previous GUI version; nevertheless, the amount of time it takes now is manageable.

4. Issue: The same configuration files (which have a relatively large size) take considerably more time to be opened in the new GUI version compared to the previous GUI version.

   Feedback: Fixed

   With the modifications which took place the performance of this task indeed has been improved substantially. I would say that the performance of the previous GUI version in performing this task has been almost reached.

5. Issue: Broke link message/ Drop-down list of global variables

   Feedback: Not fixed (A new issue appears)

   With the modifications which took place the issues which were described in my first message were resolved; however, a new issue has been created.

   Specifically, only the global variables defined before the global variable which the user wants to define are offered as options for its value; the global variables defined afterwards are not included.

   This behavior also leads to a broken link message in case a global variable is located below a global variable in which it has been declared.

   As a result, there is a need for a modification that will allow for a global variable to have as a potential input for its value also the global variables which are defined below.

   In order to practically demonstrate this new issue, I created the “GroopsBrokenLinks.xml” GROOPS configuration file which you will find attached inside the “GroopsBrokenLinks.zip” file. In this script you will find some examples which describe better what I mention above.

Thank you very much in advance for your time and I am looking forward to your feedback.

Best regards,
Greg

GroopsBrokenLinks.zip