>> I think it would be fine, but it will require those that want
>> to manually install a package to literally copy it into the right
> Sorry, I don't understand.
> The Help->Plugin Manager is not about manually installing plugins, it is
> about automatically installing plugins from the wiki page (which I think
> unnecessarily provides a different view on what addons exist).
> If you wanted to manually install a plugin, you had to put it manually in
> the right place, and that doesn't change.
I meant that in the Plugin Manager, all you need is a URL to install a
plugin. So, anyone could make a zip or tgz, put it on the web, and
someone else could install it through the Plugin Manager by entering
Likewise, anyone could add an entry to the wiki page, with that URL,
and it could be installed.
In the new system, there is a bit of an overhead to getting the addon
listed, but that hasn't been too much of a hurdle.
>> Eventually, we should replicate all of the Plugin
>> Manager/wikipage functionality in the new Preference-based system. It
>> would be great if each addon had a wiki page, thumbnail,
> Yes, I suggest keeping the wiki page as it is for now, just removing the
> link to the zip file.
Yes, that would be necessary. None of the addons listed there will
work with Gramps 3.4 (wrong version) and some of the items listed
there are shell scripts and other tools.
>> and could be
>> hidden/installed/removed from there.
> The trouble with using the wiki page for installing addons (I presume you
> mean using the page as information read by the application, rather than
> clicking somewhere on the page to have an addon installed) is that there
> would then be two sources of the truth about which addons existed - never a
> good idea.
> I think that separation of installation (via the svn repository) and
> documentation (via the wiki) is what is needed. After all, that corresponds
> with the situation for the Gramps application itself.
Yes, but the addons repository can be used to dynamically provide a
list of available addons, rather than having to list it on the wiki. I
imagine a page that looks similar to the current wiki page, but
generated by a system that reads the addon listing:
> That is why I suggest removing the last column (containing a link to the svn
> file) from the wiki page.
Some of those are shell tools, so they need to be listed there (or
somewhere), with their urls.
>> Also, the listing on the wiki was
>> a nice feature. I bet we can do that programmatically now, even in
>> different languages
> As I say, the documentation on the wiki page should be maintained
> independently from the code.
Yes, but there is a third thing: the listing (see above URL), which
has been translated into many languages. The listing is maintained
with the code.
So, to cut down on confusion, I agree that it would be good to remove
the download options from the Plugin Manager (unless Benny et al can
think of a reason to keep them) and remove the duplicate entries from
On top of that, it would be quite nice to have a server-side script
that would read the above listing (or ) and generate a page similar
to the old wiki page for those that want to browse through the
options, with instructions on how to get these through Preferences.
 - https://gramps-addons.svn.sourceforge.net/svnroot/gramps-addons/trunk/listings/
>>> Index: src/gui/plug/_windows.py
>>> --- src/gui/plug/_windows.py (revision 18947)
>>> +++ src/gui/plug/_windows.py (working copy)
>>> @@ -264,8 +264,8 @@
>>> self.__refresh_btn.connect('clicked', self.__refresh_addon_list)
>>> install_page.pack_start(hbutbox, expand=False, padding=5)
>>> - notebook.append_page(install_page,
>>> - tab_label=gtk.Label(_('Install Addons')))
>>> + # notebook.append_page(install_page,
>>> + # tab_label=gtk.Label(_('Install Addons')))
>>> #add the notebook to the window
>>> Index: src/config.py
>>> --- src/config.py (revision 18947)
>>> +++ src/config.py (working copy)
>>> @@ -128,8 +128,8 @@
>>> register('behavior.autoload', False)
>>> register('behavior.avg-generation-gap', 20)
>>> register('behavior.betawarn', False)
>>> -register('behavior.check-for-updates', 2)
>>> -register('behavior.check-for-update-types', ["update", "new"])
>>> +register('behavior.check-for-updates', 0)
>>> +register('behavior.check-for-update-types', ["new"])
>>> register('behavior.last-check-for-updates', "1970/01/01")
>>> register('behavior.previously-seen-updates', )
>>> register('behavior.do-not-show-previously-seen-updates', True)