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

Dave Peticolas dave@krondo.com
25 Nov 2001 16:19:39 -0800


--=-XRzHj5d8EhIej/sJtWuv
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2001-11-25 at 16:00, Derek Atkins wrote:
> Dave Peticolas <dave@krondo.com> writes:
>=20
> > On Sun, 2001-11-25 at 10:01, Derek Atkins wrote:
> > > So, I was wondering if there were some way to refactor the SplitLedge=
r
> > > into something more abstract?  In doing this I'll probably wind up
> > > re-inventing the register core, but what I was thinking was that we
> >=20
> > You would actually end up re-writing register-core because it already
> > is completely abstract. The 'register' in register-core knows nothing
> > about splits.
>=20
> Well, perhaps the SplitLedger, as it stands, still needs a little
> refactoring.  For example, it would be nice if I could have a
> SplitLedger and an EntryLedger that share the same color scheme.

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.


> > > 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.

dave


--=-XRzHj5d8EhIej/sJtWuv
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA8AYqb5effKKCmfpIRAuCjAKDzTpkjEcRWrP/bwY7CP8msj0OooQCg2NAu
s6XzwIZk3bLloXOYY5w9r2I=
=kdma
-----END PGP SIGNATURE-----

--=-XRzHj5d8EhIej/sJtWuv--