Register-2 Data Entry

Thu Sep 12 12:34:20 EDT 2013

On 9/12/2013 9:08 AM, David Carlson wrote:
> On 9/12/2013 5:35 AM, David Carlson wrote:
>> On 9/12/2013 3:37 AM, Graham Menhennitt wrote:
>>> On 11/08/2013 04:34, John Ralls wrote:
>>>> I guess I should have done this much sooner, but I tried using Register2. Some issues:
>>>>
>>>> * The number field is reproduced when copying a memorized transaction if it's left blank before tabbing out of the description field. 
>>>>
>>>> * Return doesn't commit the transaction and move to a new empty one, it toggles the edit state on the current field. Tabbing off the end of the transaction, rather than opening a new empty transaction, takes one to the first entry in the account. Arrow-down doesn't do anything. I was able to commit the transaction by arrowing up, which created a new empty transaction that I could arrow down to, but of course the cursor isn't in the date column where I need to start, it's in whatever column I was last in in the previous transaction. I have to back-tab to the date field to start entering the next transaction.
>>>>
>>>> *  Because Enter/Return doesn't move the cursor, the "Enter moves to blank transaction" preference has no effect.
>>>>
>>>> * The new blank transaction shows today's date rather than the last date used. 
>>>>
>>>> * Delete Split doesn't work on a new, unsaved transaction [1]. Attempting to empty the transfer account on a split crashed Gnucash [2].
>>>>
>>>> * Deleting the value in a split's deposit or withdrawal column fails: the value is restored when one tabs out. One must enter 0 which is removed when one tabs out. It's not necessarily a bug, but it's different from Register-1 and we need to be aware of it.
>>>>
>>>> * One must click on a field or press Enter when starting to edit a new transaction, otherwise a search box opens when one begins typing.
>>>>
>>>> * Completion of the rest of a transaction after autocompletion fails intermittently.
>>>>
>>>> All of these problems occur on both OSX with Gtk-2.24.20 and Fedora-18 with Gtk-2.24.16.
>>>>
>>> I've just installed 2.5.5 on FreeBSD 9-stable using Gtk 2.24.19. In
>>> addition to John's comments:
>>> * The default column widths are bad. The date column is too narrow to
>>> show the whole date. All of the value columns (Increment, Decrement,
>>> Balance) are too narrow to show the first digit. The Number column is
>>> very wide.
>>> * The left and right scroll bars are disastrous. Get rid of the right
>>> one and put the left one on the right like any normal program.
>>> * When entering a transaction is complete, the register sometimes
>>> scrolls back to the top (of both scroll bars).
>>> Sorry to be negative, but it's just not usable in the current state.
>>>
>>> Graham
>>> _______________________________________________
>>> gnucash-devel mailing list
>>> gnucash-devel at gnucash.org
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>>
>> Are you sure that you have release 2.5.5?  In Windows release 2.5.5 is
>> back to one scrollbar but the range is limited to a group around the
>> last or currently selected transaction.  Thus to see transactions
>> further away than in the current group one must first manually and
>> repeatedly select a transaction near the end of the group to get closer
>> to the desired range.  Eventually you might get there.  I have entered a
>> bug for this.
>>
>>
>> _______________________________________________
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> I must apologize.  I totally missed the slider on the left side of the
> window.  Can I blame it on my cat sitting in front of the monitor?  I
> guess that is pretty weak.  Sorry.
>
> David C
>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

The cat was trying to get me to feed her.

Anyway, in my Windows 7 version column widths are weird as well but they
seem to default to slightly too wide for the window (because the second
slider is not accounted for?).  If I try adjusting them they look like
they do not respect the right edge like they do in release 2.4.13 and
earlier.  If it can be made to work correctly, it may be better than the
old register.  I have a fairly high resolution (CRT) monitor on my
primary computer so I can keep the window large enough to see most of
the text most of the time.

I usually use the Auto-split Ledger view and I find that sometimes some
transactions get inadvertently expanded as the focus shifts and they
stay expanded when the screen settles, leaving two transactions expanded
on the screen.  then to collapse the one that does not have the focus it
is necessary to focus on it and move the focus away.  I have not
reported this yet in Bugzilla, as I thought it might get fixed when the
bug regarding when the edit is accepted and the edit session is closed
the focus moves to the next transaction in the register instead of
staying with the last edited transaction is fixed.  I have reported that
bug in Bugzilla under https://bugzilla.gnome.org/show_bug.cgi?id=707903.

This is the first version that is working well enough for me to stay
with long enough to test and find more of the rough edges.  I believe
that progress is being made, so, impatient as I am, I will try to give
the developers time to get it right.

David C

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xDC7C8BF3.asc
Type: application/pgp-keys
Size: 1729 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20130912/b391919d/attachment.bin>