[EMAIL PROTECTED] writes:
> It's been rumoured that Heath Martin said:
> > 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 ..
The part about a virtual row being possibly several physical rows is
clear. I'm not sure I understand the second part: is each cursor an
individual virtual row? Or can a virtual row have several cursors
associated to it, each of which is associated to multiple (but
different) physical rows?
> 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.
Yes, it's the reordering part which causes the most difficulty. As
for GUI redraws, this is easy enough to manage (and actually might
conceptually be easier if we knew the table wasn't going to
change under us too much), since a GUI only needs to decide on
a proper screenful to draw. Once we get the table data organized
the way we want, we just tell the GUI that it needs to redraw. If
the GUI gets enough hints as to what to draw, it only needs to draw
a screenful, and this is not a heavyweight operation. (I'm assuming
here that the GUI does uses the data in the table directly, and does
not copy the table to its own storage.)
> 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.
Well, I don't see it clearly just yet, but I'm getting there. Keeping
the concept of a "cursor" as a block of cells is quite natural. I
imagine the table as just an ordered list of blocks (or splits, I
guess). One possibility is to keep a list or hash table of splits
(not sure what the key should be, but presumably the engine can
provide a unique identifier for a split), and each entry in this table
tells us how to draw the split; this could include an ordered list of
cellblocks associated to this split, for example, as well as the
actual text to draw. Taking care of the order would be easy if we
ordered on only one field, and probably we could keep track of
multiple orders at once. (A split could have a next_date_split,
next_alpha_split, etc which we update when the cursor is committed.)
But like I say, I don't understand the current code well enough to be
confident here just yet, but it's something to think about. I'm
mainly just trying to avoid essentially recreating the entire table on
every commit. Of course, all of this would horribly break the
existing motif and gtk GUI code.
Thanks for your explanations!
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
