On Fri, Jan 30, 2009 at 8:13 AM, Benny Malengier
> 2009/1/30 Brian Matherly <brian@...>
>> > > 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.
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