With a previous beta version, I was using a local addons “Project” filepath to install 5.2 addons. But it doesn’t seem to be working on my re-install. But there is no feedback as to whether the Addon Manager is successfully reading the list of addons.
The “Where to Check” in the General tab of the 5.1 Preferences was similar. You only knew if it was touching the file when it listed addons to install. When Gramps was up-to-date with Addons, you couldn’t tell if it failed to poll or if everything was current.
That’s true. Sorry, that .txt expectation is a holdover from a previous set of 5.1 docs… since the 5.2 Project tab only specifies the parent of the listings and download folders containing the .json and .tgz files expected by the Addon Manager.
It is kinda late for a 5.2 change. And this sounds like a simple but highly visible change. So adding for 5.3 would show evolution is still possible for recently added features.
How can the 6.0.6 be hacked to have such an indicator?
I just tried downloading a GitHub generated ZIP of the Isotammi addon repository (which includes listings for 5.0, 5.1, 5.2, and 6.0) and extracted it to the desktop of a Windows 10 box.
I have (apparently) been unable to successfully touch the .json in the listings subdirectory. I’m not confident of where the failure lay. The only feedback is “There are no available addons of this type” (twice, once in the title and again in the body) followed by “Checked for ‘update’ and ‘new’”. So I don’t know if it actually found the folder, found the json, read the json successfully, or had a valid compare.
Used the Preferences Family Tree tab’s Backup path: field to navigate to the isotmmi-addons\addons\gramps60listings folder and then harvest that path. Then converted the delimiters as indicated in the wiki. (screen capture shown in thread “Need linux and mac examples tested for local Addon Manager projects”)
So there is no idea whether the problem was with the file scheme, the delimiters, the path, the delimiter between the project and the appended component, and the listings/addons-en.json portion, the data in the json, or somewhere else.
Finally discovered the correct format for the path to a locally stored curated addon collection ‘project’. The lack of feedback (about whether the JSONs were being found and read) drove me to wish-code (with Claude) an enhanced Edit Project dialog for Gramps 6. It has validation feedback and allows browsing to set a local ‘project’ path.
@Nick-Hall My submitting the Claude code for core Gramps would violate guidelines.
But how can we take advantage of what was learned through the many iterations before arriving at a version which “ticked all boxes” for a friendly dialog which did not fight or mislead the user?
( One lesson was that the _windows.py module was too large for repeated edits, so we refactored it by splitting the ‘Edit/New Project’ dialog into a separate module and importing it.)
I had Claude write up an after action report with a full design spec. But it got even more verbose than me. I doubt developers want to wade through that much detail.
Need Linux and Mac examples tested for local Addon Manager “Projects”
The wiki has URL string examples for various curated addon collection “Projects”. The final example is an (untested) Project URI for a local collection on a Windows box.
Perhaps we could set up a “control sample” archive of a project?
Testers could extract it to the various OSes to verify that projects can be local. And produce validated examples URIs for each OS. They could also be examples that non-GitHub Developers can use to verify their testbed setups. Which will encourage experimentation on local networks.
Having a safe local setup to experiment with the make.py could let more people publish their experimental addons … before migrating a release to the gramps-project collection.
And if it was documented more, it would be easier to build local development kits. Such local distribution tools could make Gramps more attractive for programming testbed for beginning Python programming classes in high schools.
Finished another Claude-coded test of enhancing feedback in the Addon Manager and have use tested it.
This version makes the Lozenges more than display flags. Now they are “buttons” that correspond to a Filter, The button is highlighted when the filter is not at the “All” (unfiltered) menu choice. Clicking a highlighted lozenge will reset the filter to unfiltered. Clicking a default color button will set the Filter to that button’s value.
(The lozenge style is defined in the gramps.css file. So re-styling would be easy. I think the shadow should be more pale … to make it a bit more subtle.)
The version lozenge does nothing. It would probably be good if it did something with color. Maybe “Green” if the version number is higher than the installed or not yet installed, Red if it is lower version (and raises a confirmation that you want to downgrade when installing over a newer version), and default color if the versions are equal.
@emyoulation Looks like you and Claude are getting along great! These changes look helpful.
My 2 cents…this can be simplified a lot. Just add the text “update available” or “update now” next to the version if a newer version is available. Perhaps “Update to x.y.z” if you really want to go all out, but I don’t think release notes are posted for different versions, so I don’t know if that helps. Leave out downgrading unless it becomes a common workflow for the majority of Gramps users.
I don’t think that Claude’s work project will be allowed. So this may only be spinning my wheels. Also, yours is the first response in nearly 2 ½ years. Maybe it only bothers me?
Right now, the Addon Manager downgrades silently when clicking the Update button but failed to notice that the Project’s version is older than the installed. So it could use a bit more intelligence.
For an intentional downgrade, it might be reasonable to require the extra step of first uninstalling via the Plugin Manager. Just make the Install and Update buttons only appear when not installed or installed version is lesser. (Instead of merely ‘different’.)
