Third-party plugins

[Doug Blank-2]

Developers,

A few ideas I'd like to bounce off of you:

1) There are developers that work in gramps SVN, but that also have
third-party contributions. I think many of those contributions live
outside of our SVN, but there isn't really a reason why they must
(right?). What if we had a src/plugins/contrib subdirectory in SVN
where that code could be worked on in subdirs. It could also be
packaged there (zipped file of .gpr.py and all necessary files). Then
the plugin page could just point to the SVN repository.

2) How do plugins in other projects handle translations? Is there an
easy manner for shipping additional translation files with a plugin,
and installing them? If not, I was thinking of an API for us to allow
plugins to augment our current setup.

3) What about creating a new extension for our plugins (perhaps
.gplug) and a mime-type, so that we could load them, and humans would
recognize what they are?

-Doug

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Benny Malengier]

2009/10/27 Doug Blank <doug.blank@...>:

> Developers,
>
> A few ideas I'd like to bounce off of you:
>
> 1) There are developers that work in gramps SVN, but that also have
> third-party contributions. I think many of those contributions live
> outside of our SVN, but there isn't really a reason why they must
> (right?). What if we had a src/plugins/contrib subdirectory in SVN
> where that code could be worked on in subdirs. It could also be
> packaged there (zipped file of .gpr.py and all necessary files). Then
> the plugin page could just point to the SVN repository.

I think a separate repository should be made, so that users who have
access to that one, do not need access to the GRAMPS repo.

>
> 2) How do plugins in other projects handle translations? Is there an
> easy manner for shipping additional translation files with a plugin,
> and installing them? If not, I was thinking of an API for us to allow
> plugins to augment our current setup.

This is a problem. The nicest would be to have translation inside of
the gramps.pot, but not possible with another repository. So the
solution would be to use for plugins a translation domain
grampsplugins, and have contributed plugins use _() function binded to
the domain grampsplugins.
For translators this should not be an issue, on translating
grampsplugins.pot, they can first use gramps.pot to translate
everything that is already present in the gramps module, then
translate only the missing strings. Tools like kbabel can work with
dictionaries making it even more simple.

> 3) What about creating a new extension for our plugins (perhaps
> .gplug) and a mime-type, so that we could load them, and humans would
> recognize what they are?

You mean for the tar file with plugin in it? Yes, that is an option.
See http://live.gnome.org/Gedit/PythonPluginHowTo , so perhaps
gramps-plugin as extension.

Benny

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Doug Blank-2]

On Tue, Oct 27, 2009 at 7:40 AM, Benny Malengier
<benny.malengier@...> wrote:

> 2009/10/27 Doug Blank <doug.blank@...>:
>> Developers,
>>
>> A few ideas I'd like to bounce off of you:
>>
>> 1) There are developers that work in gramps SVN, but that also have
>> third-party contributions. I think many of those contributions live
>> outside of our SVN, but there isn't really a reason why they must
>> (right?). What if we had a src/plugins/contrib subdirectory in SVN
>> where that code could be worked on in subdirs. It could also be
>> packaged there (zipped file of .gpr.py and all necessary files). Then
>> the plugin page could just point to the SVN repository.
>
> I think a separate repository should be made, so that users who have
> access to that one, do not need access to the GRAMPS repo.

Yes, that is a better idea. Limit the access to just those plugins.

>> 2) How do plugins in other projects handle translations? Is there an
>> easy manner for shipping additional translation files with a plugin,
>> and installing them? If not, I was thinking of an API for us to allow
>> plugins to augment our current setup.
>
> This is a problem. The nicest would be to have translation inside of
> the gramps.pot, but not possible with another repository. So the
> solution would be to use for plugins a translation domain
> grampsplugins, and have contributed plugins use _() function binded to
> the domain grampsplugins.
> For translators this should not be an issue, on translating
> grampsplugins.pot, they can first use gramps.pot to translate
> everything that is already present in the gramps module, then
> translate only the missing strings. Tools like kbabel can work with
> dictionaries making it even more simple.

But this would only work for those plugins that are in this new
proposed plugin repository, right? We could do that, but what about
others? Or would we require plugins to come from our contrib
repository?

I was thinking of a way of having dynamic translations in the plugin,
if something wasn't in the po file.

>> 3) What about creating a new extension for our plugins (perhaps
>> .gplug) and a mime-type, so that we could load them, and humans would
>> recognize what they are?
>
> You mean for the tar file with plugin in it? Yes, that is an option.
> See http://live.gnome.org/Gedit/PythonPluginHowTo , so perhaps
> gramps-plugin as extension.

That file (.gedit-plugin) looks like just the definition file (our
.gpr.py file).

Perhaps "plugin" is not a good outward facing name for Uncle Bob (Aunt
Martha's new boyfriend). Looks like Firefox calls all additional items
"add-ons", and "plugin" is a type of "add-on" (among "extension",
"themes", and "languages").

So, maybe .gramps-addon?

-Doug

> Benny
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Benny Malengier]

2009/10/27 Doug Blank <doug.blank@...>:

> On Tue, Oct 27, 2009 at 7:40 AM, Benny Malengier
> <benny.malengier@...> wrote:
>> 2009/10/27 Doug Blank <doug.blank@...>:
>>> Developers,
>>>
>>> A few ideas I'd like to bounce off of you:
>>>
>>> 1) There are developers that work in gramps SVN, but that also have
>>> third-party contributions. I think many of those contributions live
>>> outside of our SVN, but there isn't really a reason why they must
>>> (right?). What if we had a src/plugins/contrib subdirectory in SVN
>>> where that code could be worked on in subdirs. It could also be
>>> packaged there (zipped file of .gpr.py and all necessary files). Then
>>> the plugin page could just point to the SVN repository.
>>
>> I think a separate repository should be made, so that users who have
>> access to that one, do not need access to the GRAMPS repo.
>
> Yes, that is a better idea. Limit the access to just those plugins.
>
>>> 2) How do plugins in other projects handle translations? Is there an
>>> easy manner for shipping additional translation files with a plugin,
>>> and installing them? If not, I was thinking of an API for us to allow
>>> plugins to augment our current setup.
>>
>> This is a problem. The nicest would be to have translation inside of
>> the gramps.pot, but not possible with another repository. So the
>> solution would be to use for plugins a translation domain
>> grampsplugins, and have contributed plugins use _() function binded to
>> the domain grampsplugins.
>> For translators this should not be an issue, on translating
>> grampsplugins.pot, they can first use gramps.pot to translate
>> everything that is already present in the gramps module, then
>> translate only the missing strings. Tools like kbabel can work with
>> dictionaries making it even more simple.
>
> But this would only work for those plugins that are in this new
> proposed plugin repository, right? We could do that, but what about
> others? Or would we require plugins to come from our contrib
> repository?

Translation is difficult, no matter how we do it. The plugin author
himself cannot do it because he does not know the other languages.
Using a repo that plugin authors can request access too, makes it easy
for non coders to translate third party plugins.
The plugin must follow the concept of module translation:
http://docs.python.org/library/gettext.html#localizing-your-module so
no changes to the global gettext instance may be done (as that would
change the language of gramps and grampsplugin does not contain those
strings)
Plugins outside of that system can only be translated if they set up
their own translation via gettext class, and distribute the necessary
.mo files.

On a release of gramps we could also release a grampsplugins.mo taken
from the third party plugins.

Note that I see the class based api has an add_fallback function to
add a fallback translation domain, so we might be able to globally
define to use gramps.mo, and if not found grampsplugins.mo.

> I was thinking of a way of having dynamic translations in the plugin,
> if something wasn't in the po file.

Not a good idea. We need to use the gettext system, it simplifies
things a lot not to have to care.

>
>>> 3) What about creating a new extension for our plugins (perhaps
>>> .gplug) and a mime-type, so that we could load them, and humans would
>>> recognize what they are?
>>
>> You mean for the tar file with plugin in it? Yes, that is an option.
>> See http://live.gnome.org/Gedit/PythonPluginHowTo , so perhaps
>> gramps-plugin as extension.
>
> That file (.gedit-plugin) looks like just the definition file (our
> .gpr.py file).
>
> Perhaps "plugin" is not a good outward facing name for Uncle Bob (Aunt
> Martha's new boyfriend). Looks like Firefox calls all additional items
> "add-ons", and "plugin" is a type of "add-on" (among "extension",
> "themes", and "languages").
>
> So, maybe .gramps-addon?

I have no preference myself.

Benny
>
> -Doug
>
>> Benny
>>
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Doug Blank-2]

On Tue, Oct 27, 2009 at 8:26 AM, Benny Malengier
<benny.malengier@...> wrote:

