Add Isotammi addons to Project Manager defaults #1827
Conversation
|
@Nick-Hall How do we make that reset button use the same defaults as the config.py defaults? |
|
As much as I like this personally I believe that the Restore project defaults button in the Addon Manager should only restore the default managed by Gramps project addon repository, all other repositories like Isotammi etc should be left as entries but be unchecked when restore (Gramps) project defaults is pressed , instead of the current behavior that deletes all my added external repositories ! Question should the Gramps project really have external addon urls that can not be verified and would only really be for advanced users! By changing the behavior of the restore project default option as described above we get around the issue of losing those entries! Another option is to be able to load a file that has those optional repositories listed? @kkujansuu this pr should target gramps master |
Yes, I think it should. But only after the URL has been validated by someone in the Gramps team and with it deselected by default. We need an effective example of a 2nd addon collection to demonstrate the value of the Addon Manager... and the Isotammi project demonstates incredible value and how a Genealogical Society can leverage Gramps towards their own needs. I agree about not wanting to purge my custom Projects. But there is a distinct need for a reset when novices mess up their addon manager |
|
@Call-Me-Dave Yes I agreed change the how restore works and only keep the default from the project. I like the idea of having a file to load all the other external repositories.
The problem is what happens when the repository is malicious, sure you verified it , but what happens 10 minutes later, you can really only verify Gramps projects repository the aim should be to encourage other developers to eventually add what they have created to the main repository for normal users! Look at all the troubles with other projects like pythons pypi repository or even ruby's RubyGems repository, event androids store and apples store with malicious apps etc!
I disagree with that false logic! Even that project is a reason why you should not as didn't they announce they disbanded the project, which if anything makes them a good candidate to roll it into the main repository especially for discovery?
Maybe the restore option could be two level , first option only restores gramps repository and disables all the other respositories but keeps them and the full reset option deletes everything else but keeps Gramps. A lot more though should be given to this before going any further and this should be discussed else where. |
The Isotammi announced discontinuation of hosting their Server. (Used as a self-service uploader pipeline to their curated Finnish genealogical data.) It wasn't getting sufficient traffic to justify the expense. Meanwhile, the addon collection on GitHub does not have a cost to be justified. So it is unlikely to suffer that fate. |
@Call-Me-Dave Why not just package the files normal gramps addon library file that can be installed via the addon manager and if the addon manager detects the json file or some setting from the addon it shows them in the addon project list. This would have the benefit of the Gramps project managing that list separately from the distribution of the program and being able to update the list as needed? |
There's a reasonable justification for this approach. However, the distribution of Rules for filters is a similar concept and hasn't worked smoothly. (We've had 2 rule packs and the additional rules are not easily discovered.) Moreover, distribution of Custom Filters, books of Reports, and packets of sources/places/SuperTool_scripts/HistoicalContext content are other features that could use an elegant sharing functionality. So that needs discussion. The expandable Projects feature needs exercising to see if it works in the field as envisioned. I strongly suspect that a broad field test will reveal usability will be less than hoped. |
Nothing like what is being suggested here, as with the rules they need a bit of refinement in the way Gramps treats them when you have created a rule/filter that references the addon rule but it is not installed, gramps should recognize ( have some type of placeholder) that says hey that filter needs the rule pack installed to work before running!
The addon could simply be a plain (*.gpr.py) file packaged with a externalrepositories.json file. Hell you could even have a second *json file (say update.json) that has details of the current version of Gramps and if updated to a newer version of Gramps , have a popup in Gramps that mentions a new version of Gramps is out ? |
Similar is not "the same" What we've been discussing is the distribution of tiny customizations. Each rule is similarly tiny ... and they ended up in packs. Less clutter and easier maintenance. Sharing Projects might end up being as much of a maintenance nightmare as the WebConnect packs. The various services have so much linkrot that the new releases already had bad links. Or the Geography mapping service that was added in beta and died before we hit release candidate. Custom Filters and Addon Manager Projects share a common problem.... their are too many steps to set on up with insufficient validation. And they are very susceptible to failure due to transcription typos. SuperTool scripts can be shared as Files or pasted as XML into the Import Text gramplet or pasted into a Note of "SuperTool script" type. But they're still a fussy pain to share and organize. You can share a Custom Filter as XML but the other person still has to find the file in the Gramps User Directory and paste it in the right way. The GPS coordinates for Places were only 2 fields but were still enough of a pain that Serge added CSV field with a parser. The Projects are 3 fields. Maybe the "Add A Project" dialog needs a CSV field that parses too? And a copy button to make a "Project" into a CSV clipboard object that is easily shared. |
@emyoulation Just extend what @PQYPLZXHGF suggested to handle all that link rot! Have various *.json" or whatever files that overide the builtin ones from the addon or Gramps itself for the mapservices etc Or distribute the addons without the link rotting urls etc and have those addons require @PQYPLZXHGF suggested addon as a single place to collect those links for update (including exitsing (yes exiting :) ) SuperTool scripts/collections if needed )? |
Nick-Hall
force-pushed
the
maintenance/gramps52
branch
from
d027cda to
95a58c1
Compare
Nick-Hall
force-pushed
the
maintenance/gramps52
branch
from
95a58c1 to
52849a6
Compare
Nick-Hall
merged commit 52849a6
into
gramps-project:maintenance/gramps52
|
I guess no discussion from leader @Nick-Hall was the way to go! |
|
@Call-Me-Dave Is anyone objecting to adding the Isotammi entry to the list of projects? I can easily revert this. |
I'm guessing this from the comment above, and I kind of agree as you are technically adding a feature to an old release instead of to the new release! Adding this basically blesses the Isotammi entry as approved and run by Gramps project as users are not going to see the difference especially given the behaviors for the restore button, if any thing the available external projects list should be downloaded as part of the addon list as mentioned above! Some more work is needed. I can understand the snippy comment, as why have a discussion, just to be ignored! |
|
I'm sorry. This PR just wanted to add Isotammi to the projects list. The discussion appeared to be about enhancements intended for the master branch. |
|
The "Projects" feature is all about having options outside the glacial "blessing" of the gramps‐project addons. And if the Isotammi group hasn't proven themselves to be a trustworthy asset to this open source project, then I fear that doing so is utterly impossible. As I posted earlier, without a built‐in example of an alternate repository, this feature will not be exercised enough to give broad feedback. I agree that it needs additional work. (Including the reset, reducing the redundant hard-coded entries, feedback that the project connection finds a addonlist-xx.json and in which language, a local addonlist-en.json for the built-in plugins for search and help, and more.) But how will those gain advocates without sample data to give a richer exposure to the features? We need the innovation of Isotammi project more than they need us. |
@Nick-Hall Yes revert, add it to the next major release, and I suggest adding each of the other known projects also instead of showing a single preference! |
|
Think of the timeline... If this is pushed to the next major release, then there will not be more than the wishy-washy feedback that has been filed since 5.2.0, a year ago. And since there's no agreement about the feature other than adding an example project, there will only be superficial changes. And the Projects becoming truly useful will be pushed to 6.1... probably in 2026. Although more likely further than that because this is a UX enhancement. UX enhancements are always pushed to end of the development cycle when the functional base is solid and the GUI needs are defined. And NotYetImplemented UX features are the first to be cut when people are clamoring for access to the new functionalities. |
|
@Nick-Hall Revert it, makes no sense tacking it on to the last 5.2.x release! |
|
Reverted in commit 2a92670. |
No description provided.