Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Isotammi addons to Project Manager defaults #1827

Open
wants to merge 1 commit into
base: maintenance/gramps52
Choose a base branch
from

Conversation

kkujansuu
Copy link

No description provided.

@emyoulation
Copy link
Contributor

emyoulation commented Dec 17, 2024

@Nick-Hall
When I tried to add to the default Projects earlier, this added the Isotammi project during a clean install. But the Restore project defaults button in the Addon Manager still only included the main gramps-project collection.

How do we make that reset button use the same defaults as the config.py defaults?

@Call-Me-Dave
Copy link

Call-Me-Dave commented Dec 17, 2024

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

@emyoulation
Copy link
Contributor

Question should the Gramps project really have external addon urls that can not be verified and would only really be for advanced users!

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

@wroldwiedbwe
Copy link

@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.

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.

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!

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 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?

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

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.

@emyoulation
Copy link
Contributor

emyoulation commented Dec 17, 2024

didn't they announce they disbanded the project

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.

@giotodibondone
Copy link

Another option is to be able to load a file that has those optional repositories listed?

@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?

@emyoulation
Copy link
Contributor

emyoulation commented Dec 17, 2024

Why not just package the files normal gramps addon library file that can be installed via the addon manager

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.

@PQYPLZXHGF
Copy link
Contributor

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.)

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!

Why not just package the files normal gramps addon library file that can be installed via the addon manager and

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 ?

@emyoulation
Copy link
Contributor

emyoulation commented Dec 17, 2024

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.)

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!

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.

@wroldwiedbwe
Copy link

wroldwiedbwe commented Dec 17, 2024

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 ?

@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 )?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants