On October 15, 2015 00:27:45 Thiago Macieira <thiago.macie...@intel.com> wrote:
> On Wednesday 14 October 2015 21:51:23 Bubke Marco wrote:
>> On October 14, 2015 23:10:26 Thiago Macieira <thiago.macie...@intel.com>
> wrote:
>> > Do it on your own. You just said that ICU has the function you want, so
>> > use
>> > it.
>>
>> So Qt is always shipping with ICU?
>
> It can be disabled on Windows. On OS X there's no point since it's part of
> the
> system. On Linux, if you disable it, you're going to have some other features
> reduced, so don't disable it.
>
>> > Qt does not have to provide a comparator that operates on something other
>> > than its native string type.
>>
>> Isn't Qt a framework to help developers? Sorry your argumentation is sounds
>> not very empirical.
>
> Yes, it is. But Qt's goal is not to support every single use-case and corner-
> case out there. Qt should make 90% easy and 9% possible. That means there's a
> 1% of the realm of possibilities that Qt does not address. If your use-case
> calls into this group, use the fact that Qt is native code and just call
> other
> libraries.
Actually I think Qt is not main developing library people use. It is there to
make the boring stuff easy, to hide the different interfaces between different
platforms. That is why many people use Qt, they want to have a GUI but don't
want to invest to much time in it. The interesting stuff which is
differentiating you from others is mostly home grown in connection with much
more specialized libraries. And this libraries are much more important to the
users. So we should support them, their interfaces and not force our interfaces
on them. How many users use the standard library too, especially the new
features, why don't we support them not much better. Why do we have to reinvent
the wheel again and again. I know binary compatibility is important for you but
is it really that important outside of the special linux distribution cocoon.
Is it important under Windows, is it important under Mac, is it important
under embedded Linux? I think the advantages are smaller than the
drawbacks.
> That's one of the two main advantages of native code. There's no sandbox to
> escape from.
>
> Qt already supports doing locale-aware comparison. We even have a class for
> it, so it can be done efficiently: QCollator and it supports our native
> string
> type (QString).
Do you like to live on a native island?
> Providing extra support for a character encoding that is not what QString
> uses
> falls in that 1%. Just use ICU.
You arguments sounds very tautological. Because it is unimportant we don't have
it a string class for it. It is unimportant because QString is not supporting
it.
I know you love plationian argumentation but it would be much more effective if
you would try to get in the context of other and understand their arguments in
their context. Showing in your own context that their arguments "makes no
sense" is not very useful.
>> Lets describe an example. I send the QTextDocument content to an library
>> which expect utf8 content and gives me back positions. This gets
>> interesting if you use non ASCII signs. Actually the new clang code model
>> works that way.
>
> That example shows how UTF-16 is better. See above on seekability of UTF-16
> vs
> UTF-8.
>
> The solution for this is to fix the library to accept UTF-16. When we were
> doing Qt 5.0, we needed PCRE to support UTF-16. Their developers were very
> welcoming and wrote the version that supports UTF-16, so Qt does not need to
> reallocate.
You have ever heard of Pippi Longstocking: "Widdiwiddiwitt, we make the world
like we wish it should be. " or how it is translated to english. You really
think that you can force other larger projects to use utf16 instead of utf8 if
it has disadvantages for them.
And the PCRE is now supporting both at runtime? Especially for large text it
would be very helpful if you don't need to convert them to QString before you
use regular expressions on it.
>> > Even if we provide UTF-8 support classes, those will not propagate to the
>> > GUI. Forget it.
>>
>> What about compressing UTF 16 like python is doing it for UTF 32. If you are
>> only using ascii you set a flag and you can remove all that useless zeros.
>> It would be have implications for data() but maybe we should not provide
>> access to the internal representation. If you use UTF 32 as a base you
>> don't need anymore surrogates.
>
> That's what Lars called a "hybrid solution" and vetoed. I second that.
>
> Way too much code would break if we did that because we allow people access
> to
> the data pointer in QString and to iterate directly (std::{,w,u16}string
> don't
> allow that, which makes parsing them actually a lot more cumbersome).
I don't see the disadvantage if you have special iterators. That is the power
of iterators and with the new features of C++ they get really useful. But
anyway, I don't say that we have to change everything. The last time we did
that we broke our event system which is still not working like it was before we
introduced QWindow. I think we should have an evolutionary process to adapt
to the changing environment and not try to reiterate what was successful in
the past.
And we should memory why we have done things and if that decision would be the
same today. And in the end we have to decide if it is worth to change that
decision again.
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
