Calculated Waypoints refactoring: can we remove non-plain calculator formats?

Describe your problem!

I analyzed the calculated waypoint code in order to find a good way to introduce global variables (see #11520). Current implementation however is very very complex and I feel myself unable to introduce the concept without doing a large refactoring in this area.

Large complexity parts are introduced by the “button per digit” logic of calculated formats other than “Plain”. Here the user can only decide for each digit place whether it is a single-digit, a single-letter-var (no reusages of same var possible though) or a “blank”. This can look then e.g. like this:

To give you a feeling about the complexity this creates in code: the input above is then saved to the database as a “state object” like the following (and there’s lots of code decicated to interpret, save and load this stuff):

{"format":2,"plainLat":"N 53° 33.065'","plainLon":"E 009° 59.621'","latHemisphere":78,"lonHemisphere":69,"buttons":[{"type":0,"inputVal":53,"autoChar":45,"customChar":0},{"type":0,"inputVal":51,"autoChar":45,"customChar":0},{"type":1,"inputVal":51,"autoChar":65,"customChar":0},{"type":0,"inputVal":51,"autoChar":66,"customChar":0},{"type":0,"inputVal":0,"autoChar":66,"customChar":0},{"type":0,"inputVal":0,"autoChar":66,"customChar":0},{"type":0,"inputVal":0,"autoChar":66,"customChar":0},{"type":0,"inputVal":0,"autoChar":66,"customChar":0},{"type":0,"inputVal":48,"autoChar":66,"customChar":0},{"type":0,"inputVal":54,"autoChar":66,"customChar":0},{"type":0,"inputVal":53,"autoChar":66,"customChar":0},{"type":0,"inputVal":48,"autoChar":66,"customChar":0},{"type":0,"inputVal":48,"autoChar":66,"customChar":0},{"type":0,"inputVal":57,"autoChar":66,"customChar":0},{"type":0,"inputVal":53,"autoChar":66,"customChar":0},{"type":1,"inputVal":57,"autoChar":66,"customChar":0},{"type":0,"inputVal":0,"autoChar":67,"customChar":0},{"type":0,"inputVal":0,"autoChar":67,"customChar":0},{"type":0,"inputVal":0,"autoChar":67,"customChar":0},{"type":0,"inputVal":0,"autoChar":67,"customChar":0},{"type":0,"inputVal":54,"autoChar":67,"customChar":0},{"type":2,"inputVal":50,"autoChar":67,"customChar":0},{"type":0,"inputVal":49,"autoChar":67,"customChar":0}],"equations":[{"name":65,"expression":"a+b"},{"name":66,"expression":"5"}],"freeVariables":[{"name":97,"expression":"3"},{"name":98,"expression":"4"}]}

In contrast the “Plain” format produces far simpler structures and needs much less code. E.g. the following dialog:

(Although this saves an additionally large state, most parts of it are not needed for “plain” format and could be removed)

Why am I telling all of this?

Refactoring the “button-kind” for calculated coordinates is of course possible, but it will create lots of work. I am willing to invest this work, but only if there is really a user base using this! My guess would be that there is not.

So the question is:

• Is this really used in the field? As a starter, who in the c:geo development team is using this?
• can we consider to remove this from c:geo?

How to reproduce?

n/a

Actual result after these steps?

No response

Expected result after these steps?

No response

Reproducible

Yes

c:geo Version

all

System information

No response

Additional Information

No response

[Lineflyer]

I did never use the plain format as I like the assistance provided by the button format 😦

[eddiemuc]

Ok