Re: [Grecipe-manager-devel] Recipe managers

[Thomas H. <tmh...@gm...>]

On Sun, 2007-11-11 at 03:31 -0500, Louis-Francis Ratté-Boulianne wrote:
> Hi,
> 
> just want to mention you that I was working as well on a recipe
> manager ;-) In fact, I'm basically forking Gourmet ;-)
> 
Louis-Francis,

First of all, I'm CCing the list as I think this should be of interest
to everyone. I guess what I'd like to say with respect to Louis and
Dan's efforts is the following: 1. I'm really excited people are
interested in simplifying and improving Gourmet. 2. I'm kind of bummed
that I hadn't heard about it until now. I'd like to try to figure out
ways that we can all work together to improve the *same* project -- I'd
love to stop being the sole main developer for Gourmet and I welcome
change and help into the project. As far as community thinking goes, we
have this mailing list and the wiki I've set up at sourceforge. Let me
know what other resources would be useful.

If at all possible, I'd like to avoid a fork. Forking while you work on
radical changes probably makes sense, but let's try to merge this stuff
back in. You say your goal is a more GNOME-ish Gourmet. That's my goal
too -- in fact, one of the explicit goals of the gourmet project is to
be a GNOME-like, usable application.

> For now, there is nothing usable, so I don't want to do any public
> announcement, but it will be interesting to share ideas to keep a
> certain level of interoperability and maybe even eventually merge parts
> or share code.
> 
> My idea is to have every specialized features as a plugin, so the main
> program stays leans. So I plan to do a Nutritional plugin, a Kitchen
> plugin (fullscreen, big font, bluetooth remote...), a Network share
> plugin (with avahi..and I think Recipe Manager will help me a lot for
> that ;-)), a planning plugin (with a calendar). And ideally, I will try
> to have a core python library with no Gtk dependancies to do all the
> low-level stuff (database, import, export...). And we might even be able
> to share it.

I've thought about the plug-in solution in the past too. I definitely
like the idea but have never actually gotten around to implementing
anything in this respect. I'm looking forward to seeing what you come up
with.

> For now, it will be really advantageous to have a common format, and
> approximately the same attributes for each recipe. It's also really
> important that the format can be expanded in the future. (Maybe there is
> already existing a "ISO" format). Same think for Avahi..it might also be
> important to register service "_recipe.tcp_" on http://www.dns-sd.org/
> and to publish the reference.

There is no ISO recipe format that I know of. As long as we're talking
about overhauling, I should mention: one thing I've been thinking about
for the future is getting rid of the "cuisine" column and narrowing
Gourmet down to one "tag" column (what category is now) that can be
multi-purpose. I say this because it gets tedious to try to determine
what users will want, and many formats include a lot of fields (Course /
Cuisine / Category / Season) which create a lot of clutter in the
interface.

So, while we're talking about big changes, here's my big-change idea:
allow hierarchical categories (or "tags" if you like) and allow users to
browse recipes based on those tags. I'm thinking of something like what
f-spot does.

> If you want to see the changes I made to Gourmet so far, you can look at
> my branch :
> 
> https://code.launchpad.net/~lfrb/grecipe-manager/gnome
> 

I'm working on grabbing your code as we speak. I'll let you know what I
think once I have it downloaded. I'd also like to learn more about bzr
-- if it makes it easier to fork and re-merge than CVS does, it might be
something I'd like to be using more myself. (that said, I do rather like
CVS -- in the past I've changed other projects over to subversion, which
is supposed to be better, and it's made life harder rather than easier
for me).

> PS: Thomas, could you activate bugs report on launchpad ? (I prefer it
> to sourceforge one) Or do you prefer I start my own project with a
> different name ?

I absolutely prefer you *don't* start a new project -- let's try to
build a bigger community here rather than splitting into different
groups! I'll go ahead and activate launchpad bugs. SF's bug reporting
definitely leaves something to be desired.

Tom