> 2009/10/27 Doug Blank <doug.blank@...>:
>> On Tue, Oct 27, 2009 at 7:40 AM, Benny Malengier
>> <benny.malengier@...> wrote:
>>> 2009/10/27 Doug Blank <doug.blank@...>:
>>>> Developers,
>>>>
>>>> A few ideas I'd like to bounce off of you:
>>>>
>>>> 1) There are developers that work in gramps SVN, but that also have
>>>> third-party contributions. I think many of those contributions live
>>>> outside of our SVN, but there isn't really a reason why they must
>>>> (right?). What if we had a src/plugins/contrib subdirectory in SVN
>>>> where that code could be worked on in subdirs. It could also be
>>>> packaged there (zipped file of .gpr.py and all necessary files). Then
>>>> the plugin page could just point to the SVN repository.
>>>
>>> I think a separate repository should be made, so that users who have
>>> access to that one, do not need access to the GRAMPS repo.
>>
>> Yes, that is a better idea. Limit the access to just those plugins.
>>
>>>> 2) How do plugins in other projects handle translations? Is there an
>>>> easy manner for shipping additional translation files with a plugin,
>>>> and installing them? If not, I was thinking of an API for us to allow
>>>> plugins to augment our current setup.
>>>
>>> This is a problem. The nicest would be to have translation inside of
>>> the gramps.pot, but not possible with another repository. So the
>>> solution would be to use for plugins a translation domain
>>> grampsplugins, and have contributed plugins use _() function binded to
>>> the domain grampsplugins.
>>> For translators this should not be an issue, on translating
>>> grampsplugins.pot, they can first use gramps.pot to translate
>>> everything that is already present in the gramps module, then
>>> translate only the missing strings. Tools like kbabel can work with
>>> dictionaries making it even more simple.
>>
>> But this would only work for those plugins that are in this new
>> proposed plugin repository, right? We could do that, but what about
>> others? Or would we require plugins to come from our contrib
>> repository?
>
> Translation is difficult, no matter how we do it. The plugin author
> himself cannot do it because he does not know the other languages.

No, but an author can have people add their translations to the
plugin's local translation files (in gettext format, or something
else). I'm thinking of a distributed gettext-based system.

> Using a repo that plugin authors can request access too, makes it easy
> for non coders to translate third party plugins.
> The plugin must follow the concept of module translation:
> http://docs.python.org/library/gettext.html#localizing-your-module so
> no changes to the global gettext instance may be done (as that would
> change the language of gramps and grampsplugin does not contain those
> strings)
> Plugins outside of that system can only be translated if they set up
> their own translation via gettext class, and distribute the necessary
> .mo files.
>
> On a release of gramps we could also release a grampsplugins.mo taken
> from the third party plugins.
>
> Note that I see the class based api has an add_fallback function to
> add a fallback translation domain, so we might be able to globally
> define to use gramps.mo, and if not found grampsplugins.mo.

What class api are you referring? If there was a way for each addon
plugin to add their own local fallback translations, that would work.
If you know of a tutorial or docs on such things for gettext that
would be useful for me.

>> I was thinking of a way of having dynamic translations in the plugin,
>> if something wasn't in the po file.
>
> Not a good idea. We need to use the gettext system, it simplifies
> things a lot not to have to care.

Right, I'm only thinking of building on gettext. But perhaps gettext
has something like this already.

-Doug

>>>> 3) What about creating a new extension for our plugins (perhaps
>>>> .gplug) and a mime-type, so that we could load them, and humans would
>>>> recognize what they are?
>>>
>>> You mean for the tar file with plugin in it? Yes, that is an option.
>>> See http://live.gnome.org/Gedit/PythonPluginHowTo , so perhaps
>>> gramps-plugin as extension.
>>
>> That file (.gedit-plugin) looks like just the definition file (our
>> .gpr.py file).
>>
>> Perhaps "plugin" is not a good outward facing name for Uncle Bob (Aunt
>> Martha's new boyfriend). Looks like Firefox calls all additional items
>> "add-ons", and "plugin" is a type of "add-on" (among "extension",
>> "themes", and "languages").
>>
>> So, maybe .gramps-addon?
>
> I have no preference myself.
>
> Benny
>>
>> -Doug
>>
>>> Benny
>>>
>>
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Brian Matherly]

Doug,

> > Note that I see the class based api has an
> add_fallback function to
> > add a fallback translation domain, so we might be able
> to globally
> > define to use gramps.mo, and if not found
> grampsplugins.mo.
>
> What class api are you referring? If there was a way for
> each addon
> plugin to add their own local fallback translations, that
> would work.
> If you know of a tutorial or docs on such things for
> gettext that
> would be useful for me.

There is already a defined way to do this.

The class based API is defined here:
http://docs.python.org/library/gettext.html#class-based-api

The correct way to localize a python module is define here:
http://docs.python.org/library/gettext.html#localizing-your-module

Each 3rd party plugin should create it's own text domain such as "gramps-family-explorer". Then, translations can be added to that text domain by "4th party" translators.

The plugin has to use the translations class because it would be using a different text domain than the main gramps application and the installed "_()" function would not be working from the correct domain. The translations class allows falling-back to the coded message if no translated message can be found.

I plan on using the translations class to support user selectable report translations. So we will have to get comfortable with using that technique for translations anyway. See the code I added to TransUtils.py.

~Brian

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Doug Blank-2]

On Tue, Oct 27, 2009 at 10:04 AM, Brian Matherly
<brian@...> wrote:

> Doug,
>
>> > Note that I see the class based api has an
>> add_fallback function to
>> > add a fallback translation domain, so we might be able
>> to globally
>> > define to use gramps.mo, and if not found
>> grampsplugins.mo.
>>
>> What class api are you referring? If there was a way for
>> each addon
>> plugin to add their own local fallback translations, that
>> would work.
>> If you know of a tutorial or docs on such things for
>> gettext that
>> would be useful for me.
>
> There is already a defined way to do this.
>
> The class based API is defined here:
> http://docs.python.org/library/gettext.html#class-based-api
>
> The correct way to localize a python module is define here:
> http://docs.python.org/library/gettext.html#localizing-your-module
>
> Each 3rd party plugin should create it's own text domain such as "gramps-family-explorer". Then, translations can be added to that text domain by "4th party" translators.
>
> The plugin has to use the translations class because it would be using a different text domain than the main gramps application and the installed "_()" function would not be working from the correct domain. The translations class allows falling-back to the coded message if no translated message can be found.
>
> I plan on using the translations class to support user selectable report translations. So we will have to get comfortable with using that technique for translations anyway. See the code I added to TransUtils.py.

Perfect! Thanks!

-Doug

> ~Brian
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Jerome]

>> 2) How do plugins in other projects handle translations? Is there an
>> easy manner for shipping additional translation files with a plugin,
>> and installing them? If not, I was thinking of an API for us to allow
>> plugins to augment our current setup.
>
> This is a problem. The nicest would be to have translation inside of
> the gramps.pot, but not possible with another repository. So the
> solution would be to use for plugins a translation domain
> grampsplugins, and have contributed plugins use _() function binded to
> the domain grampsplugins.
> For translators this should not be an issue, on translating
> grampsplugins.pot, they can first use gramps.pot to translate
> everything that is already present in the gramps module, then
> translate only the missing strings. Tools like kbabel can work with
> dictionaries making it even more simple.

I used a dirty (but working) method for generating and merging
translation strings into gramps.pot !

#! /bin/sh
# .gramps/plugins directory
./get_strings *.py *.glade

# there is a copy of current template on .gramps/plugins/po/gramps.pot
cat messages.pot >> po/gramps.pot
msguniq po/gramps.pot -o new.pot

http://www.gramps-project.org/bugs/view.php?id=2771
http://www.gramps-project.org/wiki/index.php?title=Translating_GRAMPS#GNU_.60gettext.27_utilities
http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps20/gramps2/src/get_strings

Benny Malengier a écrit :

> 2009/10/27 Doug Blank <doug.blank@...>:
>> Developers,
>>
>> A few ideas I'd like to bounce off of you:
>>
>> 1) There are developers that work in gramps SVN, but that also have
>> third-party contributions. I think many of those contributions live
>> outside of our SVN, but there isn't really a reason why they must
>> (right?). What if we had a src/plugins/contrib subdirectory in SVN
>> where that code could be worked on in subdirs. It could also be
>> packaged there (zipped file of .gpr.py and all necessary files). Then
>> the plugin page could just point to the SVN repository.
>
> I think a separate repository should be made, so that users who have
> access to that one, do not need access to the GRAMPS repo.
>
>> 2) How do plugins in other projects handle translations? Is there an
>> easy manner for shipping additional translation files with a plugin,
>> and installing them? If not, I was thinking of an API for us to allow
>> plugins to augment our current setup.
>
> This is a problem. The nicest would be to have translation inside of
> the gramps.pot, but not possible with another repository. So the
> solution would be to use for plugins a translation domain
> grampsplugins, and have contributed plugins use _() function binded to
> the domain grampsplugins.
> For translators this should not be an issue, on translating
> grampsplugins.pot, they can first use gramps.pot to translate
> everything that is already present in the gramps module, then
> translate only the missing strings. Tools like kbabel can work with
> dictionaries making it even more simple.
>
>> 3) What about creating a new extension for our plugins (perhaps
>> .gplug) and a mime-type, so that we could load them, and humans would
>> recognize what they are?
>
> You mean for the tar file with plugin in it? Yes, that is an option.
> See http://live.gnome.org/Gedit/PythonPluginHowTo , so perhaps
> gramps-plugin as extension.
>
> Benny
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Duncan Lithgow-5]

