An easy-to-use application that will help you to discover what to cook today, tomorrow, the rest of the week and for your special occasions.
Get it here: Stable Flatpak / Nightly Flatpak / OS X binaries
Development Resources |
git clone --recursive https://gitlab.gnome.org/GNOME/recipes.git
Resources
Useful data sources, and information around food, cooking and recipes:
- the USDA database
Plans
0.1. GNOME 3.24
We are aiming to make a first, generally useful release of recipes with GNOME 3.24.
This is what we need to get there:
DONE Drop the ingredients view (it is not really useful in its current form, and we don't have time to revisit it)
DONE Complete the shopping list view early mockup
DONE Flesh out the cooking mode early mockup
DONE Recipe contributions! We need at least enough recipes to kick out all the test data (on the order of 20)
DONE A flatpak build
DONE An OS X build
0.2. GUADEC 2017
Recipes was conceived as a birthday present for GNOME's 20th birthday, so we should wrap it up nicely and present it at GUADEC.
0.3. GNOME 3.26
DONE Switch to meson as the only build system, no need to carry two build systems forever.
DONE Host (most) image data online 778619
DONE Download database updates from the web 779223
DONE Documentation
DONE Inline editing of ingredients 779908
DONE Reordering ingredients by drag-and-drop
DONE Move flatpak builds to gnome-apps-nightly and flathub
DONE Better unit handling, including unit conversion 775855
Better sharing, including sending shopping lists to your phone 775854
DONE Import in other formats Gourmet XML
- Export in other formats
0.4. GNOME 3.28
We haven't really made any concrete plans beyond 3.26 yet, but some interesting ideas have been tossed around:
- Support video, in some form
- Cocktails
- Re-using parts of recipes (e.g. a standard dough recipe could just be included by reference)
- More flexible layout (reflow when the window is wide)
- More sharing: facebook
0.5. Cleanups, refactorings, improvements
The kind of stuff that doesn't fit onto a roadmap but still needs to happen, to prevent source decay.
- Load cuisine data from a file or resource that is easier to edit and update
- Load ingredients data from a file or resource that is easier to edit and update
- Load units data from a file or resource that is easier to edit and update
- Using an enum for dietary restrictions has not really worked out too well. Maybe do it differently
- The exporter code is a bit of a tangle of nested async operations; it should be cleaned up to be less confusing
Figure out a way to share the recipe <> keyfile conversion between the recipe store and the importer/exporter code. We've already had bugs where they got out of sync
- Naming: category vs. meal vs. diet - which one is it? In the ui, we mix up categories and diets, in the code, we mix up categories and meals. A mess
Clean up the interface between GrCookingPage and GrCookingView