octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philip Nienhuis
Subject: Re: GUI doesn't appear when using ./run-octave
Date: Sun, 23 Sep 2012 17:33:04 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6

Torsten wrote:
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.

Thanks for the explanation.

Still, Octave refused to properly startup, which could be fixed by removing the qt-settings file from an earlier version. So, somehow Qt's mechanism as it is implemented in Octave is unreliable.

An obvious guess at the cause would be a setting (or some settings) that confuse(s) Octave's GUI. Maybe they contained mutually exclusive info or so; or -as you seem to suggest- a setting name was reused for another setting type (such a mix-up would be sloppy at best).

A more robust system is needed to keep track across Octave versions of which settings file entries are used for what settings, and to help Octave avoid stumbling across inconsistencies there.

Philip


reply via email to

[Prev in Thread] Current Thread [Next in Thread]