Whatever you guys decide to do I just want to note some points...

1. I prefer the term extensions
2. It would be great if we could have a more powerful (read not on the
wiki) interface to the 'plugins'. With user comment threads, screen
shots and descriptions. Just like our friend firefox. Of course this
is a web dev issue and not a gramps one.
3. Could we please more the 'plugins' out of the main menu structure,
or by some other way make them obviously unofficial? It would help us
all know which functions we should expect to work and which ones may
be buggy

Duncan

--
Linux user #372812 | http://lithgow-schmidt.dk

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Doug Blank-2]

On Tue, Oct 27, 2009 at 3:40 PM, Duncan Lithgow
<duncan.lithgow@...> wrote:
> Whatever you guys decide to do I just want to note some points...
>
> 1. I prefer the term extensions

Thanks... appreciate the feedback.

> 2. It would be great if we could have a more powerful (read not on the
> wiki) interface to the 'plugins'. With user comment threads, screen
> shots and descriptions. Just like our friend firefox. Of course this
> is a web dev issue and not a gramps one.

Agreed that we need to make that better. Perhaps we can still use the
wiki to describe them, and provide in-depth help and docs. I suspect
though that we will have a gramps-gtk window for browsing and
download. There is the beginning of such a beast with the Plugin
Manager Gramplet.

> 3. Could we please more the 'plugins' out of the main menu structure,
> or by some other way make them obviously unofficial? It would help us
> all know which functions we should expect to work and which ones may
> be buggy

I will move the non-official extensions/plugins out of SVN (there are
a few) but all of the rest are official. But for all of the ones that
are there you should report any bugs. We should expect all to work and
users to give feedback. Perhaps the Plugin manager window should allow
users to rate them, ala many other plugin systems?

-Doug

> Duncan
>
> --
> Linux user #372812 | http://lithgow-schmidt.dk
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Doug Blank-2]

Developers,

Just wanted to describe the current status of third-party plugins, now
called "addons" (shorter than the word "extensions", and different
from "plugins" because of their 3rd-party nature.)

As Benny suggested, I've created a new sourceforge SVN called
gramps-addons. The idea is for this to be open to most anyone that
wants to share their external plugin.

I also have a distributed solution for addon-based translations,
thanks to Brian's suggestion and his work in trunk. It works something
like this:

1. make a catalog of all of the translatable phrases in your addon
2. look to see if that phrase has been translated in gramps.pot (core
translations), or in any other addon
3. allow you to edit your translations in a local version, called, for
example, MyAddon/po/fr-local.po
4. to build your addon, you create your own locale collection of translations
5. when you run your addon code, you'll be using your translations as a fallback

This was a little tricky in registering the addon via Benny's new
gpr.py interface as that has strings that presumably need to be
translated by the addon! I didn't want to add a dependency to the
plugins to TransUtils, so you currently need to add this at the top of
your gpr file:

from TransUtils import get_addon_translator
_ = get_addon_translator(__file__).gettext

This redefines "_" to be a version that will fallback to the locale in
the addon's subdirectory. (Benny, if you don't mind a dependency on
TransUtils, we can predefine (or redefine) this in the registration
code so the gpr can be as free from code as possible.)

I've created a make.py python script to help automate all of this
functionality, and began documentation here:

http://www.gramps-project.org/wiki/index.php?title=Addons_Development

If this looks ok, I'll start moving over the 3rd-party (unstable)
plugins from trunk, translators can help translate, and we can list
the addons on the wiki for manual installation testing. Next steps
are: create a thumbnail image for each addon, and a GRAMPS GUI dialog
to allow users to manage their addons (perhaps just a tab in plugins).

Feedback welcomed,

-Doug

On Tue, Oct 27, 2009 at 6:40 AM, Benny Malengier
<benny.malengier@...> wrote:

> 2009/10/27 Doug Blank <doug.blank@...>:
>> Developers,
>>
>> A few ideas I'd like to bounce off of you:
>>
>> 1) There are developers that work in gramps SVN, but that also have
>> third-party contributions. I think many of those contributions live
>> outside of our SVN, but there isn't really a reason why they must
>> (right?). What if we had a src/plugins/contrib subdirectory in SVN
>> where that code could be worked on in subdirs. It could also be
>> packaged there (zipped file of .gpr.py and all necessary files). Then
>> the plugin page could just point to the SVN repository.
>
> I think a separate repository should be made, so that users who have
> access to that one, do not need access to the GRAMPS repo.
>
>>
>> 2) How do plugins in other projects handle translations? Is there an
>> easy manner for shipping additional translation files with a plugin,
>> and installing them? If not, I was thinking of an API for us to allow
>> plugins to augment our current setup.
>
> This is a problem. The nicest would be to have translation inside of
> the gramps.pot, but not possible with another repository. So the
> solution would be to use for plugins a translation domain
> grampsplugins, and have contributed plugins use _() function binded to
> the domain grampsplugins.
> For translators this should not be an issue, on translating
> grampsplugins.pot, they can first use gramps.pot to translate
> everything that is already present in the gramps module, then
> translate only the missing strings. Tools like kbabel can work with
> dictionaries making it even more simple.
>
>> 3) What about creating a new extension for our plugins (perhaps
>> .gplug) and a mime-type, so that we could load them, and humans would
>> recognize what they are?
>
> You mean for the tar file with plugin in it? Yes, that is an option.
> See http://live.gnome.org/Gedit/PythonPluginHowTo , so perhaps
> gramps-plugin as extension.
>
> Benny
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Benny Malengier]

Looks good to me on reading.
I'll move my placecompletion plugin ... addon, once you say it is stable.
Go ahead and define _ as you say in the exec command of the
PluginRegister for third party plugins.

Benny

2009/11/2 Doug Blank <doug.blank@...>:

> Developers,
>
> Just wanted to describe the current status of third-party plugins, now
> called "addons" (shorter than the word "extensions", and different
> from "plugins" because of their 3rd-party nature.)
>
> As Benny suggested, I've created a new sourceforge SVN called
> gramps-addons. The idea is for this to be open to most anyone that
> wants to share their external plugin.
>
> I also have a distributed solution for addon-based translations,
> thanks to Brian's suggestion and his work in trunk. It works something
> like this:
>
> 1. make a catalog of all of the translatable phrases in your addon
> 2. look to see if that phrase has been translated in gramps.pot (core
> translations), or in any other addon
> 3. allow you to edit your translations in a local version, called, for
> example, MyAddon/po/fr-local.po
> 4. to build your addon, you create your own locale collection of translations
> 5. when you run your addon code, you'll be using your translations as a fallback
>
> This was a little tricky in registering the addon via Benny's new
> gpr.py interface as that has strings that presumably need to be
> translated by the addon! I didn't want to add a dependency to the
> plugins to TransUtils, so you currently need to add this at the top of
> your gpr file:
>
> from TransUtils import get_addon_translator
> _ = get_addon_translator(__file__).gettext
>
> This redefines "_" to be a version that will fallback to the locale in
> the addon's subdirectory. (Benny, if you don't mind a dependency on
> TransUtils, we can predefine (or redefine) this in the registration
> code so the gpr can be as free from code as possible.)
>
> I've created a make.py python script to help automate all of this
> functionality, and began documentation here:
>
> http://www.gramps-project.org/wiki/index.php?title=Addons_Development
>
> If this looks ok, I'll start moving over the 3rd-party (unstable)
> plugins from trunk, translators can help translate, and we can list
> the addons on the wiki for manual installation testing. Next steps
> are: create a thumbnail image for each addon, and a GRAMPS GUI dialog
> to allow users to manage their addons (perhaps just a tab in plugins).
>
> Feedback welcomed,
>
> -Doug
>
> On Tue, Oct 27, 2009 at 6:40 AM, Benny Malengier
> <benny.malengier@...> wrote:
>> 2009/10/27 Doug Blank <doug.blank@...>:
>>> Developers,
>>>
>>> A few ideas I'd like to bounce off of you:
>>>
>>> 1) There are developers that work in gramps SVN, but that also have
>>> third-party contributions. I think many of those contributions live
>>> outside of our SVN, but there isn't really a reason why they must
>>> (right?). What if we had a src/plugins/contrib subdirectory in SVN
>>> where that code could be worked on in subdirs. It could also be
>>> packaged there (zipped file of .gpr.py and all necessary files). Then
>>> the plugin page could just point to the SVN repository.
>>
>> I think a separate repository should be made, so that users who have
>> access to that one, do not need access to the GRAMPS repo.
>>
>>>
>>> 2) How do plugins in other projects handle translations? Is there an
>>> easy manner for shipping additional translation files with a plugin,
>>> and installing them? If not, I was thinking of an API for us to allow
>>> plugins to augment our current setup.
>>
>> This is a problem. The nicest would be to have translation inside of
>> the gramps.pot, but not possible with another repository. So the
>> solution would be to use for plugins a translation domain
>> grampsplugins, and have contributed plugins use _() function binded to
>> the domain grampsplugins.
>> For translators this should not be an issue, on translating
>> grampsplugins.pot, they can first use gramps.pot to translate
>> everything that is already present in the gramps module, then
>> translate only the missing strings. Tools like kbabel can work with
>> dictionaries making it even more simple.
>>
>>> 3) What about creating a new extension for our plugins (perhaps
>>> .gplug) and a mime-type, so that we could load them, and humans would
>>> recognize what they are?
>>
>> You mean for the tar file with plugin in it? Yes, that is an option.
>> See http://live.gnome.org/Gedit/PythonPluginHowTo , so perhaps
>> gramps-plugin as extension.
>>
>> Benny
>>
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Jerome]

