Transaction register question

[Geert Janssens]

[ 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.

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.

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.