[Development] Lar's QtCore 6 talk
https://www.youtube.com/watch?v=cHrrR3KhvUk
Thanks for the insight into what is coming up. I had a minor panic attack
though, which seemed to be shared with the first person to ask a question. If
the property bindings are lazy evaluated, then all my QML code will be broken.
I actively exploit the existing binding behavior of immediately evaluating
dependent bindings. I hope I am misunderstanding this, but I think this should
continue to be the behavior. I also I don't want to have to choose or specify.
However there may happy automatic middle ground. If the bindings are a terminal
leaf node, then they can be lazy evaluated. However any binding that is in the
middle of a binding chain must be immediately evaluated. I think this will
satisfy everyone.
Given:
Item { id: item; property int x2: parent.x*2 }
If x2 is not used anywhere, it can be lazy evaluated. But the moment there is a
onX2Changed or Item { x: item.x2 } then it must be immediately evaluated. For
something like QML Items and x it is probably not that interesting of an
example.
But let's now assume there is QObject-derived class bing used in the QML engine
and it declares property x which is not required to be immediately updated,
then as long as nothing is connected to the xChanged signal, then all those
updates can be deferred[1]. But the moment something does connect to it, then
it can no longer be lazy-evaluated.
I don't know if this is what Lars meant? But I think it could work without
giving me panic attacks ;-)
[1] If you need a less abstract example, think of a QObject-derived class that
processes video frames and uses OpenCV to find a target, and it emits the x,y
position of the target. If nothing is connected x() never needs to be
evaluated, but if I connect a CrossHair Item and bind to the x() and y()
properties, then the binding has to be evaluated immediately to update the
position in the UI.
I do have another concern that perhaps the lazy bindings might make it harder
to find binding loops?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QUtf8String{, View}
> > QUtf8StringIterator can be easily added to extract Unicode codepoints from > the UTF-8 string like QStringIterator exists for the same in UTF-16. > I have discovered QStringIterator in KDAB blog, it is nice, thanks! A QUtf8StringIterator would boost Qt utf8 support like easily splitting/filtering a QByteArray based on QChar category. I agree though that it is not really useful for IO/networking code and much more on QString. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QUtf8String{, View}
On 5/16/20 6:16 PM, Thiago Macieira wrote:
That opens a philosophical question. In:
QString s = u"a a\u0301"; // U+0301 COMBINING ACUTE ACCENT
s.replace('a', 'b');
Should we now have a b with accent? (b́)
It's not philosophical at all, it's a defining question: at which level
does QString operate? It does not operate at the EGC level, it operates
at the UTF-16 level. (Proof: s.size() above is 4). Hence, the replace()
above is merely replacing 0x0061 with 0x0062 in the char16_t-like storage.
My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QUtf8String{, View}
On 15/05/2020 14.31, Thiago Macieira wrote: > Python's bstr still behaves string-like and has methods like > QByteArray::indexOf(const char *). QVector has no such methods. > > But since we do have QListSpecialMethods, we can add inject them into > QVector too. Right; I was assuming that would happen for e.g. decoding. I think 'block of memory' type functions also make sense, for example, startsWith. Byte arrays are unique in that *sequences* of elements often have meaning, which is not often the case for other sorts of arrays. It's quite reasonable to ask if a byte array starts with 0xDE, 0xAD, 0xBE, 0xEF (which is not text!) or to search for such sequences. Slicing (left, mid, right) are also useful, though those are probably useful for *any* array. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QUtf8String{, View}
I facing a discussion like this every couple of months ;)
Yes, we should have a b with accent, cause it is exactly what the
programmer asked QString for; it is not our fault if b with accent is not
what he meant to get after replace.
QString (like any other tool) must not be used blindly or with zero
knowledge about what it operates on and what the expected result is.
s.length() - is not about amount of characters in the string; s.at(i) -
does not return the i'th character in the string; and surely
QUtf(8|32)String.replace('a', 'b') won't behave any "better" (I mean there
won't be any magic behind the scenes that would save some idiot from
writing some dumb code).
Regards,
Konstantin
сб, 16 мая 2020 г. в 19:17, Thiago Macieira :
> On sábado, 16 de maio de 2020 08:52:19 PDT Arnaud Clère wrote:
> > Regarding the relevance of a QUtf8String, I feel like it would not be so
> > useful unless it allows to view its content as QChar instead of char (or
> > char8_t) since handling multibyte characters is so error prone. At least
> a
> > QChar handles most unicode characters as single entities...
>
> QUtf8StringIterator can be easily added to extract Unicode codepoints from
> the
> UTF-8 string like QStringIterator exists for the same in UTF-16.
>
> Usually, though, this means you're doing something wrong. Grapheme
> clusters
> can span multiple codepoints. Unless you're doing text shaping, you
> probably
> don't need them. And if you don't need them, why do you care about
> codepoints
> in the first place?
>
> That opens a philosophical question. In:
>
> QString s = u"a a\u0301"; // U+0301 COMBINING ACUTE ACCENT
> s.replace('a', 'b');
>
> Should we now have a b with accent? (b́)
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QUtf8String{, View}
On sábado, 16 de maio de 2020 08:52:19 PDT Arnaud Clère wrote:
> Regarding the relevance of a QUtf8String, I feel like it would not be so
> useful unless it allows to view its content as QChar instead of char (or
> char8_t) since handling multibyte characters is so error prone. At least a
> QChar handles most unicode characters as single entities...
QUtf8StringIterator can be easily added to extract Unicode codepoints from the
UTF-8 string like QStringIterator exists for the same in UTF-16.
Usually, though, this means you're doing something wrong. Grapheme clusters
can span multiple codepoints. Unless you're doing text shaping, you probably
don't need them. And if you don't need them, why do you care about codepoints
in the first place?
That opens a philosophical question. In:
QString s = u"a a\u0301"; // U+0301 COMBINING ACUTE ACCENT
s.replace('a', 'b');
Should we now have a b with accent? (b́)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QUtf8String{, View}
Il 16/05/20 17:52, Arnaud Clère ha scritto: Regarding the relevance of a QUtf8String, I feel like it would not be so useful unless it allows to view its content as QChar instead of char (or char8_t) since handling multibyte characters is so error prone. At least a QChar handles most unicode characters as single entities... => QStringIterator. Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QUtf8String{, View}
Hi all,
As a user, I am happy with simplifications regarding string handling and I
think the choice of utf16 for QString makes sense for most code except for
file/networking code.
I was once concerned about not being able to distinguish between QByteArray
containing utf8 text and QByteArray containing other data. But now, I am
using the following pattern to distinguish between both in the *very rare
places* where I need to have a different overload for each, or want to
provide a separate type with strong guarantees about a QByteArray content:
struct Utf8 { QByteArray utf8; }
This pattern obviously works for "tagging" any kind of data. See
https://www.fluentcpp.com/2018/04/06/strong-types-by-struct/ for a
presentation of this pattern.
Regarding the relevance of a QUtf8String, I feel like it would not be so
useful unless it allows to view its content as QChar instead of char (or
char8_t) since handling multibyte characters is so error prone. At least a
QChar handles most unicode characters as single entities...
Cheers,
Arnaud
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
