Re: [Gramps-devel] Common code for plugins

[Brian Matherly <brian@gr...>]

Doug,

> > I think I found a way to have shared code among
> plugins. Check out the
> > latest trunk. A new directory has been added:
> "plugins/lib". In this
> > directory, there is one file named
> "libholiday.py". libholiday aggregates
> > the holiday file parsing needs of the WebCal, Birthday
> Report and Graphical
> > calendar reports.
> >
> > I have also divided
> "src/plugins/Calendar.py" into two files
> > "src/plugins/drawreport/Calendar.py" and
> > "src/plugins/textreport/BirthdayReport.py".
> "src/plugins/WebCal.py" has been
> > moved to "src/plugins/webreport/WebCal.py".
> >
> > This implementation seems to work, but it is not set
> in stone. Still up for
> > debate:
> >
> > 1) The name of "src/plugins/lib". I called
> it "lib" because it seems like
> > it should store pluggable libraries of code that is
> shared by other plugins.
> > But we considered other names like "common".
> Anyone have a strong
> > preference? Because I don't.
> >
> > 2) The name of "libholiday.py". I added
> "lib" as a prefix to indicate that
> > it is a library and not an actual plugin. Is this
> distinction useful? Any
> > better ideas?
> >
> > We should now be able to start dividing the rest of
> the plugins and move
> > them into their respective locations.
> >
> > ~Brian
> >
> 
> Brian,
> 
> That looks very clean, and clever! I like the way that it
> appears as just
> another plugin, and shows whether it loaded or not.
> 
> I guess there isn't any problem with name spaces,
> because each of these will
> live in their own libXXX and only brought in when imported?

That was part of my reasoning for having the "lib" prefix on the files.

> The only issue
> related to all of these changes is:
> 
> http://www.gramps-project.org/bugs/view.php?id=2637
> 
> I was going to put the type/directory in that tree list in
> the Load Plugins
> dialog, but it appears that there is a dictionary that uses
> the filename
> (not path) to lookup bits about the file. I think that this
> currently means
> that two plugins can't have the same name, even though
> they are in different
> subdirectories.

I agree. It is my long-term plan to make that work. If you look in gen/plug/_plugins.py, you will see I have created a base class for all plugins. I am slowly converting all plugins to register as a plugin object. Each specific plugin needs a specific plugin type. So far, I have made an import "gen/plug/_import.py" and export "gen/plug/export.py". Once all the plugins are converted then we can add other tidbits of information like path to the plugin base path.

> On a related note, when I split up DefaultGramplets into
> their own files,
> I'm wondering if I should name them *Gramplet.py? For
> example, should the
> DataEntry Gramplet be: DataEntry.py or
> DataEntryGramplet.py?

Personally, I would prefer the "Gramplet" suffix. I've been trying to give all the plugins a common suffix or prefix. Look in plugins/export, plugins/import, plugins/graph and plugins/docgen. But I don't feel strongly about this.

~Brian

[Gramps-devel] Common code for plugins

[Brian Matherly <brian@gr...>]

I think I found a way to have shared code among plugins. Check out the latest trunk. A new directory has been added: "plugins/lib". In this directory, there is one file named "libholiday.py". libholiday aggregates the holiday file parsing needs of the WebCal, Birthday Report and Graphical calendar reports.

I have also divided "src/plugins/Calendar.py" into two files "src/plugins/drawreport/Calendar.py" and "src/plugins/textreport/BirthdayReport.py". "src/plugins/WebCal.py" has been moved to "src/plugins/webreport/WebCal.py".

This implementation seems to work, but it is not set in stone. Still up for debate:

1) The name of "src/plugins/lib". I called it "lib" because it seems like it should store pluggable libraries of code that is shared by other plugins. But we considered other names like "common". Anyone have a strong preference? Because I don't.

2) The name of "libholiday.py". I added "lib" as a prefix to indicate that it is a library and not an actual plugin. Is this distinction useful? Any better ideas?

We should now be able to start dividing the rest of the plugins and move them into their respective locations.

~Brian

Re: [Gramps-devel] Common code for plugins

[Doug Blank <doug.blank@gm...>]

On Thu, Jan 29, 2009 at 11:21 PM, Brian Matherly
<brian@...>wrote:

