Re: [Development] ICU decision?
...and LCMapStringEx can be used for generating sort keys. However, there seems to be some things that need to be changed/removed from QCollator, such as the index character feature (I don't recall the exact function name). Also, the case sensitivity enum in QCollator can configure sorting to have (IIRC) upper first, lower first, or the default. IIRC CompareStringEx can only use the default or ignore case. (However, I suspect upper/lower first might be possible to do with a qStableSort and QChar::isUpper()) There might be other small differences too, but at least it seems that the major feature can be done without ICU. Jan Arve -- Sendt fra min Nokia N9 07.08.13 21:42 skrev Knoll Lars: On 8/7/13 9:29 PM, Knoll Lars lars.kn...@digia.commailto:lars.kn...@digia.com wrote: On 8/7/13 5:21 PM, Thiago Macieira lars.kn...@digia.commailto:lars.kn...@digia.com wrote: On quarta-feira, 7 de agosto de 2013 08:00:27, Knoll Lars wrote: The only degraded experience I would accept is full functionality for C and system locales. It would be acceptable for the classes to not have any support for other locales, like trying to get number formatting for Azerbaijani on a German Windows. That would be acceptable for now IMO. The third option we discussed: * Require ICU, but have a 'fake' ICU lib available to deploy with Qt on Windows/Android for those who want to ship with minimal i18n support. Add some support to our packaging to choose which ICU lib to take. Thanks for the suggestions. If we go straight for option 3, can we get this fake library done in the next couple of months? It can be done, but the question would be who has the time. If we go for option 2 first, we'd have to investigate if there is any system API to provide QCollator support for the system locale. Does anyone know of such a thing? Looks like the CompareString/CompareStringEx methods should allow us to implement collation on Windows without ICU. Cheers, Lars I'm sorry, but I will block any task on making QCollator public until we know that we can have a working QtCore without an ICU dependency. But we can't (or rather should't) go for a least common denominator approach neither. A public QCollator won't mean a non working QtCore even if it has to fall back to unicode sort order on some OSes. And with ICU in place it'll all work fine. I agree that ICU is a large dependency, but we can't simply leave out important features forever because of this neither. and collation is something we have been lacking for far too long. Cheers, Lars ___ Development mailing list lars.kn...@digia.commailto:lars.kn...@digia.com http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list lars.kn...@digia.commailto:lars.kn...@digia.com http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ICU decision?
On Wed, Aug 07, 2013 at 07:29:03PM +, Knoll Lars wrote: I agree that ICU is a large dependency, but we can't simply leave out important features forever because of this neither. and collation is something we have been lacking for far too long. How important is it actually? How many people need full ICU _in Qt_? How many people are harmed by having a 20 MB dependency they don't use? The questions are serious. I don't have an answer. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ICU decision?
On quarta-feira, 7 de agosto de 2013 23:57:01, André Pönitz wrote: On Wed, Aug 07, 2013 at 07:29:03PM +, Knoll Lars wrote: I agree that ICU is a large dependency, but we can't simply leave out important features forever because of this neither. and collation is something we have been lacking for far too long. How important is it actually? That depends. There are two scenarios: Scenario 1: ICU is used in addition to the platform API, for what the platform API doesn't provide. In this case, ICU is not that important: we'd get locale information from locales the user isn't running, calendaring for calendars the user doesn't use, codecs that aren't the system codec, and collation support, which is not public API yet. We already have our own Unicode tables in qstring right now. Scenario 2: ICU is the main API, not using the platform API. In this case, then ICU is mightily important. Without it, we can't open a file, we can't format a date, time or number. If we replace our unicode tables with ICU, without ICU we wouldn't be able to uppercase a string. How many people need full ICU _in Qt_? Scenario 1: not many. The full ICU would only be necessary for applications that need to use more functionality than the system and C locales require. Scenario 2: everyone. We can't predict what locales the end user is going to run the application in, so we can't provide a stripped down version on our own. This becomes a downstream problem: that of the application developer, to choose which end user locales they're going to support. If they can't make a decision, then they need all locales. How many people are harmed by having a 20 MB dependency they don't use? Scenario 1: a lot. Scenario 2: zero. (everyone uses it, therefore zero people don't use it) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ICU decision?
On quinta-feira, 8 de agosto de 2013 00:43:20, John Layt wrote: * Spellout Style, e.g ten * Ordinal Style, e.g. 10th - ICU only * Currency Name Style, e.g. 10 US Dollars - ICU only * Decimal Pattern - user defined pattern and symbols * Padding - alter pad char, pad width, pad position * Rounding - change mode and increment * Currency format using ISO currency code - pass the ISO code and correct symbol and decimal places are used * Choice of defining min/max int/frac, or significant digits * Lenient / Strict parsing modes The spellout, ordinal, and currency features are things KDE is particularly interested in. For date/time, it only looks to be full, medium, and relative date formats that Win32 doesn't provide, all of which KDE wants. Can you list the above in the form of Qt API? I'm not sure we have most of what you listed above in our API today and we don't have any plans of adding them... I understand that there is a lot of features that KDE wants, and under other circumstances I wouldn't hesitate to give, but at this point I need to weigh the cost: if giving this API will require a major dependency we're not prepared to give. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
