Had a rethink this morning.
One of the errors I think I made was merging the display settings for the overall Gramps environment with the settings of how Gramps displays the actual data.
So what I am thinking is reverting and a rethink of the General and Display tabs.
I’ll be back!
Cool.
If you are producing hard copy and doing annotations… you might want to highlight options that affect data being stored. (As opposed to features that just change display of data.)
For instance, the guessing (new person surname & Relationship type guessing) & auto-fill functionalities (ID leading zeroes), and the data paths (backup iterations) will all create irreversible changes when records/objects are created.
At the moment, addons don’t have any defined way to add or modify the preferences panels. So the ‘Themes’ addon had to do a hack to get integrated. As such it will probably have to be modified if any significant change to the panels (such as is proposed here) is implemented. But that is why we have different branches in our addons repository, so they can be matched with different major versions of Gramps.
Another comment; the Symbols panel is most likely being simplified in the next major version of Gramps.
How about combining Colour and Symbols in some way?
is that a bad idea?
This is counterintuitive but…
moving the colors & symbols out of the core & into an add-on would offer a great opportunity.
Built-in feature have VERY little opportunity to evolve. Minor revisions are ONLY bug fixes, no enhancements. But we only have enhancement releases once a year … and enhancement candidates are only alpha tested to a miniscule pool of people with developer skill & beta tested to a tiny pool of highly technical users.
The opportunity to get timely entry-level user feedback is non-existent. So the interface doesn’t get the detailed refinement like a commercial package would. It skips the developmental step after a functional alpha prototype is beta tested. So we bypass the market-testing that polishes it into a public release.
On the other hand, add-ons do not have that limitation. They can implement tweak-after-tweak.
Symbols went to “built-in” too quickly. It was an excellent proof of concept. But the interface barely slogs through the Font family checks.
Fundamentally there are differences in Core items and things that are Addons.
Addons are things that users can Choose to add to enhance their Gramps experience. Themes is a great addon, but Gramps does not need Themes to offer a user a genealogical database.
Colors and Symbols are too integrated in the code to have them as an addon, What would “break” if these functionalities were to left to the user to install.
Symbols was asked for as a Feature Request and Serge said I can do that. What was lacking was a discussion with the users as to what this would mean. Maybe if the issue was raised here first, the functionality would have been vastly different.
Based upon previous posts elsewhere, @SNoiraud has reworked the symbol implementation for 5.2
There is a difference between adding hooks and adding interface to the core.
For instance, I could assemble a custom postscript font that has only the dozen or so Genealogical glyphs needed for the Symbols functionality. (In the 90s, it was standard procedure to create custom font families to be embedded in Technical document PDFs and delivered to Service Bureaus for commercial printing.) And then write an add-on that includes that font & offers ONLY non-interpreted sizes of that font.
Whereas the first revision of the Symbols scanned the hundreds of font families directory for the necessary glyphs before ever offering configuration. Because the feature is built-in, we could only patch the feature or wait for the next enhancement release. The lack of feedback put Serge at serious disadvantage.
So… another option would be to enhance the program to have a preferences API for all Preference items and offer a new Preferences container that works just like the Sidebar or Bottombar. Then the tabs are just Interface designs added to the container just like adding a Gramplet. Each addon can touch any of the API features.
The benefit of this approach is that Programmers who are good with adding functionality (but don’t have aesthetics or workflow skills) can stick with their best skills. And anybody who can build clean interface with the GTK design tools can do that side & deal with the User grumblies.
I suppose you can do this already… if you write a Gramplet to parse & update the gramps.ini chunks.
I think that in the Database tab the options (import) of the section should take their place in the General tab.
I wouldn’t say that if these options were about exporting.
This will also isolate the specific parameter “Base path for relative media” which is currently embedded between global parameters.
Regarding the “Base path for relative media” parameter I think the user experience would be enhanced if a dialog allowed to specify this directory when we create a new database.
Note : I changed the thread’s title to “Brainstorming: Preferences interface”.
Best Regards.
There are only one thing I care about regarding all this “settings” and “configs” stuff, and that is that there will be a function to copy/backup the user customized settings from the software, regardless if its a database setting or a “global setting”.
Else, it can be one long list of json data pair in a list for all what I care.
I change my settings once, and usually never touch them again until I install the software on another computer or has to reinstall (approx. every 7-8 year or so).
The most logic is to have all Global settings in one tab with “sub-tabs”, and database specific settings in a tab for that, and gramplet settings in it’s own tab with sub-tabs for each gramplets that need configurations saved.
If it’s horisontal or vertical “tabs” doesn’t matter much, but it should follow all the other panel layouts in Gramps.
There should only be one button for “settings” on the button bar, and one settings/options in the menu, this selection should contain all the “tabs” for all settings for the software, but not for the config of the different views.
I don’t like is the sideways scrolling of the tabs in any part of Gramps, but I don’t know what the best alternative would be.
Don’t forget we have a limited size: 800x600
The preference window must be contained into this and this is a big constraint.
This is a developer constraint. All windows must be contained in a 800x600. We have many users with old computers and small screen.
I think you need to read that : Gramps UI style
What you want to do is complex to do. In french we call that “usine à gaz” (“gaz factory”?)
If you resize your window, I think your needs are solved.
As I am making changes, I make sure that the Preference window is at its smallest size. 
Okay. Went back to the beginning (existing) version and started again. Made fewer changes and most changes were to take items and give them their own tabs.
Welcome your comments. In particular, which order should the Tabs be in. In the smallest window size, I am seeing the first five tabs.
Again, this change was not to add any new functionality. That would occur through the normal Feature Request process.
Tabs
General – Gramps display settings. Notably, I moved the Invalid date format display from the Dates tab.
Display – User display and environment settings.
Addons – New
Database – Database setup and backup. Media path.
Import – New
Dates – Added the Max generations. The name for this tab is a misnomer. Everything on the tab is a numeric setting for Gramps to evaluate the database information. Ideas on a rename ?? These entry boxes do not allow help text. I added context help to the earlier change version. Add it, leave it ??
Symbols – Shortened the name from “Genealogical Symbols” to allow more tab real estate. Otherwise, no change.
ID Formats, Colors, Text, Warnings, Researcher – No change
After my morning walkabout…
Would it be a benefit to put the Base Relative Media Path on its own Media Tab?
In Import, swap order.
The first items should be those that to ALL imports. Then winnow down to a feature that only happen on some types … like only affects GEDCOM imports.
(Note, I put in a request that the Import menu item be active if no Tree is loaded. In this case, it creates a Tree. This steps over a common stumbling block for absolute beginners.)
Note that Dates (Ranges, Spans, Approximations, Qualifiers?) fails to set a ‘units’ expectation in the pre-defined spans … except in the Generations.
The original phrasing is ambiguous for the Ranges. It is implicit (rather than explicit) that the ’about’ span qualifier is in ‘±’ (plus or minus) years units. An ‘about’ of 50years could set an expectation of ±25years
The keyword for these spans is also not distinct enough. Would distinguishing it with text styling (bold, italic) be sufficient in all fonts? Or does the term being defined need to be set off with single or double quotes?
For the Addons tab, perhaps it could be ‘Updates’ (which encourages more use). This would leave a logical space for us to show an Alert when there is a newer version of Gramps available.
My hope is that once @Nick-Hall does his long-anticipated rework of the Plugin Manager, The Add-on management would be consolidated into a single place in the GUI. Having Add-on management in the Edit -> Preferences & Help menus complicates explaining the usage.
