Re: Preferences or Settings?

[Rik]

On 05/24/2018 09:00 AM, address@hidden wrote:

Subject:

Re: Name of GUI Window: Preferences or Settings?

From:

Torsten <address@hidden>

Date:

05/24/2018 08:21 AM

To:

Rik <address@hidden>, Octave-Maintainers <address@hidden>

List-Post:

<mailto:address@hidden>

Content-Transfer-Encoding:

quoted-printable

Precedence:

list

MIME-Version:

1.0

References:

<address@hidden>

In-Reply-To:

<address@hidden>

Message-ID:

<address@hidden>

Content-Type:

text/plain; charset=utf-8

Message:

3

On 24.05.2018 05:22, Rik wrote:

5/23/18

Currently there is a menu option Edit->Preferences.  However, this option
opens up a window with the title Settings.  Octave should make these two
things consistent, and there is a bug report about this already (bug
#53616).  Does anybody have a good line of reasoning for whether we should
use "Preferences" or "Settings"?

--Rik

IMHO, in most programs the menu entry and the dialog is called
"preferences".

My informal survey was ambiguous.  Two KDE applications, dolphin (file browser) and okular (PDF viewer), both use "Settings".  GIMP uses "Preferences", as does Firefox.  Maybe there is a split between KDE/GTK applications?  My Android phone uses "Settings", and Libreoffice uses "Options".  I really don't care, but I'll mark one vote for "preferences".

 I vote for going this way, too, but without changing all
internal variable names, classes and files.

I think we need to change the names to match the window.  One shouldn't name variables "var1", "var2", "var3", ... because it forces the programmer to have a table, either on paper or in their head, about the type of "var2" is and what it does.  I just referenced the Principle of Least Surprise (https://en.wikipedia.org/wiki/Principle_of_least_astonishment) in another post.  In this case, it would be surprising to the programmer that a "Preferences" window is coded internally using variables that begin with Settings.  Also, by using a regular _expression_ it isn't that hard to clean this up.

--Rik