Also, should 3rd party-plugins not use an other config file ?

Currently, options are written on report_options.xml or same files as
main program. But 3rd party options may often change or could introduce
errors, isn't it ?


Jérôme


Benny Malengier a écrit :

> Looks good to me on reading.
> I'll move my placecompletion plugin ... addon, once you say it is stable.
> Go ahead and define _ as you say in the exec command of the
> PluginRegister for third party plugins.
>
> Benny
>
> 2009/11/2 Doug Blank <doug.blank@...>:
>> Developers,
>>
>> Just wanted to describe the current status of third-party plugins, now
>> called "addons" (shorter than the word "extensions", and different
>> from "plugins" because of their 3rd-party nature.)
>>
>> As Benny suggested, I've created a new sourceforge SVN called
>> gramps-addons. The idea is for this to be open to most anyone that
>> wants to share their external plugin.
>>
>> I also have a distributed solution for addon-based translations,
>> thanks to Brian's suggestion and his work in trunk. It works something
>> like this:
>>
>> 1. make a catalog of all of the translatable phrases in your addon
>> 2. look to see if that phrase has been translated in gramps.pot (core
>> translations), or in any other addon
>> 3. allow you to edit your translations in a local version, called, for
>> example, MyAddon/po/fr-local.po
>> 4. to build your addon, you create your own locale collection of translations
>> 5. when you run your addon code, you'll be using your translations as a fallback
>>
>> This was a little tricky in registering the addon via Benny's new
>> gpr.py interface as that has strings that presumably need to be
>> translated by the addon! I didn't want to add a dependency to the
>> plugins to TransUtils, so you currently need to add this at the top of
>> your gpr file:
>>
>> from TransUtils import get_addon_translator
>> _ = get_addon_translator(__file__).gettext
>>
>> This redefines "_" to be a version that will fallback to the locale in
>> the addon's subdirectory. (Benny, if you don't mind a dependency on
>> TransUtils, we can predefine (or redefine) this in the registration
>> code so the gpr can be as free from code as possible.)
>>
>> I've created a make.py python script to help automate all of this
>> functionality, and began documentation here:
>>
>> http://www.gramps-project.org/wiki/index.php?title=Addons_Development
>>
>> If this looks ok, I'll start moving over the 3rd-party (unstable)
>> plugins from trunk, translators can help translate, and we can list
>> the addons on the wiki for manual installation testing. Next steps
>> are: create a thumbnail image for each addon, and a GRAMPS GUI dialog
>> to allow users to manage their addons (perhaps just a tab in plugins).
>>
>> Feedback welcomed,
>>
>> -Doug
>>
>> On Tue, Oct 27, 2009 at 6:40 AM, Benny Malengier
>> <benny.malengier@...> wrote:
>>> 2009/10/27 Doug Blank <doug.blank@...>:
>>>> Developers,
>>>>
>>>> A few ideas I'd like to bounce off of you:
>>>>
>>>> 1) There are developers that work in gramps SVN, but that also have
>>>> third-party contributions. I think many of those contributions live
>>>> outside of our SVN, but there isn't really a reason why they must
>>>> (right?). What if we had a src/plugins/contrib subdirectory in SVN
>>>> where that code could be worked on in subdirs. It could also be
>>>> packaged there (zipped file of .gpr.py and all necessary files). Then
>>>> the plugin page could just point to the SVN repository.
>>> I think a separate repository should be made, so that users who have
>>> access to that one, do not need access to the GRAMPS repo.
>>>
>>>> 2) How do plugins in other projects handle translations? Is there an
>>>> easy manner for shipping additional translation files with a plugin,
>>>> and installing them? If not, I was thinking of an API for us to allow
>>>> plugins to augment our current setup.
>>> This is a problem. The nicest would be to have translation inside of
>>> the gramps.pot, but not possible with another repository. So the
>>> solution would be to use for plugins a translation domain
>>> grampsplugins, and have contributed plugins use _() function binded to
>>> the domain grampsplugins.
>>> For translators this should not be an issue, on translating
>>> grampsplugins.pot, they can first use gramps.pot to translate
>>> everything that is already present in the gramps module, then
>>> translate only the missing strings. Tools like kbabel can work with
>>> dictionaries making it even more simple.
>>>
>>>> 3) What about creating a new extension for our plugins (perhaps
>>>> .gplug) and a mime-type, so that we could load them, and humans would
>>>> recognize what they are?
>>> You mean for the tar file with plugin in it? Yes, that is an option.
>>> See http://live.gnome.org/Gedit/PythonPluginHowTo , so perhaps
>>> gramps-plugin as extension.
>>>
>>> Benny
>>>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Benny Malengier]

Doug,

I suppose you will update:
http://www.gramps-project.org/wiki/index.php?title=Plugins3.2 which is
part of http://www.gramps-project.org/wiki/index.php?title=3.2_Third-party_Plugins

About this, some comments:

1/I don't like the fact some 'expert' plugins are at the top. This is
not good for the normal new users going to that page to find out.
Reading raw export, sql export, ... will be chinese for this user. I
think a division in sections based on the technical understanding
needed, is better.

2/Geoview will be part of GRAMPS 3.2 as a plugin view. It might be
hidden by default, but it would be easy to activate, so no need to add
it there.

3/I know this page changed from the old way of division in type of
plugin to the present one big list, but is this big list with
everything together really the better approach?

Benny

2009/11/2 Doug Blank <doug.blank@...>:

> Developers,
>
> Just wanted to describe the current status of third-party plugins, now
> called "addons" (shorter than the word "extensions", and different
> from "plugins" because of their 3rd-party nature.)
>
> As Benny suggested, I've created a new sourceforge SVN called
> gramps-addons. The idea is for this to be open to most anyone that
> wants to share their external plugin.
>
> I also have a distributed solution for addon-based translations,
> thanks to Brian's suggestion and his work in trunk. It works something
> like this:
>
> 1. make a catalog of all of the translatable phrases in your addon
> 2. look to see if that phrase has been translated in gramps.pot (core
> translations), or in any other addon
> 3. allow you to edit your translations in a local version, called, for
> example, MyAddon/po/fr-local.po
> 4. to build your addon, you create your own locale collection of translations
> 5. when you run your addon code, you'll be using your translations as a fallback
>
> This was a little tricky in registering the addon via Benny's new
> gpr.py interface as that has strings that presumably need to be
> translated by the addon! I didn't want to add a dependency to the
> plugins to TransUtils, so you currently need to add this at the top of
> your gpr file:
>
> from TransUtils import get_addon_translator
> _ = get_addon_translator(__file__).gettext
>
> This redefines "_" to be a version that will fallback to the locale in
> the addon's subdirectory. (Benny, if you don't mind a dependency on
> TransUtils, we can predefine (or redefine) this in the registration
> code so the gpr can be as free from code as possible.)
>
> I've created a make.py python script to help automate all of this
> functionality, and began documentation here:
>
> http://www.gramps-project.org/wiki/index.php?title=Addons_Development
>
> If this looks ok, I'll start moving over the 3rd-party (unstable)
> plugins from trunk, translators can help translate, and we can list
> the addons on the wiki for manual installation testing. Next steps
> are: create a thumbnail image for each addon, and a GRAMPS GUI dialog
> to allow users to manage their addons (perhaps just a tab in plugins).
>
> Feedback welcomed,
>
> -Doug
>
> On Tue, Oct 27, 2009 at 6:40 AM, Benny Malengier
> <benny.malengier@...> wrote:
>> 2009/10/27 Doug Blank <doug.blank@...>:
>>> Developers,
>>>
>>> A few ideas I'd like to bounce off of you:
>>>
>>> 1) There are developers that work in gramps SVN, but that also have
>>> third-party contributions. I think many of those contributions live
>>> outside of our SVN, but there isn't really a reason why they must
>>> (right?). What if we had a src/plugins/contrib subdirectory in SVN
>>> where that code could be worked on in subdirs. It could also be
>>> packaged there (zipped file of .gpr.py and all necessary files). Then
>>> the plugin page could just point to the SVN repository.
>>
>> I think a separate repository should be made, so that users who have
>> access to that one, do not need access to the GRAMPS repo.
>>
>>>
>>> 2) How do plugins in other projects handle translations? Is there an
>>> easy manner for shipping additional translation files with a plugin,
>>> and installing them? If not, I was thinking of an API for us to allow
>>> plugins to augment our current setup.
>>
>> This is a problem. The nicest would be to have translation inside of
>> the gramps.pot, but not possible with another repository. So the
>> solution would be to use for plugins a translation domain
>> grampsplugins, and have contributed plugins use _() function binded to
>> the domain grampsplugins.
>> For translators this should not be an issue, on translating
>> grampsplugins.pot, they can first use gramps.pot to translate
>> everything that is already present in the gramps module, then
>> translate only the missing strings. Tools like kbabel can work with
>> dictionaries making it even more simple.
>>
>>> 3) What about creating a new extension for our plugins (perhaps
>>> .gplug) and a mime-type, so that we could load them, and humans would
>>> recognize what they are?
>>
>> You mean for the tar file with plugin in it? Yes, that is an option.
>> See http://live.gnome.org/Gedit/PythonPluginHowTo , so perhaps
>> gramps-plugin as extension.
>>
>> Benny
>>
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Doug Blank-2]

