Heath Martin <[EMAIL PROTECTED]> writes:
> First, the cell widths in a cursor are configured in terms of
> characters. For a GUI, it's necessary to convert these into pixel
> widths, but there are a couple of problems with this. There are
> some naive but effective ways: just fix the width of each column
> based on the maximum character width of a cell in that column, or
> fix the width of each cell individually. The first solution works,
> but one would like to have corresponding cells in a "column" of
> different widths.
I'm not sure what you mean here? If you're saying that every cell
should be just big enough to hold it's contents, then I'd have to
disagree. What happens when the user makes a string in a cell longer?
Also, this would look really messy. (I probably just misunderstood
you here).
Now if you mean that columns in some rows should be a different width
than columns in others, and perhaps that there should even be a
different number of columns for different *types* of rows, then I
might agree with that. For example, in the multi-line register case,
it might be nice to support something like this (though I'm not sure
it'd look OK):
| 6/20/1998 | 101 | Paycheck |n| 1000.00| | 1000.00|
|XXX| DEP | Some Savings | Net take home pay | 726.00| |XXXXXXXX|
|XXX| 113 | FICA | Income tax | 150.00| |XXXXXXXX|
|XXX| | Medicare | Medicare | 98.00| |XXXXXXXX|
|XXX| | Soc Sec | Social Security | 26.00| |XXXXXXXX|
This would make better use of the available space, with the one
drawback that the "Num" columns in the split lines don't line up with
the "Num" line in the parent line, but I don't really think that's a
big deal, and unless this looks horrible, I think it provides a nice
visual separation between transactions, and between the parent line
and the contained splits.
I mean for the areas with XXX to be completely blank, with no
horizontal dividing lines. This makes it clear that these areas are
"unused". To some extent, this setup looks sort of like the CTree
display without the "+"'s. For bonus points, it would be really cool
if we could have a collapse/expand button column to the left of the
date column on the transaction's main line that lets you open/shut
multi-line mode for each transaction.
The widths of each column should be calculated based on the maximum
number of characters for the row (calculated from the cell info) times
the maximum character width (+/- some fudge factor perhaps).
Does this sound reasonable, or am I overlooking something?
Actually, it might even be interesting to eventually support
configuring the row contents at runtime in case the user wants a
different layout. (For example, I've always wanted a wider row in the
single-row register that includes the memo field.) However, I'm not
sure that's practical.
> Note that we can't really just configure the pixel width directly,
> since as the window size changes, and as the font size changes, the
> width of the rows should change too (probably within some limits).
If the font size changes, I think we should just redraw the whole
register. And for now, if the window size changes, I think we should
do nothing other than activate the horizontal scroll bar, if needed.
> Second, the traversal order within a cursor is nicely defined, but
> there doesn't seem to be a way to determine which cell we should
> activate when the block is first entered, say on an up or down arrow
> press.
I think a down or up arrow should always go to the nearest cell above
or below the current cell. Since we have a fixed number of characters
per field type, and if we compute the cell width based on the number
of characters, which cell is "nearest" above/below a given cell type
should always be the same.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
