Brainstorming: Preferences interface

One of the core considerations is the window size.

Disable any Themes settings and shrink the Preferences window to its smallest size. This limits the amount of real estate available in each tab. Everything in each tab should fit into this space.

I have tried to limit the size of the Tabs by keeping their names as short as possible. This sets 5 tabs shown across the window with scroll L&R buttons. I have tried to put the 5 most accessed tabs as the first to display.

I asked about multiple rows of tabs which received unfavorable feedback.

And as @SNoiraud points out most users will have larger displays to expand the window.

Should the Surname guessing and Default family relationship be brought into this Input area?

How about Data for what has been known as Display . And does that free up Display to be used instead of General?

Yes, why not if others agree.

I was looking for a good title. I think it could be.

1 Like

Is there any data at all to support this assertion? Anyone who’s bought a computer since the late 90s (generously) has a monitor bigger than that.

I suggest having a look at the pref panes in any recent version of MacOS. Hereʻs a screenshot overlaying the gramps prefs window at its smallest on my system with the Safari prefs. Forget the details except for the fact that Safari squeezes in twice as many tabs in the same space.

2 Likes

Seems a nice proposal to me.
Probably needs to use a gtk stack instead a gtk notebook.
And some new icons …

Best regards.

How does those relate to “Input”?

Why not having more dimensions using double, even triple, entry preferences window like this one from another open source app: xnview

2 Likes

Not to throw monkey wrench into the works but…

there are a few Preferences issues that continually bite users.

It isn’t easy to distinguish what settings are stored with the Tree. (These are the items that migrate with a backup. Like the Media relative path.)

It isn’t easy to see which settings have been changed from default, what the default setting was, or to reset to default without manually managing files/file-content in the User Directory. (When you mangle a setting, it may be hard to get back to a place where Gramps works predictably again. Hopefully, the wiki IDs the default so it can be restored piecemeal.)

It isn’t easy to flush stored dialog sizes & positions, sidebar/bottombar configurations.

1 Like

The two settings are automatically added to a record when created. So they are automatically Inputted.

The other settings in the group deal with how the user’s data is displayed but I had kept the settings with these display settings because they dealt with the user’s data.

I still think those are more like “General Settings”, neither of them are anything a user can control, it’s an on/off setting.

Most people think of “Input” as something they can add themselves, or at least to some extend control the “Input” data at usage…

I second the suggestion of @PLegoux

That would confirm more with the main workspace of Gramps… With sidebar and “Main Workspace”


In Addition:

The settings that are stored in database should be separated from the Global Application Settings.

There should also be “Reset All”, “Reset Global” and “Reset Database” settings button, in addition to “Backup All Settings”, Backup Global Application Settings" and “Backup Database Settings” to file Button.
The “Setting” word can be changed to “Configuration”.
And of course an “Import Saved Settings” function.

If you are going to change anything, please improve the functionality, don’t just change the GUI because “you don’t like it the way it is”.

ALL changes to the different toolbars, placement of buttons in the workspace (Gramps main GUI) and so on has to be optional, there are many Gramps Users that like Gramps as it is, and they shouldn’t be forced adapt to another persons personal preferred workflow.

The placement of Buttons or menu items could easily be customizable by using a sortable index system like the Table Columns in the Main GUI.

About preferences, I’ve just upgraded to 5.1.3-2 and I had to tweak the tag.py file to manually change the default new tag color to white (default hard coded color is black) to use them with the black/dark theme.

In the future preferences version could you add the possibility to choose the default new tag color?

2 Likes

It would be nice if the default Tag color palette was Style-aware. I expect that there is a standard Text color and a high contrast highlight text color in all the Style definitions for Themes? The default Tag color should be that high-contrast color instead of the standard text color.

2 Likes

I think it should be related to the theme : dark or light. => no need to have another option.
dark => white and light => black