The drag & drop behaviour of the text editor itself is kept as-is
(moving text blocks with the mouse etc., and also inserting file names
if dropped into the text area) because we don't want to re-implement all
of this ourselves.
However, we display a guidance text if a user drags files over the text
area telling them where to drop them to open.

Ideally, it should onyl be printed the first time a command is executed
(this is useful for users who have multiple versions of a binary as it
is the only way to have a chance to figure out which one will be
called). Otherwise, minor constifications in main.cc

Height and width set in XML have just been ignored (they were expected
as option nodes, not attributes).
This has been fixed. Please revisit your spacer sizes...

We agreed that "it's a feature not a bug", the issue is closed, and I'm
still certain that this is necessary and ok. Hence, I'm humbly replacing
the "HACK" flag with normal documentation.

Sorry, this line was different previously ;-)

If a user starts just entering stuff then we show the value, even if it
may not be valid yet.

Same convoluted mechanism as for the Number panel, but so far it's a bit
easier here.

The format string decides whether to display date, time, or both.

If the default value of the panel was the same as the minimum value (as
per the XML) the Number would stay empty (because internally no signal
that the value has changed is emitted). Only 0 had been considered but
not other minimum values.
Quick fix: Style as non-empty whenever a change request is registered,
probably leading to some duplicate calls of this for "good" cases.

The new default value set in MeteoIO commit 2633 is also now the default
value in Inishell

Exclude ';' from coordinates input (as this is a marker for comments, it can not appear in an ini file with another meaning)

The ACDD keys have been renamed to be prefixed by ACDD_ instead of NC_.
Both NetCDF and SMET now support ACDD.

As well as some reformatting for some help texts

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.

Such plugins are now italicized so the user has a way to know they might
not work on his/her system.