On Tue, Nov 3, 2009 at 4:32 AM, Benny Malengier
<benny.malengier@...> wrote:
> Doug,
>
> I suppose you will update:
> http://www.gramps-project.org/wiki/index.php?title=Plugins3.2 which is
> part of http://www.gramps-project.org/wiki/index.php?title=3.2_Third-party_Plugins

Yes, I've already started transitioning this to the new style. I would
like that list to be low-maintenance, so it shouldn't have things in
the list like version numbers. That data should come from the addon
itself.

> About this, some comments:
>
> 1/I don't like the fact some 'expert' plugins are at the top. This is
> not good for the normal new users going to that page to find out.
> Reading raw export, sql export, ... will be chinese for this user. I
> think a division in sections based on the technical understanding
> needed, is better.

Yes, this is an issue (except for the Chinese).

> 2/Geoview will be part of GRAMPS 3.2 as a plugin view. It might be
> hidden by default, but it would be easy to activate, so no need to add
> it there.

Yes, I agree. We can easily move these from "approved" to be standard
installs with gramps, or move currently included ones to be "addons".

> 3/I know this page changed from the old way of division in type of
> plugin to the present one big list, but is this big list with
> everything together really the better approach?

Here is what I am thinking: this list is data. It is the manner in
which anyone can add a 3rd-party plugin to gramps. Currently, the
addon code can come from anyplace on the web. (But maybe we will have
all addons come from the central gramps-addons repository. That would
give us more control --- sort of an AppStore for gramps.)

The list is currently read by a gramps plugin manager (currently a
gramplet, but perhaps just a dialog, or tab on Plugin Status). The
manner in which this list is displayed is on the wiki could also be
processed.

So, I agree that we can refine the final presentation to the user, and
hopefully use some wiki-foo to keep the data separate from the
presentation, and make it look exactly how we want: be searchable,
browse by category, etc. In the end, I hope as much of this can be
automated as possible.

-Doug

> Benny
>
> 2009/11/2 Doug Blank <doug.blank@...>:
>> Developers,
>>
>> Just wanted to describe the current status of third-party plugins, now
>> called "addons" (shorter than the word "extensions", and different
>> from "plugins" because of their 3rd-party nature.)
>>
>> As Benny suggested, I've created a new sourceforge SVN called
>> gramps-addons. The idea is for this to be open to most anyone that
>> wants to share their external plugin.
>>
>> I also have a distributed solution for addon-based translations,
>> thanks to Brian's suggestion and his work in trunk. It works something
>> like this:
>>
>> 1. make a catalog of all of the translatable phrases in your addon
>> 2. look to see if that phrase has been translated in gramps.pot (core
>> translations), or in any other addon
>> 3. allow you to edit your translations in a local version, called, for
>> example, MyAddon/po/fr-local.po
>> 4. to build your addon, you create your own locale collection of translations
>> 5. when you run your addon code, you'll be using your translations as a fallback
>>
>> This was a little tricky in registering the addon via Benny's new
>> gpr.py interface as that has strings that presumably need to be
>> translated by the addon! I didn't want to add a dependency to the
>> plugins to TransUtils, so you currently need to add this at the top of
>> your gpr file:
>>
>> from TransUtils import get_addon_translator
>> _ = get_addon_translator(__file__).gettext
>>
>> This redefines "_" to be a version that will fallback to the locale in
>> the addon's subdirectory. (Benny, if you don't mind a dependency on
>> TransUtils, we can predefine (or redefine) this in the registration
>> code so the gpr can be as free from code as possible.)
>>
>> I've created a make.py python script to help automate all of this
>> functionality, and began documentation here:
>>
>> http://www.gramps-project.org/wiki/index.php?title=Addons_Development
>>
>> If this looks ok, I'll start moving over the 3rd-party (unstable)
>> plugins from trunk, translators can help translate, and we can list
>> the addons on the wiki for manual installation testing. Next steps
>> are: create a thumbnail image for each addon, and a GRAMPS GUI dialog
>> to allow users to manage their addons (perhaps just a tab in plugins).
>>
>> Feedback welcomed,
>>
>> -Doug
>>
>> On Tue, Oct 27, 2009 at 6:40 AM, Benny Malengier
>> <benny.malengier@...> wrote:
>>> 2009/10/27 Doug Blank <doug.blank@...>:
>>>> Developers,
>>>>
>>>> A few ideas I'd like to bounce off of you:
>>>>
>>>> 1) There are developers that work in gramps SVN, but that also have
>>>> third-party contributions. I think many of those contributions live
>>>> outside of our SVN, but there isn't really a reason why they must
>>>> (right?). What if we had a src/plugins/contrib subdirectory in SVN
>>>> where that code could be worked on in subdirs. It could also be
>>>> packaged there (zipped file of .gpr.py and all necessary files). Then
>>>> the plugin page could just point to the SVN repository.
>>>
>>> I think a separate repository should be made, so that users who have
>>> access to that one, do not need access to the GRAMPS repo.
>>>
>>>>
>>>> 2) How do plugins in other projects handle translations? Is there an
>>>> easy manner for shipping additional translation files with a plugin,
>>>> and installing them? If not, I was thinking of an API for us to allow
>>>> plugins to augment our current setup.
>>>
>>> This is a problem. The nicest would be to have translation inside of
>>> the gramps.pot, but not possible with another repository. So the
>>> solution would be to use for plugins a translation domain
>>> grampsplugins, and have contributed plugins use _() function binded to
>>> the domain grampsplugins.
>>> For translators this should not be an issue, on translating
>>> grampsplugins.pot, they can first use gramps.pot to translate
>>> everything that is already present in the gramps module, then
>>> translate only the missing strings. Tools like kbabel can work with
>>> dictionaries making it even more simple.
>>>
>>>> 3) What about creating a new extension for our plugins (perhaps
>>>> .gplug) and a mime-type, so that we could load them, and humans would
>>>> recognize what they are?
>>>
>>> You mean for the tar file with plugin in it? Yes, that is an option.
>>> See http://live.gnome.org/Gedit/PythonPluginHowTo , so perhaps
>>> gramps-plugin as extension.
>>>
>>> Benny
>>>
>>
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Doug Blank-2]

On Tue, Nov 3, 2009 at 2:41 AM, Jérôme <romjerome@...> wrote:
> Also, should 3rd party-plugins not use an other config file ?
>
> Currently, options are written on report_options.xml or same files as main
> program. But 3rd party options may often change or could introduce errors,
> isn't it ?

That's a good point. Some possibilities:

1) continue having addons store their options in the common xml file
2) have a combined options file for all addons (maybe in .gramps/plugins)
3) have each addon be required to be in a subdir, and store their options there

#1 is done, but has the downsides that Jérôme mentioned (bad addon
could bring down the whole system). #2 and #3 will require some extra
code in the option handlers to get the options.

I guess I would vote for #1 until a time is shown that we really need
something more complex. Perhaps by having all addons come from a
central place, we can ensure that they are behaved well-enough to have
their options live with the others.

-Doug

