After hours of fighting, I managed to implement a workaround. The
problem is that when creating an ini file from scratch (for example for
MeteoIO) and running it directly (after saving it to a file), the
workflow output path can not be read (${key:OUTPUT::METEOPATH} can never
be read, it is actually empty). This comes from the fact that
MainWindow.getINI() does not contain the same keys as in the INIParser
just after saving... So the dirty fix is to copy this content to
MainWindow.ini_ just after saving so the WorkFlow object has access to
the user provided configuration. Hopefully, a clean fix can be developed
at some point.

Noteworthy: Removed fixed shortcut in doc because it is OS-dependent.

As well as a minot tweak in the project file

Unfortunately, the Snowpack provided examples require to run on level higher than the config files. This is now possible but made me realize that relative paths should not be expanded against the path of the ini file but against the current working directory (the other convention makes sense for include files but not for the inputs/outputs)

(Because the rest of INIshell is very clean concerning OS-specific code, so it's nice to collect it)

Properly implement and document the newish workflow checkbox so it can be called by ID as the others. Minor cleanup in recent features; typos.

I did not see it being used anywhere, so if it is, please check if
something broke.

A missing icon (on Mac) has also been added

Some obsolete calls for Mac have also been removed.

Do mini TODO: start showing a hidden Number when the minus sign is entered. It's not perfect but better.

Properly implement yesterday's 'buildall' option - this is actually really useful to decide between a safe and a performant build method (XMLs must be crafted more carefully and are less flexible for the latter but if it fits all is fine)

(Be consistent about when to show it, no non-functional combo boxes)

Remember splitter sizes also when hiding/showing the Workflow - this makes toggling the Workflow via the menu much more user friendly

If a path that is referred to in the workflow is relative, it is now converted to absolute based on the location of the ini file. This is what makes the most sense and allows directly opening the results files.

This means that the PATH variable receives more locations where to look for the application that should be launched by the workflow. It is assumed that the workflow name is also used (all lowercase) in some potential directory names that could contain the executable for the said application.

Now the user can chose to either use as working directory the one of the ini file or the current one. The first elements of an enhanced way to find applications even not in the PATH have been laid out, it will now be customized for each platforms.

When the application was not found in PATH, it would fail to notify the user, thus letting the user believe "something" is running. It now properly reports to the user that the executable was not found.

Some icons were still not working, this has been fixed. The search paths for the application files has once more been tweaked to behave better with Linux usage. The ini files panel now shows the path centered, italic and on a neutral background. The pre-defined buttons roles have been set where possible/applicable. When a workflow external application run is fininshed, the application notifies the user (blinking taskbar icon, bouncing cursor, etc depending on the platform). The XML validation had a bug: it converted the bytestream to the local encoding when it must be to utf8. And finally, some more micro-optimizations.

There is now an icon theme that can be used on Windows and osX (but the user theme is still used on Linux), the search paths are now plateform agnostics (thanks to Qt) and the icon toolbar can not float or be moved anymore

The snowpack workflow does not provide a default start date anymore (there is no obvious choice) and the "now" date is rounded to the start of the day

The color scheme has been redesigned and now follows Solarized (https://en.wikipedia.org/wiki/Solarized_(color_scheme)). Instead of directly coding colors in the code, they have all received symbolic names and then the names are mapped to a specific color. On the long term, we will be able to offer several color schemes, like Solarized, osX, Windows, etc

Disable panels' context menus for grouping elements that could show up on a few pixels. Minor XML tweaks and (very) minor code optimization.