The Developer mode has been too quirky in the past for my comfort. After being burned a couple times, I avoid it.
In the recent Windows AIO releases of Gramps, Developer Mode seemed be the default and I hadn’t been able to turn it off. As a former (decades former) Product Manager for some Mac software, I would have felt compelled (since one Product Manager duty is to be the end-user’s advocate in the development process) to object to ‘hidden features’, particularly any that required command line knowledge to reveal. As such things would be a violation of the HIG… Apple’s Human Interface Guidelines. Are the --developer command line flags supported in the macOS flavor of Gramps?
Plus the use of command line options and Gramps environment variables has been too opaque. (Do they have to be invoked as a hand-typed command in the terminal for every use? Can they be put into a launcher script batch that is executed whenever Gramps is started? If so, why isn’t there a link somewhere in Preferences to launch a text editor for that batch file? Can you use something like the Python Eval to change those settings in a live Gramps session?)
I am unsure of what the “Developer” Audience .gpr.py does to the interface… other than make it filterable in the Addon Manager. Support of “Developer” Audience seems superficial, incomplete or rudimentary.
Many of the new addons I’ve been wish-coding would be ‘Developer’ tools and Gramplets if you were to be strict about classifying them. The Tools would benefit from be segregated into the Debug menu rather than being lumped into the crowded “Utilities” submenu. I don’t use that Audience for fear of hiding another new Easter Egg.
Most of my tweaks are Novice-level developer tools — designed to invite exploration and encourage advanced users towards stepping out of their comfort-zone onto the next stage. (Some of the ‘developer’ audience will consist of Weblate translators,WikiContributors, UX designers, tinkerer/patchers, or wish-coders rather than technically adept coders.) If they were in an GUI Easter Egg (like a disappearing submenu) then that defeats Novice engagement.
That’s important information
The snark in me can’t resist the remark that Linux has a completely different take on that, but your point still stands for Apple at minimum and we want to target all 3 big platforms. (And Apple can’t be too wrong about interface design, right?) I can see how the connection between “replace builtin plugins” and a --developer flag can be seen as opaque. I’m a big friend of self explanatory settings.
In that case, the proposal I made pretty much seems like the best option to satisfy all requirements.
2 additonal fields which indicate if the plugin is built-in and if it is overridable. Both information available at runtime. If not set, it defaults to “addon” & “replaceable”. The loader refuses to override plugins that are marked as “locked”.
The enhanced Plugin Manager can use those flags as basis for showing it in the enhanced view.
Thank you everyone for contributing to the discussion. I’ve written a Feature Request at https://gramps-project.org/bugs/view.php?id=14241 and will start implementation once someone from maintainer team has had time to confirm it.
The feature you are thinking about is the -O flag. If not set then the __debug__ variable is set to True.
It should work on all platforms. There was a bug on Windows, but it has been fixed.
Allowing core plugins to be overridden is likely to cause maintenance issues for us. If a user reports a problem then we may assume it is with core code when it is really with a third-party addon.
If there is demand for a core plugin to be overridden then it probably shouldn’t be in core.
I can also see the opposite case where a popular addon or library could be moved into core.
However, a field to indicate if a plugin is core is a good idea.
I’ll review how often core items are already actually being overriden and the decision can be taken during the PR.
Not sure if this qualifies, but…
the Themes addon overrides the list panels in gui\configure.py to be able to add the Themes tab to Preferences.
This is an example of where an addon overrides core functionality, not a core plugin.
It has failed in the past when another addon tried to do the same thing. A better approach would be to provide a proper mechanism for addons to do this. (A new plugin type of PREFERENCE to add a preference page for example in this case)
Perhaps this could be discussed further?
-
There are likely to always be reasons to override each built-in Import or Exporter plug-in.
There will always be features not yet supported and dialect support that will desired. Or new versions published for different formats.
-
Report plug-ins can always be improved.
(e.g., the various Fan chart systems could be integrated so that all Fan chart types would be available in Graphical Reports and Gramplets, not just Chart Views. And interactively configuring settings for a Chart view could be conveyed to a Report for printing the same way. And fixing a bug or enhancing … like overhangs… would automatically flow to all 3 containers: view modes, gramplets and reports.)
-
Chart view plug-ins can always be made more attractive or intuitive or communicate more information.
(For example, the 3 Fan built-in Chart view modes support Print… but none of the others do. And none support the ‘export as SVG’ found in FTV toolbar. Also known as the ‘save as’ toolbar button of the Life Line view modes.)
Actually, I cannot think of a Plugin Type where the built-ins are so perfect that there is not some opportunity to evolve.
Yes. All built-in views and reports can probably be improved.
My CombinedView was intended to enhance and eventually replace the Relationships view. As an addon I wouldn’t want it to override the Relationships view. This would likely cause confusion for both users and developers.
I have no problem with people taking core plugin and producing “enhanced”, “improved” or “plus” versions as addons. In fact I would encourage doing so. They may eventually make it into core Gramps. The point is that they should clearly be distinct from the core plugin and the core version should still be available to use.
My presumption is that the interactions of a “enhanced”/“improved”/“plus” cannot be fully exercised unless it supersedes the built-in. So every feature (that would normally default to the original) will fork to the evolved version instead.
While I would expect that the developer of an evolved could swap in the new version on a Windows install. Or for a Debian install on a Linux distro. But it looks like that is not as accessible for a Flat Pack or a Snap. And I don’t know about the access to core for the macOS installs. So broad testing as an addon would have to be repeated when the PR for rolling it to the core was submitted.
As an example, I would like to submit a replacement for the core vCard import/export plugin. And test a proposal for a brain-dead Import. (Example: new user exports the Contacts from their smart phone as a springboard for starting their Family Tree from scratch. Since a person’s phone Contacts tend to include their existing living family members. So these can be 'stitched together into Family groups.)
The built-in Importer only supports the v3 vCard but most Smart Phone exchange v2.1 vCards. So you cannot leverage the current brain-dead import workflow… start with Gramps closed and choose the OS context menu to open the exported .vcf file with Gramps. If it could read v2.1 files, this workflow would create a new Tree, rename it in the pattern of the .vcf filename, load that tree and import the .vcf data. But it cannot import v2.1 file format.
The next, most obvious evolution is:
- build a the vCard importer/exporter pair that also supports the v1.0, v2.1, and v4.0 but also recognizes/refuses ‘.vcf’ files of the Variant Call Format for genomic/DNA data. (built, ready to fulfill Feature Request 14071 )
- Feature request 12185 : patch the Import… in the Family Trees menu to do the ‘braindead’ import (new, rename,load) workflow iff no Tree is loaded. (Currently, Family Trees → Import is hidden unless a Tree is loaded.)
- enhance the importer to storeAttribute/generate thumbnails from UUENCODED bitmaps embedded as avatars in vCard records.
- expand vCard support to handle more types of embedded data
- expand
.vcf sniffing to branch to a Variant Call Format importer (even if that plug-in simply refuses to import the data with a perfunctory or even patronizing “cannot import” message.)
Doug has already written a version sniffer, but I can understand someone wanting to use their own customised code to import a file with the same extension and version as an existing built-in importer. Perhaps a “Family Trees → Import with…” that allowed the user to select an importer would be another option to consider in this case.
Yes, the sniffer by @dsblank is the reason the more version flexible vCard upgrade has not yet been submitted as a replacement for the v3-only built-in.
It seemed likely that he would need to test the sniffer-branching with real-world data files. There are lots of vCard samples available in the wild. And it is easy to export samples with familiar data from one’s own smart phone. The vCard addons were offered 3 weeks ago. So he could exercise the sniffing with the 3.0 aware built-in and this other-vCard-version-aware addon.
Once the sniffer has been sufficiently tested, the built-in vCard plugins should be replaced for the next Gramps release.