thinkle
commented
10 years ago We actually started with a single window and evolved away from it for a reason. The thing is, recipe data entry and recipe editing are two different tasks, and including the controls for data entry mucks up the display interface substantially. For day-to-day use, my feeling is that the recipe display entry is clean and makes simple things (multiplying, nutrition) easy and intuitive. The recipe editing and importing interfaces, on the other hand, are not clean, but they are powerful and fast. As someone who has done a lot of data entry, it's essential to me that I can type data in fast and see what's there, and that I can structure data that's already typed (web import, text import, whatever), and Gourmet provides tools for all that. I worry that simplifying the editing interface would involve getting rid of higher levels of functionality (grouping ingredients, pasting in a list of ingredients all at once, editing shopping and nutritional keys, etc).
Now it's possible some new set of UI conventions will allow us to combine elegance and power, but with the basic gtk conventions, adding a bunch of controls of whatever kind to the recipe display has the substantial risk of mucking it up.
I guess the other thing that occurs to me is that if we're going to put a bunch of design/UI work in, we might want to focus our energies elsewhere, on either the web front-end or on some kind of touch interface, both of which are substantially different problems and will likely require substantially different solutions.
What about modifying the recipe card display as to allow in-place editing of the different sections (description, ingredients, instructions, notes) by adding a little pencil icon or so to each to switch between read-only and editing mode (as found e.g. in the GitHub issues tracker UI)? I think that such a change would make editing recipes feel much more light-weight, and would entail dropping the recipe editor window altogether.