questions about conventions for GUI preferences

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

questions about conventions for GUI preferences

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





prefs.txt (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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





Reply | Threaded
Open this post in threaded view
|

Re: questions about conventions for GUI preferences

John W. Eaton
Administrator
On 10/25/19 11:37 AM, Torsten Lilge wrote:

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

Thanks for the feedback and explanation about the reasons for the
current situation.

Yes, I meant to say

With literal strings used for the keys, 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.

Let's continue to move toward using symbolic names then.  I don't think
we need to make the change all at once.  I can help with the changes.

Thanks,

jwe