Thanks Geert for the response and insightful help. With your response, I will
see what I can do about maybe fixing some of the simpler aspects of this dialog
first as it seems to be pretty straight forward. I'll stay away from the more
radical discussion of removing the option entirely for now until I have a
better understanding of how difficult it might be to extend it first.
Thanks for the help from all the developers as I try to take on a new hobby.
Matt
On Thursday, November 28, 2019, 2:51:10 AM CST, Geert Janssens
wrote:
Hi Matthew,
Thanks for looking into this. The bug has been around for too long already...
Here's my view on it:
In theory we could indeed use a different widget for cases where we are asking
for a simple number. The big benefit of the GNCAmountEdit widget on the other
hand is that it allows the user to do in-place calculations.
Like in the loan calculator example I could enter the number of payment
periods as 7*12 rather than 84 when I know the loan will be for 7 years. Or I
could enter the outstanding periods as (7*12 - 3*12+9), not a calculation I
could quickly do in my head. So the GNCAmountEdit offers the convenience of
not needing to get an external calculator and I think that has value.
The real issue is - as you have discovered - the decimal point adjustment
happens unconditionally where it should be more tightly controlled.
Personally I think users would expect it to be applied to currency amounts
only. So with auto-decimal point set to two and you enter 1000, you really
mean $10.00
For integer values like number of payment periods this clearly doesn't make
sense. This is also what the implementation of xaccParseAmount suggests: it
will only apply auto decimal point corrections when the string to be parsed is
marked as a monetary type. This function is called by the expression parser to
evaluate the amount, but the expression parser doesn't differentiate and will
always assume monetary values.
So of the two suggestions you make I think extending GNCAmountEntry and the
expression parser to take the amount type into account is the best.
However a more radical approach may be to first evaluate whether we want to
keep the auto decimal point functionality at all. So before you spend the
effort it may be worthwhile to check with our user base who is really using
this function and how much of a loss it would be if we simply removed it.
Personally I don't benefit from this feature. It requires more typing and
mental overhead in most of my data entries as I have plenty of values that are
integer. Others may have different experiences.
As a side note while testing I found several minor usability bugs with this:
in many cases I can enter values or calculations, but they won't be evaluated
until I leave the window. For example the loan calculator. I can enter a value
like 10 in the amount field. When leaving the field I'd expect it to
change to 1000.00 when auto decimal point is set to 2. It doesn't change
however until after I click on the calculate button. That's pretty confusing.
The same goes for the period field in the loan assistant. Only when switching
to the next page and back, the field will be interpreted. Just to say there's
plenty of room for improvement here.
Regards,
Geert
Op zondag 24 november 2019 20:45:55 CET schreef Matthew Forbis via gnucash-
devel:
> Hi developers,
>
> As a foray into fixing bugs, this one looked simple to tackle. Here is the
> link for easy access: https://bugs.gnucash.org/show_bug.cgi?id=330930
>
> As a summary, when having auto decimal point enabled, certain fields are
> treated as still having the auto decimal point enabled, such as number of
> payment periods on the loan assistant. As I looked into this, these
> dialogs and a few others use a GNCAmountEntry which goes through the
> expression parser and there is no way to turn off the auto decimal point
> when setting up the form, so anytime there is a GNCAmountEntry, it forces
> decimal places into the number. I guess I see a few possible ways to go
> about fixing it, but I'm not sure which would be considered correct. 1)
> Pass parameters back up so you can have the GNCAmountEntry tell the
> expression parser to not do auto decimal point, or 2) Change it to a
> different type of entry field (such as GTKEntry) that would not parse
> expressions, but would also not enter in decimal points, or 3) I missed
> some option somewhere to tell a GNCAmountEntry to ignore the decimal
> points, but I certianly can't figure it out.
>
> Is there a preference from the core devs as to which would be considered the
> "correct" way. I also see when researching this, it probably also applies
> to other places too that use GNCAmountEntry. For instance, the tax table
> editor has a Percent entry for rate that I wouldn't think makes sense to
> necessarily add auto decimal places when you are already entering in as a
> percent and not a decimal.
