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

Fri Oct 16 01:32:26 CEST 2015

On October 16, 2015 00:20:22 Marc Mutz <marc.mutz at kdab.com> wrote:

> Guys, this thread is for QStringView. Could we keep it on-topic, please? There 
> are more than enough bits floating around to create your own threads (with a 
> tip of the hat to Kai).
>

Good argument but actually I think before we introduce something new to our string handling we should test it out. Why not add it Qt creator like André proposed and see how it works. 

I think we don't want to end with something like our model view system or QtControls. Lets test it before we make changes. 

I think too we should embrace the standard library more and don't replicate their features. 

A better process to add features would be helpful too.  First they should be experimental so we can change them easily. Second we should be better at removing features. If we do not remove things we will getting slower and slower to add new interesting stuff. It is hard to find the balance but if you are too conservative you will getting slowly less used. We tried to be very innovative with Qml and we learned much about it. 

So the question is how can we maximize the usefulness of Qt with our man power. Is replicating the standard library really helping? 

>
> On Thursday 15 October 2015 23:02:09 Bubke Marco wrote:
>> 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. _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
> -- 
> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sent from cellphone 