0.14.0

[David G. Mackay]

Greetings,

I recently installed 0.13.4 and played with it a bit.  There were a few
things that looked like they could be improved, but before I mentioned
those, I thought that I'd try the latest and greatest.  There are a
couple of issues with 0.14.0 that I thought that I'd mention:

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.

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

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

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.

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

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

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.

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.

Dave



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel

[Thomas Mills Hinkle]

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

Greetings,

<snip> 

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.

Tom

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel

[Thomas Mills Hinkle]

I've taken a look at the wiki.  One thing that popped out when I was
doing a series of imports from a text file is that it would be nice to
automatically pop up the recipe card for editing after import.  I see it
as a checkbox item on the import screen.  If you think it's useful, I'd
be happy to take a shot at it.

This strikes me as very useful. It may make more sense for this to be part of the core functionality rather than a separate plugin. Popping up the recipe card itself, though, might be trickier to implement -- this is something you'd want for 1-2 recipes, but not something you'd want to see for a larger import.

Perhaps the following makes sense (for all imports):

A. If only 1 recipe was imported, pop up the recipe card automatically (display view -- the user can then click "edit" to correct anything that's wrong).
B. If more than 1 recipe is imported, pop up a dialog with an embedded recindex view (like the index view) containing the newly imported recipes.

Behavior "A" seems like it's clearly the "right thing" to me. Behavior "B" is tricker -- it could be considered more logical to show the newly imported recipes in the standard recipe view, but this could be a confusing behavior if the user was in the middle of looking at other recipes when the import finishes. On the other hand, if we pop up a new window, that could seem like overkill to a user whose first action is to import a bunch of recipes, because in that case they'd suddenly have *two* windows showing their new recipe. This suggests a model where we do the following...

A. If only 1 recipe was imported, pop up the card.
B. If more than 1 recipe was imported and there are no recipes in Gourmet yet, don't pop up anything, just update the index view.
C. If more than 1 recipe was imported and there are existing recipes, pop up a window listing the new recipes and update the index view.

Does that make sense to people, or is that introducing unnecessary complexity?

Tom

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel