[neelix-devel] Wake up

[Hans F. <ha...@fu...>]

Ok, I'm graduated. Now I'll finally have time to work on Neelix. I'm
hoping to get some momentum, please feel free to jump on at any time and
help in any way.

This is the time when we see how maintainable our code is. :-) I suspect
there will be some refactoring, but hopefully I can restrain the desire
to refactor everything in sight and only refactor what needs
refactoring. I've been reading "The Art of UNIX Programming" by ESR and
it's a great book with some very pragmatic perspectives and opinions.
ESR isn't a big fan of OO it seems, and prefers simplicity and a
well-defined interface over OO for OO sake. A lot of things got me
thinking and I was afraid I might want to refactor everything. But as I
thought it through from the ground up I think we're not far from the
best approach, so I'm confident we can keep using the codebase we have.

Let me review the MVP (model-view-presenter) approach we were taking,
and which I think is still a good approach. The model is the data, the
presenter operates on the data ("business logic"), and the view is the
UI. I propose the following simple rules as to what goes where: the
model is attribute readers/writers and observable. The presenter is
everything more complex than read/write to the model, that is logically
separate from the UI. Traditionally the view only reads from the model
and does writes through the presenter, but in the case that you're just
setting a value in an object it seems a waste to have all that framework
code. On the converse, when something does become more complex we must
remember to move it to the presenter so that it can be reused by other
views. There may be views (e.g. nontraditional views that we haven't yet
considered) that need their own presenters because they don't fit well
with the first presenter, but nobody should have to rewrite the model or
a piece of it (if so we have a design flaw). Any thoughts on the overall
design, then?

Given that design, I see the following action items:
- sweep through the code; document it and clean up any messes
  (refactoring as necessary) I want especially good documentation on the
  model.
- Polish the model (I think it's mostly done, IIRC)
- Get a complete GUI skeleton (e.g. not attached to the model or perhaps
  initialized from the model but unconcerned about changing things)
- Identify presenter items and code them. I think the presenter will
  grow organically but we should knock off anything big and obvious up
  front.
- glue

As far as functionality,
0.1.0 - target: Independence Day 2004
Recipe management.
  - organized into categories in cookbooks
  - partial ingredient implementation (e.g. to the degree needed for
    receipe management)

Please give me your thoughts, now that you've lent me your brains for a
moment. Then take up an action item and run, walk, or crawl with it. If
not, I'll chip away at them myself. I believe the best impetus for an
open source project is someone(s) spewing code (or some kind of tangible
work). 

-- 
 .O.  Hans Fugal            | De gustibus non disputandum est.
 ..O  http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
 OOO                        | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95  CB5E FC98 E8CD E0AA D460