On Sat, Oct 25, 2008 at 11:55 AM, David G. Mackay <mackay_d@bellsouth.net> wrote:


The tarball doesn't include the data subdirectory, so that causes
several failures with the python setup.py install command.  (I did the
installation of the 0.14.0 on a different system than the 0.13.4.

Yep -- some others have mentioned this. I've just fixed in CVS MAKEFILE (though I haven't made a new tarball yet)

On line 651 in src/lib/legacy_db/db_085/rdatabase.py it should be
convert.Converter, not convert.converter.

Yup -- also already noted, but thanks for the reminder -- your e-mail prompted me to actually fix it :)

setup.py didn't handle copying gourmet.desktop.in to gourmet.desktop

Not sure why this would be -- on my system this is working. Does this work out of CVS for you?

Activating the gxml import plugin is a bit confusing.  When I first
tried to import the recipes.xml file produced by 0.13.4, I got the no
plugin found message.  When I looked under
Settings/Plugins/"Importer/Exporter" it showed the gxml module as
export.  Finally, I decided to activate it, and was able to import the
recipes.  A bit of documentation, and/or a change in the screen data
indicating that activating the module adds both import and export
capability would help to clear things up.

I'm still just working on getting the plugin system up and running. Long term, there will be a number of plugins that should be activated by default, including probably all import/export plugins. In those cases, the plugin system isn't really so useful in that users wouldn't want the functionalities provided. But it is useful in that it will let us isolate non-working functionality, and also will make it easier for developers to create alternative versions of some functionality (see below).

I think the idea would be:

1. Activate most import/export plugins by default, unless it is shown to cause a substantial slow-down to start-up time.
2. Consider making the import/export UI's show you when there are non-active plugins that could extend the functionality.

During the import process, there was no progress bar activity.

Strange -- I'm testing right now and I see a progress bar.

After the import, I wasn't able to view the imported recipes until I
quit, and then restarted gourmet.

Again, I'm not seeing this when I'm testing from my devel machine (CVS HEAD)

How set are you on using sax to handle the xml?  I had 0.13.4 set up on
a laptop with 512MB (of which 64MB is used by the display card) running
Fedora 9.  I also had a firefox session running with several tabs open.
The export took over 24 hours because everything went to virtual memory.
The import was done on a system running Fedora 9 with 3 GB of memory,
and went considerably faster, but top showed memory utilization for the
gourmet process peaking above 900MB.

That's bad. How many recipes do you have in your DB? At any rate, this is one of the places where the plugin system really helps. You (or anyone) can develop a second export plugin and test it side-by-side with the existing one very simply. Obviously I'd be happy to switch to something faster that provides equivalent functionality.

Do you have any documentation for your coding standards?  I've used
python and glade/pygtk for a while now, and there are several things
that I'd like to see added.  I've also worked a lot with mysql and
postgresql from python, so I might be able to help with that integration
as well.

We don't yet have documentation. I have been going through the codebase and cleaning things up a bit -- that's what created the converter error in the legacy_db code. Unfortunately, standardizing always creates the possibility for new bugs, so I'm not sold that it's worth it. That said, for new code it would be nice to at least keep method_names_looking_like_this and ClassNamesLookingLikeThis. I think camelCase attributes would be logical, which would make attributeNames and method_names distinguishable, but that's not something that's true throughout the codebase currently -- I believe you'll see a mix of camelCase and under_scores.
As to adding functionality to Gourmet, as you've seen, we're moving in the direction of simplifying the core and adding new functionality as plugins. If you look at the sf wiki you'll also see TODO lists and a discussion of the plugin architecture, as well as various wishlist items for the future.