Re: GUI doesn't appear when using ./run-octave

[Torsten]

On 22.09.2012 22:08, Philip Nienhuis wrote:
> Michael D. Godfrey wrote:
>>
>> On 09/22/2012 04:32 AM, Torsten wrote:
>>> What about a command line option that controls which other settings file
>>> is used, e.g. --settings-file FILE?
>> This, at least for systems that support alias or its equivalent, will
>> allow users to configure any combination of versions and settings.
>> Seems like a pretty simple and natural approach.
> 
> Still, even to just avoid support questions, Octave version #A should
> not "hang" or bail out on incompatible settings file formats (e.g., for
> Octave version #B) if an unwary user forgets to (or cannot) issue that
> command line option.
> Remember, GUIs are regularly started from a start menu or desktop launch
> thingy where command line options are very easily forgotten or hard to
> add. Such start menu items or desktop launchers are often included with
> distribution-specific installer files (.deb, .rpm, etc) that usually
> don't know about local system setup idosyncrasies either.
> 
> My idea was rather that each Octave version would search the settings
> file for the settings it needs, and
> a- uses the settings it finds and knows about;
> b- uses defaults for settings it does not find;
> c- ignores settings it doesn't recognize or doesn't know how to invoke.
> 
> For cases b or c some warning might be issued.
> 
> Maybe Octave should remember if it found an incompatible settings file
> format and in that case warn the user when he/she is about to save new
> settings (to avoid overwriting settings for a possible other Octave
> version on the same machine).
> 
> Another solution: a settings file could have several sections separated
> by a version number header. Or maybe the version number should be a
> "setting", to be recognized by Octave so it can decide what to do next.
> 
> Anyway, I think such a mechanism should be in place regardless of the
> command line solution (which IMO is a useful addition).
> 
> Long time ago I wrote stuff like this for some SW I developed. I
> remember that while it looked easy at first sight, it turned out there
> were loads of gotchas and that devising a robust mechanism for saving to
> and reading from settings files requires careful thinking.
> 
> Philip

The file format, i.e. its basic structure, is always the same because
the Qt-settings mechanism is used. Octave does not read the settings
file at once trying to interpret its contents. Instead it looks for an
entry when it is needed and takes a default value if this entry is not
found. Unknown entries do not matter.

When new settings would be needed for a new version, the default values
are taken the first time (since they are not found in the file) and
changes of the new settings are written to the settings file. An older
version would then just ignore the new settings (as long as the meaning
of old entry names do not change). This implies that settings like
window state and geometry must get new entry names (or a new section)
when new widgets are introduced.

Therefore I think that points a, b, and c are already met by the Qt
mechanism.

Torsten