> I think I found a way to have shared code among plugins. Check out the
> latest trunk. A new directory has been added: "plugins/lib". In this
> directory, there is one file named "libholiday.py". libholiday aggregates
> the holiday file parsing needs of the WebCal, Birthday Report and Graphical
> calendar reports.
>
> I have also divided "src/plugins/Calendar.py" into two files
> "src/plugins/drawreport/Calendar.py" and
> "src/plugins/textreport/BirthdayReport.py". "src/plugins/WebCal.py" has been
> moved to "src/plugins/webreport/WebCal.py".
>
> This implementation seems to work, but it is not set in stone. Still up for
> debate:
>
> 1) The name of "src/plugins/lib". I called it "lib" because it seems like
> it should store pluggable libraries of code that is shared by other plugins.
> But we considered other names like "common". Anyone have a strong
> preference? Because I don't.
>
> 2) The name of "libholiday.py". I added "lib" as a prefix to indicate that
> it is a library and not an actual plugin. Is this distinction useful? Any
> better ideas?
>
> We should now be able to start dividing the rest of the plugins and move
> them into their respective locations.
>
> ~Brian
>

Brian,

That looks very clean, and clever! I like the way that it appears as just
another plugin, and shows whether it loaded or not.

I guess there isn't any problem with name spaces, because each of these will
live in their own libXXX and only brought in when imported? The only issue
related to all of these changes is:

http://www.gramps-project.org/bugs/view.php?id=2637

I was going to put the type/directory in that tree list in the Load Plugins
dialog, but it appears that there is a dictionary that uses the filename
(not path) to lookup bits about the file. I think that this currently means
that two plugins can't have the same name, even though they are in different
subdirectories.

On a related note, when I split up DefaultGramplets into their own files,
I'm wondering if I should name them *Gramplet.py? For example, should the
DataEntry Gramplet be: DataEntry.py or DataEntryGramplet.py?

-Doug

Re: [Gramps-devel] Common code for plugins

[Brian Matherly <brian@gr...>]

Doug,

> > I think I found a way to have shared code among
> plugins. Check out the
> > latest trunk. A new directory has been added:
> "plugins/lib". In this
> > directory, there is one file named
> "libholiday.py". libholiday aggregates
> > the holiday file parsing needs of the WebCal, Birthday
> Report and Graphical
> > calendar reports.
> >
> > I have also divided
> "src/plugins/Calendar.py" into two files
> > "src/plugins/drawreport/Calendar.py" and
> > "src/plugins/textreport/BirthdayReport.py".
> "src/plugins/WebCal.py" has been
> > moved to "src/plugins/webreport/WebCal.py".
> >
> > This implementation seems to work, but it is not set
> in stone. Still up for
> > debate:
> >
> > 1) The name of "src/plugins/lib". I called
> it "lib" because it seems like
> > it should store pluggable libraries of code that is
> shared by other plugins.
> > But we considered other names like "common".
> Anyone have a strong
> > preference? Because I don't.
> >
> > 2) The name of "libholiday.py". I added
> "lib" as a prefix to indicate that
> > it is a library and not an actual plugin. Is this
> distinction useful? Any
> > better ideas?
> >
> > We should now be able to start dividing the rest of
> the plugins and move
> > them into their respective locations.
> >
> > ~Brian
> >
> 
> Brian,
> 
> That looks very clean, and clever! I like the way that it
> appears as just
> another plugin, and shows whether it loaded or not.
> 
> I guess there isn't any problem with name spaces,
> because each of these will
> live in their own libXXX and only brought in when imported?

That was part of my reasoning for having the "lib" prefix on the files.

> The only issue
> related to all of these changes is:
> 
> http://www.gramps-project.org/bugs/view.php?id=2637
> 
> I was going to put the type/directory in that tree list in
> the Load Plugins
> dialog, but it appears that there is a dictionary that uses
> the filename
> (not path) to lookup bits about the file. I think that this
> currently means
> that two plugins can't have the same name, even though
> they are in different
> subdirectories.

I agree. It is my long-term plan to make that work. If you look in gen/plug/_plugins.py, you will see I have created a base class for all plugins. I am slowly converting all plugins to register as a plugin object. Each specific plugin needs a specific plugin type. So far, I have made an import "gen/plug/_import.py" and export "gen/plug/export.py". Once all the plugins are converted then we can add other tidbits of information like path to the plugin base path.

> On a related note, when I split up DefaultGramplets into
> their own files,
> I'm wondering if I should name them *Gramplet.py? For
> example, should the
> DataEntry Gramplet be: DataEntry.py or
> DataEntryGramplet.py?