>
> Jérôme
>
>
> Benny Malengier a écrit :
>>
>> Looks good to me on reading.
>> I'll move my placecompletion plugin ... addon, once you say it is stable.
>> Go ahead and define _ as you say in the exec command of the
>> PluginRegister for third party plugins.
>>
>> Benny
>>
>> 2009/11/2 Doug Blank <doug.blank@...>:
>>>
>>> Developers,
>>>
>>> Just wanted to describe the current status of third-party plugins, now
>>> called "addons" (shorter than the word "extensions", and different
>>> from "plugins" because of their 3rd-party nature.)
>>>
>>> As Benny suggested, I've created a new sourceforge SVN called
>>> gramps-addons. The idea is for this to be open to most anyone that
>>> wants to share their external plugin.
>>>
>>> I also have a distributed solution for addon-based translations,
>>> thanks to Brian's suggestion and his work in trunk. It works something
>>> like this:
>>>
>>> 1. make a catalog of all of the translatable phrases in your addon
>>> 2. look to see if that phrase has been translated in gramps.pot (core
>>> translations), or in any other addon
>>> 3. allow you to edit your translations in a local version, called, for
>>> example, MyAddon/po/fr-local.po
>>> 4. to build your addon, you create your own locale collection of
>>> translations
>>> 5. when you run your addon code, you'll be using your translations as a
>>> fallback
>>>
>>> This was a little tricky in registering the addon via Benny's new
>>> gpr.py interface as that has strings that presumably need to be
>>> translated by the addon! I didn't want to add a dependency to the
>>> plugins to TransUtils, so you currently need to add this at the top of
>>> your gpr file:
>>>
>>> from TransUtils import get_addon_translator
>>> _ = get_addon_translator(__file__).gettext
>>>
>>> This redefines "_" to be a version that will fallback to the locale in
>>> the addon's subdirectory. (Benny, if you don't mind a dependency on
>>> TransUtils, we can predefine (or redefine) this in the registration
>>> code so the gpr can be as free from code as possible.)
>>>
>>> I've created a make.py python script to help automate all of this
>>> functionality, and began documentation here:
>>>
>>> http://www.gramps-project.org/wiki/index.php?title=Addons_Development
>>>
>>> If this looks ok, I'll start moving over the 3rd-party (unstable)
>>> plugins from trunk, translators can help translate, and we can list
>>> the addons on the wiki for manual installation testing. Next steps
>>> are: create a thumbnail image for each addon, and a GRAMPS GUI dialog
>>> to allow users to manage their addons (perhaps just a tab in plugins).
>>>
>>> Feedback welcomed,
>>>
>>> -Doug
>>>
>>> On Tue, Oct 27, 2009 at 6:40 AM, Benny Malengier
>>> <benny.malengier@...> wrote:
>>>>
>>>> 2009/10/27 Doug Blank <doug.blank@...>:
>>>>>
>>>>> Developers,
>>>>>
>>>>> A few ideas I'd like to bounce off of you:
>>>>>
>>>>> 1) There are developers that work in gramps SVN, but that also have
>>>>> third-party contributions. I think many of those contributions live
>>>>> outside of our SVN, but there isn't really a reason why they must
>>>>> (right?). What if we had a src/plugins/contrib subdirectory in SVN
>>>>> where that code could be worked on in subdirs. It could also be
>>>>> packaged there (zipped file of .gpr.py and all necessary files). Then
>>>>> the plugin page could just point to the SVN repository.
>>>>
>>>> I think a separate repository should be made, so that users who have
>>>> access to that one, do not need access to the GRAMPS repo.
>>>>
>>>>> 2) How do plugins in other projects handle translations? Is there an
>>>>> easy manner for shipping additional translation files with a plugin,
>>>>> and installing them? If not, I was thinking of an API for us to allow
>>>>> plugins to augment our current setup.
>>>>
>>>> This is a problem. The nicest would be to have translation inside of
>>>> the gramps.pot, but not possible with another repository. So the
>>>> solution would be to use for plugins a translation domain
>>>> grampsplugins, and have contributed plugins use _() function binded to
>>>> the domain grampsplugins.
>>>> For translators this should not be an issue, on translating
>>>> grampsplugins.pot, they can first use gramps.pot to translate
>>>> everything that is already present in the gramps module, then
>>>> translate only the missing strings. Tools like kbabel can work with
>>>> dictionaries making it even more simple.
>>>>
>>>>> 3) What about creating a new extension for our plugins (perhaps
>>>>> .gplug) and a mime-type, so that we could load them, and humans would
>>>>> recognize what they are?
>>>>
>>>> You mean for the tar file with plugin in it? Yes, that is an option.
>>>> See http://live.gnome.org/Gedit/PythonPluginHowTo , so perhaps
>>>> gramps-plugin as extension.
>>>>
>>>> Benny
>>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Gramps-devel mailing list
>> Gramps-devel@...
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Doug Blank-2]

On Mon, Nov 2, 2009 at 11:43 AM, Benny Malengier
<benny.malengier@...> wrote:
> Looks good to me on reading.
> I'll move my placecompletion plugin ... addon, once you say it is stable.
> Go ahead and define _ as you say in the exec command of the
> PluginRegister for third party plugins.

I redefined _ for all registration code. We should keep an eye on this
to see if it has any adverse effects on registering the plugins (eg,
speed, dependencies, memory leaks, etc). Ideally, we only need to do
this if a plugin has its own locales. This does create a Translation
object for each registration. May need to delete it when done.

In any event, this should just use the current translation and should
work ok. I tested with standard install plugins and addons with their
own translations, and it appears to do the right thing.

NOTE: to use your own translations in the actual addon code, you still need to:

from TransUtils import get_addon_translator
_ = get_addon_translator(__file__).gettext

Perhaps we can do something to make that easier to use.

-Doug

> Benny
>
> 2009/11/2 Doug Blank <doug.blank@...>:
>> Developers,
>>
>> Just wanted to describe the current status of third-party plugins, now
>> called "addons" (shorter than the word "extensions", and different
>> from "plugins" because of their 3rd-party nature.)
>>
>> As Benny suggested, I've created a new sourceforge SVN called
>> gramps-addons. The idea is for this to be open to most anyone that
>> wants to share their external plugin.
>>
>> I also have a distributed solution for addon-based translations,
>> thanks to Brian's suggestion and his work in trunk. It works something
>> like this:
>>
>> 1. make a catalog of all of the translatable phrases in your addon
>> 2. look to see if that phrase has been translated in gramps.pot (core
>> translations), or in any other addon
>> 3. allow you to edit your translations in a local version, called, for
>> example, MyAddon/po/fr-local.po
>> 4. to build your addon, you create your own locale collection of translations
>> 5. when you run your addon code, you'll be using your translations as a fallback
>>
>> This was a little tricky in registering the addon via Benny's new
>> gpr.py interface as that has strings that presumably need to be
>> translated by the addon! I didn't want to add a dependency to the
>> plugins to TransUtils, so you currently need to add this at the top of
>> your gpr file:
>>
>> from TransUtils import get_addon_translator
>> _ = get_addon_translator(__file__).gettext
>>
>> This redefines "_" to be a version that will fallback to the locale in
>> the addon's subdirectory. (Benny, if you don't mind a dependency on
>> TransUtils, we can predefine (or redefine) this in the registration
>> code so the gpr can be as free from code as possible.)
>>
>> I've created a make.py python script to help automate all of this
>> functionality, and began documentation here:
>>
>> http://www.gramps-project.org/wiki/index.php?title=Addons_Development
>>
>> If this looks ok, I'll start moving over the 3rd-party (unstable)
>> plugins from trunk, translators can help translate, and we can list
>> the addons on the wiki for manual installation testing. Next steps
>> are: create a thumbnail image for each addon, and a GRAMPS GUI dialog
>> to allow users to manage their addons (perhaps just a tab in plugins).
>>
>> Feedback welcomed,
>>
>> -Doug
>>
>> On Tue, Oct 27, 2009 at 6:40 AM, Benny Malengier
>> <benny.malengier@...> wrote:
>>> 2009/10/27 Doug Blank <doug.blank@...>:
>>>> Developers,
>>>>
>>>> A few ideas I'd like to bounce off of you:
>>>>
>>>> 1) There are developers that work in gramps SVN, but that also have
>>>> third-party contributions. I think many of those contributions live
>>>> outside of our SVN, but there isn't really a reason why they must
>>>> (right?). What if we had a src/plugins/contrib subdirectory in SVN
>>>> where that code could be worked on in subdirs. It could also be
>>>> packaged there (zipped file of .gpr.py and all necessary files). Then
>>>> the plugin page could just point to the SVN repository.
>>>
>>> I think a separate repository should be made, so that users who have
>>> access to that one, do not need access to the GRAMPS repo.
>>>
>>>>
>>>> 2) How do plugins in other projects handle translations? Is there an
>>>> easy manner for shipping additional translation files with a plugin,
>>>> and installing them? If not, I was thinking of an API for us to allow
>>>> plugins to augment our current setup.
>>>
>>> This is a problem. The nicest would be to have translation inside of
>>> the gramps.pot, but not possible with another repository. So the
>>> solution would be to use for plugins a translation domain
>>> grampsplugins, and have contributed plugins use _() function binded to
>>> the domain grampsplugins.
>>> For translators this should not be an issue, on translating
>>> grampsplugins.pot, they can first use gramps.pot to translate
>>> everything that is already present in the gramps module, then
>>> translate only the missing strings. Tools like kbabel can work with
>>> dictionaries making it even more simple.
>>>
>>>> 3) What about creating a new extension for our plugins (perhaps
>>>> .gplug) and a mime-type, so that we could load them, and humans would
>>>> recognize what they are?
>>>
>>> You mean for the tar file with plugin in it? Yes, that is an option.
>>> See http://live.gnome.org/Gedit/PythonPluginHowTo , so perhaps
>>> gramps-plugin as extension.
>>>
>>> Benny
>>>
>>
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Nick Hall-6]

Doug,

I just started to try out the new plugin code with some one of my own
reports.

When I ran the make.py it failed with:

