It's been rumoured that Heath Martin said:
>
> I have a couple of questions about the register code, for those who
> have studied/designed it. The Table struct currently has a Locator
The fault is mine. I never quite finished it the way I wanted, unfortunately,
the scaffolding to hold it together and teh real code are quite indistinguishable.
At least that's my excuse.
> member for each physical cell that gives the virtual row/column the
> cell lives in. Does it make sense (it makes the GUIs life much
> easier) to have a "Reverse Locator", that given a virtual cell, will
> point to the physical row/column origin. Well, I guess it makes sense
> and is very easy to implement, but would it be useful in other places
OK, the only gotcha to watch out for is that one 'virtual' row (cursor)
can be one, two (or more) physical rows. Next, several different 'cursors'
can be in use at once, each of a different size ... e.g. one to hold
the transaction date & description, follwed by several others that hold the
individual splits, followed by e.g. a blank line ..
FWIW a count is kept when the register is loaded.
> besides for the GUI? For example, I believe that the current code
> will reload the entire table when a cursor is committed (correct me if
> I'm wrong here) because the table needs to stay in order with the
> order of the splits.
Well, if the user changges an amount somewhere in teh middle, all of the
balances change and so need to be redrawn. If a date changes, then
the order changes and everything needs a redraw. Because teh user can sort not
just by date, but also by amount, by alpha order, etc, just about any change can
cause a reordering and thu a need for a redraw.
So, although I try to be clever and not redraw too much, it gets to be
hard after a while. There are already a couple of alarming bugs due it's not
redrawning often enough.
> Could we not just change Locators and Reverse
> Locators? But maybe this isn't any more efficient in the end, and may
> not be feasible with the current design. If we went this far it might
> make sense to redesign the table (as a list or hash table or
> something), and it may not be worth the effort.
As orignally conceived, the 'table' was going to be a very regularly-spaced,
grid-like thing. Then rob browning convinced me this wouldn't work, since
one might need to have a differing number of splits, intermixed with rows that
have different functions and hold different info. Thus, the locator was invented
to help keep track of sizes and locations.
If you think you can see all this clearly enough, then yes, I supppose you can
redesign the table. All I want to keep is the concept of a 'cursor' as a
block of cells, a die stamp. into which I can punch data.
> Another question: in the SplitRegister struct in splitreg.h there are
> members single_cursor, double_cursor, etc. which define five types
> of valid cellblocks for the register. Could we, instead of having
> these, make an array of cursors, indexed by an enum of cursor types:
>
> enum {
> SINGLE_CURSOR, DOUBLE_CURSOR, ... };
>
> then instead of using single_cursor, use something like
> cursors[SINGLE_CURSOR]. Then we could store in the handlers array the
> type of cursor, rather than the pointer to the cursor. I ask because
> in my current register code, I set up a style for each type of cursor,
> and then decide on how to draw a virtual row based on the handler for
> that row. It would make the code cleaner to use the enum, and one can
> also envision having a special type like USER_DEFINED in which the
> user can dynamically set up a preferred cursor (colors, fonts,
> justification, order of cells, etc). Does any of this sound
> reasonable?
I was planing/hoping to take almost all of the contents of splitreg.c and
turn it into a giant config file under the user's control. You will notice
that it has a very regular structure: Its the highly concentrated distilate of
anything and everything you'd ever want to configure about the register.
Never got around to it, among other things, there wasn't much demand.
Although I have no sentimental attachement to splitreg.c,h what I strongly
recommend would be the creation of a new register, keeping splitreg around
until the new reg is stable. e.g. register.c still works, its just an older
and simpler implementation that is no longer used.
--linas
>
> Best Regards,
> Heath Martin
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