Personally, I would prefer the "Gramplet" suffix. I've been trying to give all the plugins a common suffix or prefix. Look in plugins/export, plugins/import, plugins/graph and plugins/docgen. But I don't feel strongly about this.

~Brian

Re: [Gramps-devel] Common code for plugins

[Benny Malengier <benny.malengier@gm...>]

2009/1/30 Brian Matherly <brian@...>

> Doug,
>
> > > I think I found a way to have shared code among
> > plugins. Check out the
> > > latest trunk. A new directory has been added:
> > "plugins/lib". In this
> > > directory, there is one file named
> > "libholiday.py". libholiday aggregates
> > > the holiday file parsing needs of the WebCal, Birthday
> > Report and Graphical
> > > calendar reports.
> > >
> > > I have also divided
> > "src/plugins/Calendar.py" into two files
> > > "src/plugins/drawreport/Calendar.py" and
> > > "src/plugins/textreport/BirthdayReport.py".
> > "src/plugins/WebCal.py" has been
> > > moved to "src/plugins/webreport/WebCal.py".
> > >
> > > This implementation seems to work, but it is not set
> > in stone. Still up for
> > > debate:
> > >
> > > 1) The name of "src/plugins/lib". I called
> > it "lib" because it seems like
> > > it should store pluggable libraries of code that is
> > shared by other plugins.
> > > But we considered other names like "common".
> > Anyone have a strong
> > > preference? Because I don't.
> > >
> > > 2) The name of "libholiday.py". I added
> > "lib" as a prefix to indicate that
> > > it is a library and not an actual plugin. Is this
> > distinction useful? Any
> > > better ideas?
> > >
> > > We should now be able to start dividing the rest of
> > the plugins and move
> > > them into their respective locations.
> > >
> > > ~Brian
> > >
> >
> > Brian,
> >
> > That looks very clean, and clever! I like the way that it
> > appears as just
> > another plugin, and shows whether it loaded or not.
> >
> > I guess there isn't any problem with name spaces,
> > because each of these will
> > live in their own libXXX and only brought in when imported?
>
> That was part of my reasoning for having the "lib" prefix on the files.
>
> > The only issue
> > related to all of these changes is:
> >
> > http://www.gramps-project.org/bugs/view.php?id=2637
> >
> > I was going to put the type/directory in that tree list in
> > the Load Plugins
> > dialog, but it appears that there is a dictionary that uses
> > the filename
> > (not path) to lookup bits about the file. I think that this
> > currently means
> > that two plugins can't have the same name, even though
> > they are in different
> > subdirectories.
>
> I agree. It is my long-term plan to make that work. If you look in
> gen/plug/_plugins.py, you will see I have created a base class for all
> plugins. I am slowly converting all plugins to register as a plugin object.
> Each specific plugin needs a specific plugin type. So far, I have made an
> import "gen/plug/_import.py" and export "gen/plug/export.py". Once all the
> plugins are converted then we can add other tidbits of information like path
> to the plugin base path.
>
> > On a related note, when I split up DefaultGramplets into
> > their own files,
> > I'm wondering if I should name them *Gramplet.py? For
> > example, should the
> > DataEntry Gramplet be: DataEntry.py or
> > DataEntryGramplet.py?
>
> Personally, I would prefer the "Gramplet" suffix. I've been trying to give
> all the plugins a common suffix or prefix. Look in plugins/export,
> plugins/import, plugins/graph and plugins/docgen. But I don't feel strongly
> about this.


we did agree on not using capitalization in new directories, so
dataentrygramplet.py ;-)
A suffix does give you the info in your IDE which tab you need to click
quicker than not adding the suffix if you have many files open. On the other
hand, as the name is long it might not fit the tab of your ide.

B.

Re: [Gramps-devel] Common code for plugins

[Doug Blank <doug.blank@gm...>]

On Fri, Jan 30, 2009 at 8:13 AM, Benny Malengier
<benny.malengier@...>wrote:

