bugGNU Octave - Bugs: bug #52090, default values for missing GUI...

 
 

bug #52090: default values for missing GUI settings out of sync between settings dialog and actual behavior

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Fri 22 Sep 2017 03:44:38 PM UTC  
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Inaccurate Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

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).

Torsten <ttl>
Project Member
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.

Mike Miller <mtmiller>
Project Administrator
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.

Philip Nienhuis <philipnienhuis>
Project Member
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.

Torsten <ttl>
Project Member
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".

Mike Miller <mtmiller>
Project Administrator
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.

Mike Miller <mtmiller>
Project Administrator
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

Torsten <ttl>
Project Member
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.

Mike Miller <mtmiller>
Project Administrator
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.

Mike Miller <mtmiller>
Project Administrator
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.

John W. Eaton <jwe>
Project Administrator
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.

Torsten <ttl>
Project Member
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.

Mike Miller <mtmiller>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by mtmiller (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-09-24 ttl StatusNone => Fixed
        Open/ClosedOpen => Closed

    Back to the top


    Powered by Savane 3.3