Superseding built-in plug-in registration

Ideas
1

Perhaps the plugin registration process could be enhanced so that built-in plug-ins could be superseded by add-ons in the Gramps User Directory?

If this is done during initialization, maybe it won’t add to the operational overhead?

A number of the built-ins have been languishing since the “enhancement” release cycle is so protracted.

So the options seem to be:

  1. move most of the built-ins out into add-ons
  2. add the ability to supersede a built-in
  3. add confusing clutter with cloned built-ins recast as add-ons
2

I don’t like that. These plugins are supported by the gramps core team.
Add-ons are supported only by their writers.

3

Stripping out built-ins also has the unhappy side-effect of making Gramps seem less complete when “installed out of the box”.

Many users have an irrational fear of installing add-ons. I’ve even had one respond: “if it was really needed, it would’ve been included.” At the time, this attitude left me speechless.

I do believe a few need to be stripped anyway… As an example: an elementary labeled-by-default Navigator mode would greatly simplify the interface documentation. (My old eyes would really appreciate a mode with larger sized icons. I wonder if that would be any help get more users through for the eval period?)

Converting the current 3 modes to advanced-user add-ons would also give those Navigator modes a chance to evolve.

4

And that is the major consideration to determine if a function should be a part of the built-in code. For the novice user, the built-in functions should be everything the user needs to have a successful Gramps experience.

If anything, with each major release a determination should be made to see if an addon should be added to the core code acknowledging that that functionality should be made available out of the box. The major tension is that addons can be updated between version releases. In particular, addon filters are prime candidates to be added to the core code.

5

Is it? We could challenge the conceptual differences of “core” versus “built-in” versus “included”. Maybe that “absolute need” just determines if the feature should be bundled as part of the installer.

Perhaps if the installers put some of the plugins in the User Directory instead of a plugins folder in the protected area of the drive, then the functionality remains equally available for newbies.

But, pre-populating a few add-ons might also desensitize users to using add-ons. Essentially give the extensibility a more official stamp of approval.

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.