Re: Use locale grouping to format numbers (#1781)
VZ
vadz left a comment (wxWidgets/wxWidgets#1781)This PR has been in "work needed" state for more than a year and will be closed soon. Please update it, e.g. by commenting here, if anybody intends to resume working on it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#1781)This is actually very close to being mergeable, I'll try to finish and merge it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#1781)BTW, @utelle: I don't think this is directly related to the currency-related changes you're working on, but wanted to let you know about this PR just in case it could be useful somehow.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
utelle left a comment (wxWidgets/wxWidgets#1781)I don't think this is directly related to the currency-related changes you're working on, but wanted to let you know about this PR just in case it could be useful somehow.
@vadz: Thanks for informing me. Actually, this PR is somewhat related to my PR. Looking at the scrrenshot in the first comment the example is about budget values - clearly currency related.
Windows, for example, provides settings for formatting 2 kinds of numerical values:
- ordinary values
- monetary values
For both the decimal separator, the grouping, the grouping separator, and the number of decimal digits can be queried from the operating system.
Actually, this is true for all major platforms wxWidgets supports: Windows, Linux/Unix, macOS.
However, this PR differentiates between the kinds of values only for Linux/Unix using the categories wxLOCALE_CAT_NUMBER and wxLOCALE_CAT_MONEY. It does not for Windows and macOS, although those platforms also provide different attributes depending on the category.
The parameters relevant for number formatting are retrieved here via GetInfo.
You urged me to introduce a separate method for retrieving currency information. From my point of view, it would make sense to enhance the new method by providing in the returned structure not only the currency symbol, currency code, and number of decimal digits (BTW, an attribute not retrieved for ordinary numerical values), but also the other attributes relevant for formatting monetary values.
In addition, it could make sense to provide a similar convenience method for retrieving the attributes for formatting ordinary numbers.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#1781)Grouping is valuable both with monetary and other values (e.g. population count), so it shouldn't be currency-specific, but it is indeed somewhat related.
I was mostly thinking that perhaps we need a higher level API than GetInfo() for this information as well, as the string representation is not really obvious to work with. But at least here the main (only?) use of it is to pass it back to wxNumberFormatter, so we could live with an opaque string too.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ulrich Telle
utelle left a comment (wxWidgets/wxWidgets#1781)Grouping is valuable both with monetary and other values (e.g. population count), so it shouldn't be currency-specific, but it is indeed somewhat related.
Well, IMHO the number formatting should be able to use both sets of parameters - that for ordinary values and that for monetary values. The parameter sets may be identical, but maybe not, since the user can configure them independently.
I was mostly thinking that perhaps we need a higher level API than
GetInfo()for this information as well, as the string representation is not really obvious to work with.
Under Windows and Linux/Unix the system API is based on equivalents to GetInfo() and return the values as strings. Only macOS delegates formatting related parameter to the number formatter object.
I guess the majority of users come from the Windows or Linux world, so using the GetInfo() method in wxWidgets is close to the system API.
But at least here the main (only?) use of it is to pass it back to
wxNumberFormatter, so we could live with an opaque string too.
Well, I'm not in favor of an opaque string. Either allow separate access to each parameter via GetInfo(), or introduce convenience methods to retrieve all related parameters in one go, or both.
If we introduce convenience methods which return a structure with all relevant parameters (that could then be consumed by the number formatter), this would allow the user to easily manipulate the parameters to his own preferences or requirements.
@vadz: What I need to know is which way you want to go:
- all access through
GetInfo(), no convenience methods - only additional convenience methods for number formatting (for ordinary and monetary values)
- 1. and 2.
- something else
Maybe it makes sense to allow accessing the currency symbol and currency code independently of the number formatting.
Let me know your preferences, so that I can continue to work on my PR.
P.S. This PR implements the feature within wxLocale. IMHO it would be preferrable to do it in wxUILocale.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#1781)Grouping is valuable both with monetary and other values (e.g. population count), so it shouldn't be currency-specific, but it is indeed somewhat related.
Well, IMHO the number formatting should be able to use both sets of parameters - that for ordinary values and that for monetary values. The parameter sets may be identical, but maybe not, since the user can configure them independently.
Yes, I agree (even if I think that in practice they will always be the same).
I guess the majority of users come from the Windows or Linux world, so using the
GetInfo()method in wxWidgets is close to the system API.
Let me repeat that I don't think basing wx API on underlying platform-specific API is a good design principle. It may make sense to follow them if we can't do anything better, but quite often we can (because we're not working under the same constraints as OS API designers).
But at least here the main (only?) use of it is to pass it back to
wxNumberFormatter, so we could live with an opaque string too.Well, I'm not in favor of an opaque string. Either allow separate access to each parameter via
GetInfo(), or introduce convenience methods to retrieve all related parameters in one go, or both.
I don't like string-based API, but it's the simplest one. Using higher level API would be better IMO.
@vadz: What I need to know is which way you want to go:
1. all access through `GetInfo()`, no convenience methods 2. only additional convenience methods for number formatting (for ordinary and monetary values) 3. _1._ **and** _2._ 4. something else
I am for (2). I.e. if we add higher level functions I don't see any point in also allowing access to this via GetInfo(), which will be used just for the simple things.
Maybe it makes sense to allow accessing the currency symbol and currency code independently of the number formatting.
Why not. Those fit GetInfo() well enough.
Let me know your preferences, so that I can continue to work on my PR.
Note that they are just preferences and are not based on any deep analysis of the problem (I just don't have time for it...), so if you have strong arguments in favour of some other solution, please let me know.
P.S. This PR implements the feature within
wxLocale. IMHO it would be preferrable to do it inwxUILocale.
Yes, I agree with this too. This PR is pretty old, I don't even know if wxUILocale existed when it was originally written.
Thanks!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.