It's been rumoured that Heath Martin said:
>
> [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?
Each virt row is 'printed' by only one cursor.
> Or can a virtual row have several cursors
> associated to it, each of which is associated to multiple (but
> different) physical rows?
No.
Hah. Its not clear because it got mushy when multiple cursors of multiplke sizes
got introduced. But the following remains true, always:
-- a phys row can belong to only one virt row at a time.
-- a cursor is always the same size as the virt row its on,
-- there is only one cursor for a given virt row.
-- there is no overlap; a phys row can only belong to one virt row.
Say I have three cursors T(rans),S(plit), and B(lank). These are used to
'print' the following registers
virt row 1 T
virt row 2 S
virt row 3 B
virt row 4 T
virt row 5 S
virt row 6 S
virt row 7 S
virt row 8 S
virt row 9 B
* You can see there is only one cursor per virt row. There is no overlap
* between cursors and virt rows, the correspondence is one to one. Note
* that the three cursors T,S and B may consist of one, or more phys rows,
* e.g. B and S may be one line each, but T may be two lines. Thus, we
* have the following physical layout:
*
* phys row 1 virt row 1 T
* phys row 2 virt row 1 T
* phys row 3 virt row 2 S
* phys row 4 virt row 3 B
* phys row 5 virt row 4 T
* phys row 6 virt row 4 T
* phys row 7 virt row 5 S
* phys row 8 virt row 6 S
* phys row 9 virt row 7 S
* phys row 10 virt row 8 S
* phys row 11 virt row 9 B
*
* This layout remains static until the next time that the table is
* re-'printed'.
>
> > 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),
Yeah ... well ... there's a bitflag for what changed, called 'changed'
in SplitLedger.c We could compare the bits in this flag to the bits
in the current sorting order & determine if a resort occured. Currently,
the engine does not provide a bitflag saying 'these attirubutes are used during
sorting,' but I suppose this could be changed.
> since a GUI only needs to decide on
> a proper screenful to draw.
screenful? A good widget shouldn't bother drawing anything whose pixels aren't
visible. e.g. Xbae is good at displaying huge tables for this reason:
it only drws the few rows that are visible.
> 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.)
Most widget writers will be real parranoid about touching storage
outside of its control. Xbae is like that: it copies in all data.
If it didn't do that, there's potential for some very very hard-to-debug
bugs where an application might be freeing/reallocing memory that the
widget was expecting to use, etc. I can't imagine the gtk widget is
going to be any less paranoid.
> > 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).
Right.
> 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.
Well, the other possiblity might be to keep a list of of what it drew last
time, and see if ... well, that on't work either ...
e.g. Create two bank accounts. transfer money from one to the other.
Open two registers, showing each account. Change the amount in one window.
Note that the other window also redraws, to show the new correct amount.
Since you changed an amount value, potentially *all* displayed balances change
in *both* register windows (as well as the leger balance in the main window).
Three or more windows may be involved if you have e.g. windows open for bank,
employer, taxes and your entering a paycheck... (or correcting a typo in an
old paycheck)...
The only thing I can think of is a bit stored with every table entry, stating
'this entry has changed since lst time, redraw it'. But that still doesn't
avoid the overhead of reloading the table from the engine.
--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
