RFC: refactoring window-register as widget-register + containing window

Derek Atkins warlord@MIT.EDU
25 Nov 2001 19:33:47 -0500


Dave Peticolas <dave@krondo.com> writes:

> Yes. Colors are easy, the harder part is all the stuff in
> the split ledger with functionality you would want to have,
> like deleting whole blocks, auto-completion, etc. that right
> now is hard-coded for splits & transactions.
> 
> 
> > My point is that the SplitLedger appears to be more than just "Layout
> > and Data Representation of Splits".  It seems to contain a lot of
> > other stuff, too, which I would think can be abstracted into one more
> > layer.
> 
> Sure, I agree with you. We have levels of functionality to consider:
> 
> 1) cell types
> 2) layout
> 3) low-level handlers (getters, setters, labelers, etc.)
> 4) high-level handlers (cut/copy/paste blocks, auto-completion, register
>                         loading, etc.)
> 5) window-level handlers (menus, iconbars, etc.)
> 
> 1-3 are pretty much finished and very flexible. setters need to be
> broken out into per-cell-type handlers and a scheme configuration
> format needs to be defined.
> 
> 5 is what you and Josh have been discussing, I think.
> 
> 4 is what you are talking about now, I think.

Well, 5 is certainly what Josh has been discussing.  I haven't said
much (other than 'general tools are good').  But yes, 3 and 4 are what
I'm talking about.

Moreover, I'd like to be able to re-use as much of SplitLedger as
I can.

> > > > could have a way to register cell-types with the split ledger, or
> > > > rather, register the functions used to create/modify "Splits":
> > >=20
> > > You can already register new cell types.
> >=20
> > With the SplitLedger?  At runtime?  How?
> 
> You can register new cell types with the cell factory
> in src/register/register-core. I recently rewrote the
> register layout/model stuff with dynamic configurability
> in mind, including a scheme layout file.

By this do you mean 'Date', 'Text', 'Amount', etc..  Or do you mean
DATE_CELL, NUM_CELL, DESC_CELL, CREDIT_CELL, DEBIT_CELL, etc.  If the
former, great.  If the latter, then I think the abstraction is wrong.

> dave

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available