> == The Register
>
> * Normally, I would think that using the '+' key in the check number field
> entering the next highest check number in that account would be the intuitive
> way for it to work. But I had a problem with it. When I first opened my
That's a good point, people often have breaks in their check numbers and
don't use them in perfect sequence. I'll see if I can come up with something
more sophisticated for this.
> * It would be nice if autocomplete for the description would also enter in th
> information from the last transaction with that description. That's the
> default behavior in moneydance and quicken, and I find it speeds up my data
> entry considerably. Also, I was curious why the autocomplete for the
> description didn't also pop up a window the same way the autocomplete for the
> account did. That way, someone could type in the first char or two, and
> then use the arrow keys to find the exact description they were looking for.
Transaction auto-completion will *definitely* be a future feature.
> * It would be nice if, when an unknown account is typed into the register ent
> a dialog popped up asking if the user wanted to create a new account. If the
> answered yes, then the new account dialog could then pop up, allowing the use
> to create a new account there on the spot, with the account name autopopulate
> based on what they had typed in. If they answered no, then the entry would
> behave as normal. I think this would be especially useful for new users who
> don't already have all of their accounts set up, so they can create them "as
> they need them."
This is a good feature, too. I'll try to get it in for 1.3.5.
> * It would be nice if register windows remembered their size, placement, and
> entry type (single vs double, auto split or no) after they're closed so that
> when they're reopened I don't have to go and change their settings to what I
> prefer every time.
Window placement is hard -- and not really the domain of the app. The window
manager is supposed to do that. The register window should remember it's width,
are you seeing different behavior?
As for height and register mode, you can set the initial number of register
rows and the initial register mode in the Preferences dialog in the Register
section.
> * It would be nice if there was a hot key to toggle split entry mode for a
> particular entry. Ctrl-S would be my first choice, but perhaps that is alrea
> mapped to 'Save'. If there is already such a hotkey, forgive my ignorance.
There isn't one already, but gnome/gtk has a cool feature that lets you
define your own. Using the mouse or keyboard, highlite the menu item you
want to given an accelerator to. Then press the key combination you want
to use for the menu item. After that, you can use that key to invoke the
menu item. The accelerator will be remembered even between invocations of
gnucash. This works for all gnome/gtk programs, btw.
> == Overall Structure
>
> Before I switched to linux full-time, I used Quicken '99. Its interface was
> very browser-like, in that each register, report, etc. opened up in the same
> window, and you could move backwards and forwards through these "pages" with
> the traditional "Back" and "Forward" buttons. They also had each page "tabbe
That's an interesting idea, it would definitely cut down on window clutter.
> In that same vein, I like Bill's suggestion of using Bonobo components for
> creating a richer, more functional application. I'm surprised others haven't
> commented on it yet. I've never programmed with Bobobo or gnucash, so I don'
I'm all for using Bonobo eventually, but I don't think it's even out of
CVS at the moment. I'd rather wait until it's considered part of the gnome
development platform before we convert to it.
> == Final thoughts
>
> Finally, I can't stress enough how useful a 'repeated/upcoming transaction'
> interface would be. This is the one thing that forces me to continue using
> Moneydance in parallel gnucash. The "Duplicate" option in the right-click me
Recurring transactions are on the way. We have some minor technical issues
that have to be attended to first in order to implement them, but they will
be a future feature.
> Another idea I had, and one that I think I might be able to implement (if
> others agree it would be useful), would be a druid to help users set up an
> initial set of accounts. I find the account structure given in the help file
I think others have suggested this before, too. If you feel like doing this,
please do!
thanks for all the feedback,
dave
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]