Re: [Gramps-devel] Using VCG to generate family trees.

[Alex R. <sh...@al...>]

John,

On 11/09/2004 08:57:04 AM, John Stoffel wrote:
> Alex> Actually, the whole setup of two plugins registering under the
> Alex> same name keeps giving us trouble.
>=20
> Ding ding ding!  This is a bad situation, and we should really clean
> it up.=20
>=20
> Alex> Maybe we should remove on of them (if they're doing exactly the
> Alex> same) or change the name to e.g. Alternative Relationship graph
> Alex> (if they produce different results). At present, any maintanence
> Alex> is twofold, with no apparent benefit :-)
>=20
> The problem as I see it is also twofold:
>=20
> 1. Different named modules which register the same name when called.
>    Which one gets used?  The last one loaded?  It would be nice to
>    have some notice that says:
>=20
> 	Loaded: /path/to/plugin/foo2.py - replaced "FOOBAR Graphical
> 	  Report" loaded from /usr/share/gramps/plugins/barbar.py"
>=20
>    So we can keep track of which plugins are called and how they
>    override each other. =20
>=20
>=20
> 2. What should be the minimum requirement for plugins in terms of
>    Python?  Do we need to require that all plugins (distributed with
>    gramps of course) only use python 2.2 or higher features?  I think
>    I know that the Set() stuff is python 2.3 or higher, so maybe we
>    shouldn't support it with the 1.0.x branch, but only the 1.1 branch,
>    which I think requires 2.3 or newer.=20

Maybe it's a way to go. Honestly, I would like to mandate that plugins
use unique names. This would relieve a lot of problems at once.

> >> 5. When a module is loaded, but the register_report() doesn't run,
> >> please give an error messages that marks that module as NON-loaded,
> >> or at least show a warning.  It's not a sucessful import when that
> >> happens, see comment 3 above.
>=20
> Alex> For all other reports, register_report() is the last call in the
> Alex> module.  Loading the module guarantees the availability of the
> Alex> report. Again, what you're seeing is a singularity that escaped
> Alex> our attention. Fixing the problem of having to different
> Alex> implementations using same name should make all related problems
> Alex> disappear.
>=20
> No, you're missing the point here.

I don't think so :-)

> If the register_report() call isn't run (for whatever reason), then the
> plugin hasn't loaded properly and a warning/error should be thrown.=20

This is correct, and for every plugin _except_ graphviz this is
exactly how it goes. The graphviz has the conditional registration,
which should be handled differently.

I still think that getting rid of the vicious scheme where two plugins
use the same name will remove many problems, including this one.
If we maintain both, we should give them different names and
remove version-dependent registration. If we remove one of them,
we also get rid of the version-dependent registration.

> I was going crazy
> trying to figure out why my modules was shown to have loaded, but
> wasn't in the menus.  All because the *required* initialization
> routine hadn't run.  Which is an error.  It's defined in the docs that
> the register_report() function must be there, if it's not, then the
> plugin is broken.

This is correct, but barring the conditional input, register_report()
is the prerequisite for loading the module.

Alex

--=20
Alexander Roitman   http://ebner.neuroscience.umn.edu/people/alex.html
Dept. of Neuroscience, Lions Research Building
2001 6th Street SE, Minneapolis, MN  55455
Tel (612) 625-7566   FAX (612) 626-9201