[ 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
[email protected]
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
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
