[GNC-dev] Bug 330930

[Matthew Forbis]

 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 <geert.gnucash at kobaltwit.be> 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 100000 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.
> 
> If someone can provide direction, I'll make an attempt at fix and submit a
> pull request for review.
> 
> Thanks,
> Matt
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel