[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Bubke Marco]

On October 15, 2015 00:27:45 Thiago Macieira <thiago.macieira at intel.com> wrote:

> On Wednesday 14 October 2015 21:51:23 Bubke Marco wrote:
>> On October 14, 2015 23:10:26 Thiago Macieira <thiago.macieira at 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.