[Development] ICU decision?

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130807/7bf2918f/attachment.sig>