Re: questions about conventions for GUI preferences

[Torsten Lilge]

On Fri, 2019-10-25 at 02:28 -0400, John W. Eaton wrote:
> In some cases, the names and default values of GUI preferences are 
> defined as symbolic constants in header files.  For example, in 
> gui-preferences-ws.h:
> 
>    const gui_pref
>    ws_hide_tool_tips ("workspaceview/hide_tools_tips", QVariant
> (false));
> 
> In a few recent changesets, I tried to use these symbolic names that
> are 
> already defined in a consistent way.  I noticed a case where the key 
> name was used as the default value and another where the identifier
> for 
> a font size was used where a font name should have been.  I also
> spotted 
> an incorrect use of a literal preference key.
> 
> We also have many literal character strings used for preference
> keys.  I 
> came up with the attached list.
>
> I saw (and fixed) at least one case where we had a symbolic constant 
> defined with a key name and default value but the default value was 
> repeated literally in the code so changing the value in the symbolic 
> constant wouldn't have had any effect.  Having constants defined in 
> multiple places seems bad to me.
> 
> It also seems odd that we would have (for exmample) a symbolic name
> for 
> the variable editor font size but not the font name.  Why?
> 
> Should we try to define and use constants for all preference keys and 
> default values, use literal strings everywhere, or some mixture as we 
> have now?
> 
> With symbolic constants, it's harder to have typos in the strings
> used 
> in various locations.
> 
> With symbolic constants, it's easier to know exactly what the key is 
> without having to search but it's harder to ensure that there aren't
> any 
> typos in the names and harder to change the name of a key.  Not that
> it 
> matters too much, because it is already hard to change the name if
> you 
> want to preserve backward compatibility with preference files from 
> previous versions.
> 
> Comments?
> 
> jwe
> 

The reason why I started to exchange the literals by symbolic constants
for key names and default values was to prevent typos in the "hard
wired" strings which already led to one or two bug reports in the pasts.

I only added symbolic constants in cases where I was working on the
related preferences anyways. That's why we currently have this mixture.

I really vote for changing all still existing literals into symbolic
constants for the reasons that have already mention in your mail (in the
last paragraph, did you mean "With literal strings, ...")? If this is
the common opinion here, I would raise the priority of this issue and
work on this for the next time.

Torsten




Torsten