Mon 25 Sep 2017 08:10:28 PM UTC, comment #11:
Thanks Mike, I missed this one.
@Philip: I do not have the impression that the auto row height slows down the variable editor (in contrast to auto column width).
|
Sun 24 Sep 2017 06:57:05 PM UTC, comment #10:
Thanks Torsten. I added
https://hg.savannah.gnu.org/hgweb/octave/rev/eadaf557ca09
to make the welcome wizard also default to disabling network access, with a FIXME about getting the default from a common location in the future.
|
Sun 24 Sep 2017 12:07:40 PM UTC, comment #9:
I see that the Variable Editor's default setting for "Autofit" (rows) has been set to "Auto".
Does "Auto" mean here that the row height is only adapted to font height + 2, or is the height of each and every individual row calculated?
I'm asking because the setting for automatic fitting of column width led to long delays while populating the variable editor window (see patch #8656 comment #38 and #39).
Rows can have multiline cells (e.g., for nested ell arrays), so there may be a risk that also auto-fitting row height my lead to long delays.
In my discussions with Michael Barnes (who did a lot of work on the Variable Editor) I suggested to leave out the entire Autofit stuff as unwary users may have no idea why it takes so long for the Variable Editor to respond which may provoke undue bug reports.
AFAIK matlab doesn't have this Autofit option either.
|
Sun 24 Sep 2017 10:04:14 AM UTC, comment #8:
I have pushed changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/1265c7f0119a
which fixes the inconsistencies in the default values.
The other two things we have discussed (include file with constants definitions and removing defaults from initial settings file) are not directly related to this bug. I am therefore closing this report.
|
Sat 23 Sep 2017 12:58:09 AM UTC, comment #7:
Two more, variable-editor.cc reads the settings "terminal/fontName" and "variable_editor/font_name" with default values of an empty string, but the settings dialog uses a default value of "Courier New".
|
Sat 23 Sep 2017 12:40:24 AM UTC, comment #6:
I went through libgui for all uses of "settings->value" with a default value in the second argument. Here are the settings that have different defaults in settings-dialog.cc vs where they are used by the various GUI components:
- filesdockwidget/sync_octave_directory, used in files-dock-widget.cc
- news/allow_web_connection, used in main-window.cc
- variable_editor/autofit_row_height, used in variable-editor.cc
All other settings look like they agree to me.
|
Fri 22 Sep 2017 09:16:37 PM UTC, comment #5:
The proposed audit is very welcome, since the differences found should be ruled out as soon as possible.
Afterwards, I would like to start working on an include file for defining the defaults in order to prevent new differences. This will take some time
|
Fri 22 Sep 2017 05:35:57 PM UTC, comment #4:
Torsten - I was going to do some grepping and share an audit here of what values don't match, but if you want to work on a refactoring of all calls to "settings->value" so the defaults are only defined in one place, feel free and I'll leave it to you.
|
Fri 22 Sep 2017 05:20:47 PM UTC, comment #3:
I think the most important issue to address first is just to make sure that the defaults in settings-dialog.cc agree with those used elsewhere. For example
These should all be false.
Whether that means a refactoring of where these values or functions to wrap how they are retrieved with their default values, up to you if you want to look at that.
Secondarily, if you think we can minimize or eliminate entirely the default-qt-settings file, that's a bonus.
|
Fri 22 Sep 2017 05:09:42 PM UTC, comment #2:
I agree that we should avoid having the default settings in the code and a config file.
It seems best to have the defaults in the code, but make it possible for settings in a config file to override them in case someone wishes to redefine personal or site-wide defaults.
|
Fri 22 Sep 2017 05:03:21 PM UTC, comment #1:
This is a good point. Should we create an include file where constants for all defaults are defined in order to avoid using different defaults within the program?
Regarding the default-qt-settings file, I suggest to get rid of most of the preferences therein as these defaults are already used when reading the settings. Maybe only the geometry settings of the main window and the dock widgets are really important for an initial settings file. If desired, I can test which default settings are required in this initial file.
|
Fri 22 Sep 2017 03:44:38 PM UTC, original submission:
Octave installs a default qt-settings file when it first starts up that contains some default values for all preferences.
Let's forget that for a moment, and imagine that the settings file is empty, or is missing some specific setting.
Both the code for the Preferences dialog and the portion of the GUI that use the setting read this setting and have fallback default values for when the setting is missing.
In some cases these values are out of sync. For example, if "web/allow_web_connection" is deleted from settings file, the Preferences dialog appears as if the option is disabled. However selecting the Community News menu item shows that it behaves as if it were enabled by default.
There may be more, I will try to do an audit of all the settings values and see where the defaults are mismatched between the Preferences dialog and where the setting is actually used.
|