Traceback (most recent call last):
File "./make.py", line 38, in <module>
raise ValueError("Where is GRAMPS?: '%s'" % GRAMPSPATH)
ValueError: Where is GRAMPS?: '../../trunk'

I also have a couple of questions:

1. In the documentation for the addons you suggest using the convenience
function register() to register the plugin. In the standard gramps
plugins some gpr files do and some don't, is there any reason for this?

The following use the convenience function:

lib/libplugins.gpr.py
mapservices/mapservice.gpr.py
quickview/quickview.gpr.py
records.gpr.py
tool/tools.gpr.py

and these don't:

docgen/docgen.gpr.py
drawreport/drawplugins.gpr.py
export/export.gpr.py
graph/graphplugins.gpr.py
import/import.gpr.py
rel/relplugins.gpr.py
textreport/textplugins.gpr.py
webreport/webplugins.gpr.py

2. What do I need to do to make my plugin translatable? - I don't
actually need to do any translation myself. Do I just need to add the
two lines to the gpr file and make sure the strings in my plugin use the
_ function?

Regards,

Nick.


Doug Blank wrote:

> Developers,
>
> Just wanted to describe the current status of third-party plugins, now
> called "addons" (shorter than the word "extensions", and different
> from "plugins" because of their 3rd-party nature.)
>
> As Benny suggested, I've created a new sourceforge SVN called
> gramps-addons. The idea is for this to be open to most anyone that
> wants to share their external plugin.
>
> I also have a distributed solution for addon-based translations,
> thanks to Brian's suggestion and his work in trunk. It works something
> like this:
>
> 1. make a catalog of all of the translatable phrases in your addon
> 2. look to see if that phrase has been translated in gramps.pot (core
> translations), or in any other addon
> 3. allow you to edit your translations in a local version, called, for
> example, MyAddon/po/fr-local.po
> 4. to build your addon, you create your own locale collection of translations
> 5. when you run your addon code, you'll be using your translations as a fallback
>
> This was a little tricky in registering the addon via Benny's new
> gpr.py interface as that has strings that presumably need to be
> translated by the addon! I didn't want to add a dependency to the
> plugins to TransUtils, so you currently need to add this at the top of
> your gpr file:
>
> from TransUtils import get_addon_translator
> _ = get_addon_translator(__file__).gettext
>
> This redefines "_" to be a version that will fallback to the locale in
> the addon's subdirectory. (Benny, if you don't mind a dependency on
> TransUtils, we can predefine (or redefine) this in the registration
> code so the gpr can be as free from code as possible.)
>
> I've created a make.py python script to help automate all of this
> functionality, and began documentation here:
>
> http://www.gramps-project.org/wiki/index.php?title=Addons_Development
>
> If this looks ok, I'll start moving over the 3rd-party (unstable)
> plugins from trunk, translators can help translate, and we can list
> the addons on the wiki for manual installation testing. Next steps
> are: create a thumbnail image for each addon, and a GRAMPS GUI dialog
> to allow users to manage their addons (perhaps just a tab in plugins).
>
> Feedback welcomed,
>
> -Doug
>
> On Tue, Oct 27, 2009 at 6:40 AM, Benny Malengier
> <benny.malengier@...> wrote:
>  
>> 2009/10/27 Doug Blank <doug.blank@...>:
>>    
>>> Developers,
>>>
>>> A few ideas I'd like to bounce off of you:
>>>
>>> 1) There are developers that work in gramps SVN, but that also have
>>> third-party contributions. I think many of those contributions live
>>> outside of our SVN, but there isn't really a reason why they must
>>> (right?). What if we had a src/plugins/contrib subdirectory in SVN
>>> where that code could be worked on in subdirs. It could also be
>>> packaged there (zipped file of .gpr.py and all necessary files). Then
>>> the plugin page could just point to the SVN repository.
>>>      
>> I think a separate repository should be made, so that users who have
>> access to that one, do not need access to the GRAMPS repo.
>>
>>    
>>> 2) How do plugins in other projects handle translations? Is there an
>>> easy manner for shipping additional translation files with a plugin,
>>> and installing them? If not, I was thinking of an API for us to allow
>>> plugins to augment our current setup.
>>>      
>> This is a problem. The nicest would be to have translation inside of
>> the gramps.pot, but not possible with another repository. So the
>> solution would be to use for plugins a translation domain
>> grampsplugins, and have contributed plugins use _() function binded to
>> the domain grampsplugins.
>> For translators this should not be an issue, on translating
>> grampsplugins.pot, they can first use gramps.pot to translate
>> everything that is already present in the gramps module, then
>> translate only the missing strings. Tools like kbabel can work with
>> dictionaries making it even more simple.
>>
>>    
>>> 3) What about creating a new extension for our plugins (perhaps
>>> .gplug) and a mime-type, so that we could load them, and humans would
>>> recognize what they are?
>>>      
>> You mean for the tar file with plugin in it? Yes, that is an option.
>> See http://live.gnome.org/Gedit/PythonPluginHowTo , so perhaps
>> gramps-plugin as extension.
>>
>> Benny
>>
>>    
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>
>  

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Benny Malengier]

2009/11/4 Nick Hall <nick__hall@...>:

> Doug,
>
> I just started to try out the new plugin code with some one of my own
> reports.
>
> When I ran the make.py it failed with:
>
> Traceback (most recent call last):
> File "./make.py", line 38, in <module>
> raise ValueError("Where is GRAMPS?: '%s'" % GRAMPSPATH)
> ValueError: Where is GRAMPS?: '../../trunk'
>
> I also have a couple of questions:
>
> 1. In the documentation for the addons you suggest using the convenience
> function register() to register the plugin. In the standard gramps plugins
> some gpr files do and some don't, is there any reason for this?
>
> The following use the convenience function:
>
> lib/libplugins.gpr.py
> mapservices/mapservice.gpr.py
> quickview/quickview.gpr.py
> records.gpr.py
> tool/tools.gpr.py
>
> and these don't:
>
> docgen/docgen.gpr.py
> drawreport/drawplugins.gpr.py
> export/export.gpr.py
> graph/graphplugins.gpr.py
> import/import.gpr.py
> rel/relplugins.gpr.py
> textreport/textplugins.gpr.py
> webreport/webplugins.gpr.py

I finished these when Doug complained and wanted a register function.
I don't mind a register func, but it would have been to much work to
redo what was done. Moreover, personally I see no specific benefit
from one way to the other.

It is good to non-developer plugin writers however to only give one
way to do things.


> 2. What do I need to do to make my plugin translatable? - I don't actually
> need to do any translation myself. Do I just need to add the two lines to
> the gpr file and make sure the strings in my plugin use the _ function?

I think that is it, but something is not working yet.

Benny

>
> Regards,
>
> Nick.
>
>
> Doug Blank wrote:
>>
>> Developers,
>>
>> Just wanted to describe the current status of third-party plugins, now
>> called "addons" (shorter than the word "extensions", and different
>> from "plugins" because of their 3rd-party nature.)
>>
>> As Benny suggested, I've created a new sourceforge SVN called
>> gramps-addons. The idea is for this to be open to most anyone that
>> wants to share their external plugin.
>>
>> I also have a distributed solution for addon-based translations,
>> thanks to Brian's suggestion and his work in trunk. It works something
>> like this:
>>
>> 1. make a catalog of all of the translatable phrases in your addon
>> 2. look to see if that phrase has been translated in gramps.pot (core
>> translations), or in any other addon
>> 3. allow you to edit your translations in a local version, called, for
>> example, MyAddon/po/fr-local.po
>> 4. to build your addon, you create your own locale collection of
>> translations
>> 5. when you run your addon code, you'll be using your translations as a
>> fallback
>>
>> This was a little tricky in registering the addon via Benny's new
>> gpr.py interface as that has strings that presumably need to be
>> translated by the addon! I didn't want to add a dependency to the
>> plugins to TransUtils, so you currently need to add this at the top of
>> your gpr file:
>>
>> from TransUtils import get_addon_translator
>> _ = get_addon_translator(__file__).gettext
>>
>> This redefines "_" to be a version that will fallback to the locale in
>> the addon's subdirectory. (Benny, if you don't mind a dependency on
>> TransUtils, we can predefine (or redefine) this in the registration
>> code so the gpr can be as free from code as possible.)
>>
>> I've created a make.py python script to help automate all of this
>> functionality, and began documentation here:
>>
>> http://www.gramps-project.org/wiki/index.php?title=Addons_Development
>>
>> If this looks ok, I'll start moving over the 3rd-party (unstable)
>> plugins from trunk, translators can help translate, and we can list
>> the addons on the wiki for manual installation testing. Next steps
>> are: create a thumbnail image for each addon, and a GRAMPS GUI dialog
>> to allow users to manage their addons (perhaps just a tab in plugins).
>>
>> Feedback welcomed,
>>
>> -Doug
>>
>> On Tue, Oct 27, 2009 at 6:40 AM, Benny Malengier
>> <benny.malengier@...> wrote:
>>
>>>
>>> 2009/10/27 Doug Blank <doug.blank@...>:
>>>
>>>>
>>>> Developers,
>>>>
>>>> A few ideas I'd like to bounce off of you:
>>>>
>>>> 1) There are developers that work in gramps SVN, but that also have
>>>> third-party contributions. I think many of those contributions live
>>>> outside of our SVN, but there isn't really a reason why they must
>>>> (right?). What if we had a src/plugins/contrib subdirectory in SVN
>>>> where that code could be worked on in subdirs. It could also be
>>>> packaged there (zipped file of .gpr.py and all necessary files). Then
>>>> the plugin page could just point to the SVN repository.
>>>>
>>>
>>> I think a separate repository should be made, so that users who have
>>> access to that one, do not need access to the GRAMPS repo.
>>>
>>>
>>>>
>>>> 2) How do plugins in other projects handle translations? Is there an
>>>> easy manner for shipping additional translation files with a plugin,
>>>> and installing them? If not, I was thinking of an API for us to allow
>>>> plugins to augment our current setup.
>>>>
>>>
>>> This is a problem. The nicest would be to have translation inside of
>>> the gramps.pot, but not possible with another repository. So the
>>> solution would be to use for plugins a translation domain
>>> grampsplugins, and have contributed plugins use _() function binded to
>>> the domain grampsplugins.
>>> For translators this should not be an issue, on translating
>>> grampsplugins.pot, they can first use gramps.pot to translate
>>> everything that is already present in the gramps module, then
>>> translate only the missing strings. Tools like kbabel can work with
>>> dictionaries making it even more simple.
>>>
>>>
>>>>
>>>> 3) What about creating a new extension for our plugins (perhaps
>>>> .gplug) and a mime-type, so that we could load them, and humans would
>>>> recognize what they are?
>>>>
>>>
>>> You mean for the tar file with plugin in it? Yes, that is an option.
>>> See http://live.gnome.org/Gedit/PythonPluginHowTo , so perhaps
>>> gramps-plugin as extension.
>>>
>>> Benny
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Gramps-devel mailing list
>> Gramps-devel@...
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>>
>>
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Jerome]

