I've been puzzling out the relationship between the code in window-register.c [RegWindow, let's say], the GNCLedgerDisplay, the SplitRegister, the GnucashRegister, the GnucashSheet and the Table...
After talking to dave_p this evening, things are much more clear.
I was especially curious about what constructs like the following [slightly
edited] were all about:
void gnc_register_jump_to_blank (RegWindow *regData)
{
SplitRegister *reg = gnc_ledger_display_get_split_register (regData->ledger);
VirtualCellLocation vcell_loc;
Split *blank;
blank = gnc_split_register_get_blank_split (reg);
if (gnc_split_register_get_split_virt_loc (reg, blank, &vcell_loc))
gnucash_register_goto_virt_cell (regData->reg, vcell_loc);
}
Specifically, it seems like there's two very similar registers at play
['(SplitRegister)reg' and '(GnucashRegister)regData->reg'].
But, as it turns out...
The SplitRegister is, as mentioned, an application-specific
Split-containing-thing editor, which interacts with the Table [a ui-agnostic
tabular editor], which itself is an MVC-patterned thing.
The GnucashRegister is a Gnome-specific UI for that table ... it should
probably be named GnomeTableView, but isn't.
Thus, the call above gets the vcell_loc of the blank_split from the
application-specific SplitRegister, and feeds that to the UI-specific
GnucashRegister [read: GnomeTableView]... thus jumping to the blank split
as per the user's request.
In the course of this, I came up with a .dia file of the relationship
and navigability between these things; a .png export of it is attached.
Please forgive my mangling of UML notation.
...jsled
register_ledger_sheet_oh_my.png
Description: PNG image
