Rob Browning writes:
> Alexandru Harsanyi <[EMAIL PROTECTED]> writes:
>
> > Rob, I'm working now on the register window code, to add some menus,
> > toolbars, and make it usable. If you want, I will look for that bug
> > too. I will submit a patch at the end of the week or maybe next
> > week.
>
> If you're going to do a lot of work on the register itself then you
> should probably consider coordinating with Heath. I believe he's
> working directly on that ATM.
Indeed, I am working on this, but it sounds like Alexandru is working
on the register window, whereas I am working on the actual register,
so probably there won't be too much overlap, and what there is can
be resolved easily.
BTW, I currently have a gnome canvas version of the register up, in a
manner of speaking. I've only hooked in the call to
xaccRefreshTableGUI, so it doesn't do much except refresh at the right
times :-), but nonetheless it's progress.
I have a couple of questions about the register code, for those who
have studied/designed it. The Table struct currently has a Locator
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
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. 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.
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?
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
