On quarta-feira, 7 de agosto de 2013 23:57:01, André Pönitz wrote: > On Wed, Aug 07, 2013 at 07:29:03PM +0000, 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
