Transaction register question

David Carlson carlson.dl at sbcglobal.net
Sat Aug 17 14:54:19 EDT 2013


On 8/17/2013 12:05 PM, Geert Janssens wrote:
> [ Moving this to devel, as it's not really a user question anymore]
>
> On 17-08-13 15:53, David Carlson wrote:
>>
>>
>> Hi Robert, interested users and developers,
>>
>> I think that development of register2 or some other replacement for the
>> current method of transaction entry is crucial to the continued success
>> of GnuCash.  That is not because the current register is 'bad', but
>> because emulation of the current register scheme places unnecessary
>> burdens on developers who seem to be trying to (sorry, folks) fit a
>> square peg in a rounds hole.
>>
>> Generally, database interface programs use 'forms' to input data.  A
>> 'form' can easily be designed to help the user complete his task
>> efficiently and go on to the next task.  When the 'form' is separated
>> from the 'table' that shows the register, it becomes possible to
>> optimize one without compromising the other.  That is one of the great
>> features of a database interface.
>>
>> I think this issue needs more discussion and more alternative ideas
>> considered.
>>
>> I propose that the transaction editing be done in a 'form' that is
>> separate from the register window.  That allows the register performance
>> to be optimized separately from the editing process.
> Hi David,
>
> Thank you for your suggestion. But I have to disagree.
>
> The performance issue we are currently facing is not in the data
> loading end. The data is loaded completely in memory when GnuCash
> starts, which makes it even more quickly to work with than a true
> database backend. There are other motivations to switch to a database
> backend, but they are not relevant to the performance issue we have
> now in the register.
>
> The current bottleneck is purely in the widget that has to display the
> transaction splits in the register (a GtkTreeView widget). If the list
> of splits is too long, this widget gets slow. I don't know the exact
> cause as I haven't investigated this myself. But I did use google to
> check for performance issues with a GtkTreeView widget and that does
> suggest several possible causes and solutions. It will be a matter of
> finding the exact cause and use the appropriate solution for it. I
> actually think that what Robert has done so far is already largely in
> the right direction: load only a subset of splits at all times, namely
> those that are visible and a few around it. The only thing still
> needed is to make the standard scrollbar aware of the complete range
> of splits regardless, so it can be used to scroll all the way through
> all splits. This logic is now in a separate scrollbar, and that's what
> is superfluous in my opinion. The same can probably be done in the
> main scrollbar.
>
I intentionally avoided making any assertions about specific details.  I
was stating that separating transaction editing from register viewing
gives the developers an opportunity to optimize both activities.

> In addition to this, I don't think using a from would do anything to
> improve performance. The performance hit is in trying to display the
> splits. This would still have to be done even if you want to use a
> separate form. If not, we would lose a lot in user-data interaction. I
> perceive it as a big benefit to be able to have the neighbouring
> splits around when entering new data. This context gives very useful
> feedback like did I enter this transaction already, is the balance
> what I expect after input,...
>
> I can be wrong, but from what I see, I don't think a form will help me
> work more efficient. And by the way, I have used several accounting
> programs that do use forms. As a heavy keyboard user I have always
> felt that slow me down.
>
Forms can and should contain navigation shortcuts.  They also do not
need to be in a window that hides everything else in the display.  The
fact that many sub-optimal forms exist is not an excuse to assert that
optimized use of forms could not be better.

In fact, I would consider the existing transaction editing scheme to be
a rather sophisticated form of sorts that (unfortunately, in my opinion)
is constrained (shoehorned?) to fit completely into the register view
with no room for developments that could enhance both the developer's
job and ultimately, the user experience.

GnuCash is blessed with several really good developers.  I am sure that
you can make this good software better.

David C

> As always this is just my view on the issue.
>
> Geert
>>
>> Thanks.
>>
>> David C
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>

-------------- 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/20130817/91216a3e/attachment.bin>


More information about the gnucash-devel mailing list