Rob Browning writes:
> 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).
No, this isn't what I meant; mainly I'm looking for a good way to
translate the configuration information in splitreg.c (currently given
in # of characters) into something (in pixels) the GUI can use that
looks uniform, but I'm starting to see that it's not really possible
without more configuration information in splitreg.c. I'm trying to
not think of the GUI as a fixed array of cells, like a spreadsheet,
but more like a list of rows whose individual columns may be
different, in number, in width, or both. (However, we will need to
clip text to fit the cell, except perhaps when it's being entered.)
> 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):
Yes, this is what I was thinking. As another example,` in a multiline
cursor, have the left sides of the description and memo cells line up,
but the memo cell be longer to the right.
>
> | 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 is exactly what I want. So, the top line could be given a
"percentage of space" specification like (0.2, 0.1, 0.5,0.01,...)
[something that adds to one] and the other row like
(0.1, 0.1, ... ). This would make some columns line up correctly (e.g., the
right sides of the date field on the top line, and the number field on
the second line). We could also specify left/right borders, etc. or
whatever.
> 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.
Yes, this would be nice, too, and probably not difficult. We could
probably get really fancy here if we wanted, for example, pop up a
persistent box that sits on top of the register and allows for full
editing support of the transaction (and of course, that can be popped
back down again).
> 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.
This is probably possible, but I'm not sure how to do it the right
way. I haven't looked at any of the startup files, but I believe it
wouldn't be difficult to support. Isn't it mainly a GUI thing anyway?
The GUI, given enough hints, can either ignore or enhance what
the table and splitreg provide, as long as the data it needs is
in the table.
> 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.
The comments in splitreg.[ch] (thanks, linas!) mention defining
up/down traversal orders, too, besides just left/right traversals.
Another possibility is to move to the cell in the next row whose
purpose is nearest what we're leaving. e.g., from a date cell to a
date cell, or a number cell to a number cell. It's not clear that we
should move to the "visually closest" cell, since with different
cursor layouts this may be a little confusing. On the other hand, it
seems like a reasonable layout will keep same-purpose cells close
together visually. We'll probably end up experimenting a bit here,
and probably we can make all of this user-configurable, within limits.
I personally think I would like arrow keys to move between
transactions or splits, but I can see how this would be annoying for some.
(Another example: what to do about the enter key?)
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
