I’ve been digging into the bug 10604 in MantisBT which is about the conflict between a built-in plugin and an addon. It points to a deeper issue in the plugin mechanism which requires a design decision beyond just a patch.
In short, the bug isn’t “core plugins shouldn’t be hidden.” The bug is “plugins that other registered code depends on for resources shouldn’t be hidden — regardless of where they came from.”
It is a bad idea to hide core plugins. We should probably restrict this functionality to developers or remove it completely.
The core issue is that there is currently no real way to identify if we are talking about a built-in plugin or a 3rd party add-in at runtime and deciding if it is overridable or not. And there is no way to prevent a core plugin from being overriden by a 3rd party. You can build workaround like understanding from which directory the plugin came or string sniffing which are both hacky work arounds. The real way to solve this would be to include another property in gpr.py which allows the core plugin to decide if it can be overriden or not.
That would mean following change: add a property to the gpr.py which declares a) core or not and b) if it is overridable.
I’m happy to implement that PR - it shouldn’t be too big and we can have as default “addon” - “overrideable” which means it does not impact anyone downstream.
I finally found a way to recreate the issue. It seems likely that the user has used the ‘Help/Plugin Manager’ to ‘Hide’ the ‘Webstuff’ plugin. Since this plugin provides the CSS style sheets for HTML documents and Narrative Web reports, it should NEVER be hidden. We should probably rename the plugin and change the description to make this more clear.
With the Webstuff plugin hidden, there are no style sheets, and the HTML tab in the report dialog (always existing, although only shown for HTML reports) has no entries for the ‘CSS file’ drop-down. Thus when the code tries to get the active entry for the combobox, it gets a -1 for a result, even though the code earlier set the active entry to 0 (invalid for no entries).
The right fix would be to mark Webstuff as “builtin” and “not overrideable”, so if someone tried to remove it, it would remain.
The other one is libplugins.gpr.py which provides Library code other plugins import. The SqlLite Backend, Thumbnailer and Sidebar implementation plugins should ideally also remain I think.
The Plugin Manager already uses a path identifier today to identify the built-in status which is brittle. But also things like showing an uninstall button doesn’t make sense, help with update routing, etc.
Excellent question - I’m not sure what prompted the design decision around Webstuff or lib* at the time, but they probably shouldn’t have been implemented there at the first place. Moving them would mean a massive renaming campaign though - we’d have to move the namespaces in order to stay consistent or use a compatibility shim.
That would affect 15 3rd party addons and 84 sites in gramps code (mostly inside the libs themselves and maps)
I guess you would have to choose your poison - additonal flag for sake of safety or moving them out of the way and impact everyone downstream. At least the issues would pop up at build time.
The plugin manager enhanced, but not the built-in plugin manager, prevents views from being hidden. Can a setting for the relevent gpr files be created and regognized by the plugin mangers to prevent the plugins from being hidden?
Am I being thick but on my version of GRAMPS
The Plugin Library “Webstuff” is only visible if you select
“Built in” items from Plugin Manager Enhanced and is clearly marked as
“built in”.
Surely the warning should be do not remove any “built in” plugins or on
your head be it.
phil
ver 6.0.6
Python: 3.13.5
sqlite: 3.46.1
orjson: 3.10.7
LANG: en_GB.UTF-8
OS: Linux
Distribution: 6.12.88+deb13-amd64
You are right, but the connection isn’t always obvios and ends up generating tickets and costing time to triage. Anything that generates multiple tickets is worth taking a look at and left-shift as much as possible, i.e. planning ← develop ← testing ← deployment ← use
The more we can ensure these kind of things don’t happen in the first place, the easier it is for the devs to focus on important stuff and developing cool, new features.
Which is why moving the code out of the API surface is the smart suggestion, it just won’t address all scenarios unfortunately.
1)Why does the “Show Built-in Items” need to be there at all, I suspect
90+% of users would never access this feature.
2)If “Show Built-in Items” really needs to be there why not when
selected does it not disable the “Hide” button.
phil
This experimental Plugin Manager is already operational with Gramps 5.2 through 6.1 … except for the selecting the thumbnail preview for the selected plugin. (There will need to be an enhancement to the .gpr.py to store a URL for the screenshot. And I’ll probably need some help working out how to use the Thumbnailers to scale and cache thumbnails of those screenshots.)
This enhancement to the Addon Manager required patching the core module, adding a helper module for validating the Project definitions, and the gramps.css file
It’s a feature which allows the additon of new addons such as the Enhance Plugin Manager and other extensions. It allows the community to do it’s own work without necessitating the involvement of the maintainers. That’s a case of security vs. open for experimentation
Built-in != not allowed to hide. As per comment above, that was the feature the maintainers decided on. It’s legitimate to ask if these features are really necessary, I didn’t do that - instead I’m proposing how we can make it safer for everyone.
In fact, your Plugin Manager Enhanced would benefit from the suggested improvements. Right now you are using a work around (path sniffing) to determine if a plugin is built-in, if I’ve read the code right. This would make it more explicit.
The blocking would enhance both managers as it provides explicit instructions if a built-in plugin can be removed or not.
So I disagree with the “no changes required to .gpr.py”, but defineitely think the enhanced Plugin Manager has merit on its own.
I’m very much in favor of evolving .gpr.py. My pushback (“no changes required”) isn’t opposition to your GEPS – quite the opposite. I’m thinking about how we might enable earlier access to tools that broaden participation in that discussion.
At the moment, feedback on the .gpr.py GEPS tends to come primarily from contributors who are already comfortable working directly with the codebase. That’s understandable, since meaningful experimentation currently requires that level of access and expertise.
For contributors focused on UX, UI, or visual design, the path to experimentation is less direct. They typically need to collaborate with a developer to prototype ideas, which introduces an extra step: aligning on priorities, translating design concerns into implementation details, and fitting that work into an already full development queue.
That collaboration is valuable, but it can also slow down or filter out exploratory ideas – especially those centered on usability, aesthetics, or interaction design, which are harder to evaluate without something tangible to try.
What I’m aiming for is to lower that barrier: creating ways to build and share useful experiments with more practical, hands-on knowledge, without requiring deep familiarity with the underlying implementation. My hope is that this complements the existing work by bringing in a wider range of perspectives earlier in the process.
Along those lines, I have been building GUI-oriented bridges inside the Gramps interface to make experimentation more accessible, including:
exposing CSS layers to direct experimentation
some GUI to surface missing or problematic translations and streamline suggestions via Weblate
Tools for exploring Gramps constants and environment variables
easing access to extended character sets
GUI for discovering and reusing icons from themes and the core application
Inline documentation with the ability to include visual illustrations of the GUI
automating publication of experimental addons (enables private sharing of alternatives that explore beyond current architectural design and constraints)
Sample visual feedback experiments enhancing the Gramps GUI
making README.md markdown files from GitHub repositories (and installed addons) viewable within Gramps
increasing direct access of indexes to developer docs (Sphinx) and wiki (multilingual Gramps Glossary lookup)
Although not technically competent to respond to you regards code my
issue stems from the initial discussion about experienced users having
to spend time sorting problems that should not be.
I am guessing these are mainly new or inexperienced users (and a large
group of the experienced)who have no real need to know about workings of
the plugin system they just want it to work.
So I suggested what I thought was a simple preventative measure.
phil
And you are absolutely right to question that - it makes sense. Reduce the complexity and make it easier for new users is always a smart move. It’s good to question, so I see it as a valuable “wait a second … have you thought this through?”
The primary conflict is your call for simplicity vs. the wish to give 3rd parties access to modify the code base. If the requirement is to be open for change, we need to strengthen the protective measures for exactly such new users you are referring to. So - if you want the openess, then there is a certain amount of complexity that must be added. If not, your idea is the right instinct.
I agree totally with you that GRAMPS has to be open for change.
Daft idea
Scenario if you have the “Select Built-in items” and if selected disable
the Hide button. So all can see the built in’s etc. Somebody gets
interested and then asks the question how do I get round this, the
reason being “I want to modify x,y,z” Maybe a release code or patch
could be given with suitable warnings.
phil
Yeah the sniffing was a failed experiment. Instead, I had to ‘hide’ the @prculley original Plugin Manager Enhanced to use the experimental Plugin Manager plus
Nick had suggested to use the --developer command line flag for that idea. That would move the second item “may not be overriden” from the gpr.py to the command line and still make it overrideable for people who want.
Both are valid options. @emyoulation - what are your thoughts on this?