>
>
> 2009/1/30 Brian Matherly <brian@...>
>
> Doug,
>>
>> > > I think I found a way to have shared code among
>> > plugins. Check out the
>> > > latest trunk. A new directory has been added:
>> > "plugins/lib". In this
>> > > directory, there is one file named
>> > "libholiday.py". libholiday aggregates
>> > > the holiday file parsing needs of the WebCal, Birthday
>> > Report and Graphical
>> > > calendar reports.
>> > >
>> > > I have also divided
>> > "src/plugins/Calendar.py" into two files
>> > > "src/plugins/drawreport/Calendar.py" and
>> > > "src/plugins/textreport/BirthdayReport.py".
>> > "src/plugins/WebCal.py" has been
>> > > moved to "src/plugins/webreport/WebCal.py".
>> > >
>> > > This implementation seems to work, but it is not set
>> > in stone. Still up for
>> > > debate:
>> > >
>> > > 1) The name of "src/plugins/lib". I called
>> > it "lib" because it seems like
>> > > it should store pluggable libraries of code that is
>> > shared by other plugins.
>> > > But we considered other names like "common".
>> > Anyone have a strong
>> > > preference? Because I don't.
>> > >
>> > > 2) The name of "libholiday.py". I added
>> > "lib" as a prefix to indicate that
>> > > it is a library and not an actual plugin. Is this
>> > distinction useful? Any
>> > > better ideas?
>> > >
>> > > We should now be able to start dividing the rest of
>> > the plugins and move
>> > > them into their respective locations.
>> > >
>> > > ~Brian
>> > >
>> >
>> > Brian,
>> >
>> > That looks very clean, and clever! I like the way that it
>> > appears as just
>> > another plugin, and shows whether it loaded or not.
>> >
>> > I guess there isn't any problem with name spaces,
>> > because each of these will
>> > live in their own libXXX and only brought in when imported?
>>
>> That was part of my reasoning for having the "lib" prefix on the files.
>>
>> > The only issue
>> > related to all of these changes is:
>> >
>> > http://www.gramps-project.org/bugs/view.php?id=2637
>> >
>> > I was going to put the type/directory in that tree list in
>> > the Load Plugins
>> > dialog, but it appears that there is a dictionary that uses
>> > the filename
>> > (not path) to lookup bits about the file. I think that this
>> > currently means
>> > that two plugins can't have the same name, even though
>> > they are in different
>> > subdirectories.
>>
>> I agree. It is my long-term plan to make that work. If you look in
>> gen/plug/_plugins.py, you will see I have created a base class for all
>> plugins. I am slowly converting all plugins to register as a plugin object.
>> Each specific plugin needs a specific plugin type. So far, I have made an
>> import "gen/plug/_import.py" and export "gen/plug/export.py". Once all the
>> plugins are converted then we can add other tidbits of information like path
>> to the plugin base path.
>>
>> > On a related note, when I split up DefaultGramplets into
>> > their own files,
>> > I'm wondering if I should name them *Gramplet.py? For
>> > example, should the
>> > DataEntry Gramplet be: DataEntry.py or
>> > DataEntryGramplet.py?
>>
>> Personally, I would prefer the "Gramplet" suffix. I've been trying to give
>> all the plugins a common suffix or prefix. Look in plugins/export,
>> plugins/import, plugins/graph and plugins/docgen. But I don't feel strongly
>> about this.
>
>
> we did agree on not using capitalization in new directories, so
> dataentrygramplet.py ;-)
> A suffix does give you the info in your IDE which tab you need to click
> quicker than not adding the suffix if you have many files open. On the other
> hand, as the name is long it might not fit the tab of your ide.
>
> B.
>
>
It isn't a big issue, but I think that plugins should keep the camel case
names. These names only appear in the plugins tabs, and they are hard to
read in all lowercase. They don't get imported by any Python code directly,
so the names are more useful for humans, and therefore should be easily
read.

-Doug

Re: [Gramps-devel] Common code for plugins

[Brian Matherly <brian@gr...>]

> > we did agree on not using capitalization in new
> directories, so
> > dataentrygramplet.py ;-)
> > A suffix does give you the info in your IDE which tab
> you need to click
> > quicker than not adding the suffix if you have many
> files open. On the other
> > hand, as the name is long it might not fit the tab of
> your ide.
> >
> It isn't a big issue, but I think that plugins should
> keep the camel case
> names. These names only appear in the plugins tabs, and
> they are hard to
> read in all lowercase. They don't get imported by any
> Python code directly,
> so the names are more useful for humans, and therefore
> should be easily
> read.

I thought that we had agreed that all new files in new directories would get the new naming convention. Basically, this means anything we put in "src/gen" should be lowercase. I think I remember that we also agreed that consistency was more important. So if an existing directory uses a certain naming convention, then new files should also use that convention.

~Brian