> Traceback (most recent call last):
> File "./make.py", line 38, in <module>
> raise ValueError("Where is GRAMPS?: '%s'" % GRAMPSPATH)
> ValueError: Where is GRAMPS?: '../../trunk'

I set and other path (../../../gramps) maybe one parent directory is missing on make.py GRAMPSPATH value : line 38 ?

--- En date de : Mer 4.11.09, Nick Hall <nick__hall@...> a écrit :

> De: Nick Hall <nick__hall@...>
> Objet: Re: [Gramps-devel] Third-party plugins
> À: "Doug Blank" <doug.blank@...>
> Cc: "Gramps Development List" <gramps-devel@...>
> Date: Mercredi 4 Novembre 2009, 15h33
> Doug,
>
> I just started to try out the new plugin code with some one
> of my own
> reports.
>
> When I ran the make.py it failed with:
>
> Traceback (most recent call last):
> File "./make.py", line 38, in <module>
> raise ValueError("Where is GRAMPS?: '%s'" % GRAMPSPATH)
> ValueError: Where is GRAMPS?: '../../trunk'
>
> I also have a couple of questions:
>
> 1. In the documentation for the addons you suggest using
> the convenience
> function register() to register the plugin. In the standard
> gramps
> plugins some gpr files do and some don't, is there any
> reason for this?
>
> The following use the convenience function:
>
> lib/libplugins.gpr.py
> mapservices/mapservice.gpr.py
> quickview/quickview.gpr.py
> records.gpr.py
> tool/tools.gpr.py
>
> and these don't:
>
> docgen/docgen.gpr.py
> drawreport/drawplugins.gpr.py
> export/export.gpr.py
> graph/graphplugins.gpr.py
> import/import.gpr.py
> rel/relplugins.gpr.py
> textreport/textplugins.gpr.py
> webreport/webplugins.gpr.py
>
> 2. What do I need to do to make my plugin translatable? - I
> don't
> actually need to do any translation myself. Do I just need
> to add the
> two lines to the gpr file and make sure the strings in my
> plugin use the
> _ function?
>
> Regards,
>
> Nick.
>
>
> Doug Blank wrote:
> > Developers,
> >
> > Just wanted to describe the current status of
> third-party plugins, now
> > called "addons" (shorter than the word "extensions",
> and different
> > from "plugins" because of their 3rd-party nature.)
> >
> > As Benny suggested, I've created a new sourceforge SVN
> called
> > gramps-addons. The idea is for this to be open to most
> anyone that
> > wants to share their external plugin.
> >
> > I also have a distributed solution for addon-based
> translations,
> > thanks to Brian's suggestion and his work in trunk. It
> works something
> > like this:
> >
> > 1. make a catalog of all of the translatable phrases
> in your addon
> > 2. look to see if that phrase has been translated in
> gramps.pot (core
> > translations), or in any other addon
> > 3. allow you to edit your translations in a local
> version, called, for
> > example, MyAddon/po/fr-local.po
> > 4. to build your addon, you create your own locale
> collection of translations
> > 5. when you run your addon code, you'll be using your
> translations as a fallback
> >
> > This was a little tricky in registering the addon via
> Benny's new
> > gpr.py interface as that has strings that presumably
> need to be
> > translated by the addon! I didn't want to add a
> dependency to the
> > plugins to TransUtils, so you currently need to add
> this at the top of
> > your gpr file:
> >
> > from TransUtils import get_addon_translator
> > _ = get_addon_translator(__file__).gettext
> >
> > This redefines "_" to be a version that will fallback
> to the locale in
> > the addon's subdirectory. (Benny, if you don't mind a
> dependency on
> > TransUtils, we can predefine (or redefine) this in the
> registration
> > code so the gpr can be as free from code as
> possible.)
> >
> > I've created a make.py python script to help automate
> all of this
> > functionality, and began documentation here:
> >
> > http://www.gramps-project.org/wiki/index.php?title=Addons_Development
> >
> > If this looks ok, I'll start moving over the 3rd-party
> (unstable)
> > plugins from trunk, translators can help translate,
> and we can list
> > the addons on the wiki for manual installation
> testing. Next steps
> > are: create a thumbnail image for each addon, and a
> GRAMPS GUI dialog
> > to allow users to manage their addons (perhaps just a
> tab in plugins).
> >
> > Feedback welcomed,
> >
> > -Doug
> >
> > On Tue, Oct 27, 2009 at 6:40 AM, Benny Malengier
> > <benny.malengier@...>
> wrote:

> >   
> >> 2009/10/27 Doug Blank <doug.blank@...>:
> >>     
> >>> Developers,
> >>>
> >>> A few ideas I'd like to bounce off of you:
> >>>
> >>> 1) There are developers that work in gramps
> SVN, but that also have
> >>> third-party contributions. I think many of
> those contributions live
> >>> outside of our SVN, but there isn't really a
> reason why they must
> >>> (right?). What if we had a src/plugins/contrib
> subdirectory in SVN
> >>> where that code could be worked on in subdirs.
> It could also be
> >>> packaged there (zipped file of .gpr.py and all
> necessary files). Then
> >>> the plugin page could just point to the SVN
> repository.
> >>>       
> >> I think a separate repository should be made, so
> that users who have
> >> access to that one, do not need access to the
> GRAMPS repo.
> >>
> >>     
> >>> 2) How do plugins in other projects handle
> translations? Is there an
> >>> easy manner for shipping additional
> translation files with a plugin,
> >>> and installing them? If not, I was thinking of
> an API for us to allow
> >>> plugins to augment our current setup.
> >>>       
> >> This is a problem. The nicest would be to have
> translation inside of
> >> the gramps.pot, but not possible with another
> repository. So the
> >> solution would be to use for plugins a translation
> domain
> >> grampsplugins, and have contributed plugins use
> _() function binded to
> >> the domain grampsplugins.
> >> For translators this should not be an issue, on
> translating
> >> grampsplugins.pot, they can first use gramps.pot
> to translate
> >> everything that is already present in the gramps
> module, then
> >> translate only the missing strings. Tools like
> kbabel can work with
> >> dictionaries making it even more simple.
> >>
> >>     
> >>> 3) What about creating a new extension for our
> plugins (perhaps
> >>> .gplug) and a mime-type, so that we could load
> them, and humans would
> >>> recognize what they are?
> >>>       
> >> You mean for the tar file with plugin in it? Yes,
> that is an option.
> >> See http://live.gnome.org/Gedit/PythonPluginHowTo , so
> perhaps
> >> gramps-plugin as extension.
> >>
> >> Benny
> >>
> >>     
> >
> >
> ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry(R) Developer
> Conference in SF, CA
> > is the only developer event you need to attend this
> year. Jumpstart your
> > developing skills, take BlackBerry mobile applications
> to market and stay
> > ahead of the curve. Join us from November 9 - 12,
> 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > Gramps-devel mailing list
> > Gramps-devel@...
> > https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >
> >
> >   
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal
> Reports 2008 30-Day
> trial. Simplify your report design, integration and
> deployment - and focus on
> what you do best, core application coding. Discover what's
> new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

     

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel