Wow, this is a huge improvement! I see the development warning and
the splash screen in about 5 seconds after startup, and then the account
tree comes up in another 5 or so. At least for users with somewhat
older hardware like I have, I think this will be a huge usability
improvement. It w
writes:
>
> There's a bug in the main window startup code:
> If user tries to open a file that has a lock on it (e.g. because a
> previous gnucash crash left the dangling lock), and then answers
> 'no' to the 'do you want to break the lock' question, then no main
> window shows up; but gnucash d
There's a bug in the main window startup code:
If user tries to open a file that has a lock on it (e.g. because a
previous gnucash crash left the dangling lock), and then answers
'no' to the 'do you want to break the lock' question, then no main
window shows up; but gnucash doesn't exit, and cann
It's been rumoured that Conrad Canterford said:
> Would require a rethink of how things are set out on the register (and
> possibly a significant rewrite,particularly for my more ambitious
> suggestions).
actually, shouldn't. Most of the actual register layout is specified
in one file, which bas
[EMAIL PROTECTED] wrote:
> I was thinking the other day on how to implement an a/r a/p register.
> One thing that the register needs is a per-transaction 'date due'
> field. (yes, there are other possible sol'ns but bear with me).
> Well, we could hard-wire the date-due field into a new account ty
Forwarded message:
>
> Modified Files:
> register.scm
> Log Message:
> Add memo & action field.
I was thinking the other day on how to implement an a/r a/p register.
One thing that the register needs is a per-transaction 'date due'
field. (yes, there are other possible sol'ns but bear wi
