[Development] FirstPersonCameraController Improvements
Hello everyone, I've been having problems with Qt3D's FirstPersonCameraController and I was wondering if I could help contribute to make it easier to use and more flexible. As I see it the current problems are: Fixed keymapDefault keys being inaccessible to some (I have no page up/down on my laptop keyboard)Keys used for control are not standard (WASD is used more often than pageup/down and arrow keys)Lack of sensitivity adjustment (if your scene is really big then you can't increase the movement speed to easily navigate around your scene) Do you all think that these are necessary or at least useful to fix, and if so would you mind if I contributed to add these changes? --Nova ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
On 8 Jul 2019, at 17:38, Shawn Rutledge mailto:shawn.rutle...@qt.io>> wrote: On 8 Jul 2019, at 16:24, Volker Hilsheimer mailto:volker.hilshei...@qt.io>> wrote: Hi, Executive summary: * QTest::mouseMove seems to be broken * when simulating QEvent::MouseMove events by constructing event objects, always construct them with global position The details: While trying to fix https://bugreports.qt.io/browse/QTBUG-76765 to not update the mouse cursor when the cursor-fied QGraphicsItem the mouse is on top of is disabled, I noticed the following pattern in the respective test: QTest::mouseMove(localPoint, widget); QMouseEvent event(QEvent::MouseMove, localPoint, Qt::NoButton, 0, 0); QApplication::sendEvent(widget, ); which confused me a bit. Shouldn’t QTest::mouseMove already have sent the event? Apparently not. That there is no overload that takes modifiers and keys is also strange. In the end, when running the test locally on my Mac, I never got it ot pass. What seems to happen is this: * for QWidget receivers, QTest::mouseMove just calls QCursor::setPos QCursor::setPos is not guaranteed to generate mouse events. The documentation of some overloads of that function [1] in fact explicitly advises against using that function in unit tests. Yep. Cursor support can be disabled, I think that’s one reason at least. Another is that some platforms (i.e. Wayland) don’t allow applications to set cursor position. Anyway it’s heavy-handed and slow. But tests that need to simulate mouse hover or mouse enter/exit by sending events do need to ensure that the cursor is _not_ on top of the window, to avoid getting spurious events… and that’s usually done by QCursor::setPos(); so we can’t seem to get rid of it after all. https://codereview.qt-project.org/c/qt/qtbase/+/5290 seems to have put it into its current state… it’s old. But before that was https://codereview.qt-project.org/c/qt/qtbase/+/4462 which comments out QCursor::setPos() and sends a platform event instead… at least in one case. Too bad the commit message is so sparse. I suppose there’s the usual tradeoff between the philosophy that real platform testing should involve real platform events (in this case: if you really move the system mouse cursor, then the window system will hopefully send a mouse move event to the window, and aren’t you making the test more realistic that way?) vs. the practical tendency for that kind of testing to be less reliable, with unpredictable latency, needing to use QTRY_ much more because you don’t know how long to wait until the window system reacts, etc. Thanks for digging in the history. This explains why targeting a QWindow with mouseMove synthesises an event; or at least it shows when it started doing that... If we need to have better tests that confirm that platform events are correctly received by Qt, translated into QEvents, and then routed to the correct receiver, then let’s have that. But we need to be able to stand on top of this guarantee when we test the internal logic of widgets. I need to be able to rely on basic event handling being done correctly; or in fact, I shouldn’t care when I test my unit. QTestlib is primarily a unit testing framework after all, not an integration or UI testing framework. The assumption that I can only test QGraphicsView’s hit testing logic by sending an event thought the operating system and the event system has nothing philosophical about it :) We use an object oriented language to build Qt, with hopefully well encapsulated internal states that don’t magically change randomly. If we need make sure that Qt doesn't produce any events that we don’t want, wouldn’t it be easier to disable/filter out those events (ie all input events with QEvent::spontaneous) programmatically, than to rely on QCursor::setPos? Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Oslo, we have a problem [char8_t]
No, what I’ve actually meant - is it possible to have a free function that takes some string view (QLatin1StringView?) and operates on that view instead of allocating a new string. I’m asking because I’m kinda nooby in UTF and I don’t really know what should happen for non-ascii characters in that case (should such a function just ignore them?). Such a function can solve the problem with .toUpper()/toLower() in QByteArray - just remove them and use free function if you’re sure your string is latin1/you don’t care about UTF (which is the currently supported case). On the other hand, if we introduce QLatin1String/QUtf8String/Q(Utf16)String, such a function will probably won’t make much sense (except for optimization purposes/being an implementation detail) since the API for those classes should be the same, i.e. have some allocating toUpper/toLower methods (since string size can change after those operations). > 8 июля 2019 г., в 8:49, Giuseppe D'Angelo via Development > написал(а): > > Il 08/07/19 07:54, Иван Комиссаров ha scritto: >> Is it possible to do an inplace toUpper() for the ASCII encoding? > > At some past QtCS it was deemed that we should add foo() functions to > complement any toFoo() -- the former would act in-place, the latter would > return a new value. > > But I don't think any of that has happened yet, so your best shot is hoping > that foo() is overloaded for rvalue *this. toUpper() is, hence the in-place > modifying version is the > >> ba = std::move(ba).toUpper(); > > which IMNSHO is quite *bad* to read. > > 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 > > ___ > 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] HTML5/CSS vs Qt QML and QtCreator / Assistant
On 01/07/2019 09.56, Konstantin Tokarev wrote: > 01.07.2019, 13:30, "Ville Voutilainen" : >> On Sat, 29 Jun 2019 at 14:34, Konstantin Tokarev wrote: >>> Or even better: split page into "tiles" (i.e. portions of page with height >>> of viewport) and >>> render long page as a sequnece of tiles. This would reduce time needed to >>> show initial >>> content. >> >> That sounds curiously like "reimplement how Chromium renders web pages" to >> me. > > Not exactly: > > 1. We don't have any updates, so all tiles are immutable They are? How are you planning to handle text selection? -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Moving to Gerrit 2.16.9
On 30/06/2019 10.10, Holger Freyther wrote: > On 28. Jun 2019, at 00:57, Thiago Macieira wrote: >> In this particular case, Google loves to use Bazel. Everyone else hates that >> they do. >> >> Ask anyone trying to package Tensorflow. > > Some Ex-Googlers like it too. It seems there is a disconnect between > the SaaS/PaaS/CD world and where some of us come from with traditional > packaging of binaries. :} Indeed. Having been exposed to it once, I can understand where a closed-source company could find Bazel attractive, but it was a *horrible* fit for open source projects at the time. I don't know how much it has improved, though, given Google, I would suspect "not much". -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Oslo, we have a problem [char8_t]
Just checked the implementation (thanks to woboq, once again) and you're
right. These are completely unacceptable.
Konstantin
пн, 8 июл. 2019 г., 20:28 Thiago Macieira :
> On Monday, 8 July 2019 10:53:42 -03 Konstantin Ritt wrote:
> > > See my reply to Marc: users want US-ASCII case-insensitive text
> matching
> > > and
> > > case folding routines, for network protocols that are US-ASCII case-
> > > insensitive (DNS, IRC, etc.).
> >
> > That strnicmp() and std::toupper()/std::tolower() is exactly what for.
>
> No, those are exactly what they are NOT for.
>
> First, those are locale-dependent and should not be used unless you
> control
> the locale or you specifically want to treat your 8-bit content under the
> system's locale codec. On most modern Unix systems, that's UTF-8. But it's
> not
> uncommon to find applications run with LC_ALL=C, which force those
> functions
> to US-ASCII.
>
> And then there's tr_TR.UTF-8, which causes strnicmp("I", "i") != 0. If
> this is
> what you want, great. Just be careful when using it and expecting US-ASCII
> behaviour, like when parsing the IRC protocol. There used to be an old bug
> in
> ksirc that if you joined channel #irc, it would also join #ırc and then
> further open tabs for #Irc and #İrc depending on messages you received.
>
> Finally, std::toupper and std::tolower are FLAWED BY DESIGN. Do not use
> them,
> ever. Uppercasing and lowercasing are string functions, any API that
> returns a
> single character is flawed. SG16 means to fix that in the new std::text
> functionality.
>
> --
> 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] QTestlib: how not to test mouseMoveEvent handling
Den mån 8 juli 2019 kl 16:26 skrev Volker Hilsheimer : > > Hi, > > Executive summary: > > * QTest::mouseMove seems to be broken > * when simulating QEvent::MouseMove events by constructing event objects, > always construct them with global position > > > The details: > > While trying to fix https://bugreports.qt.io/browse/QTBUG-76765 to not update > the mouse cursor when the cursor-fied QGraphicsItem the mouse is on top of is > disabled, I noticed the following pattern in the respective test: > > QTest::mouseMove(localPoint, widget); > QMouseEvent event(QEvent::MouseMove, localPoint, Qt::NoButton, 0, 0); > QApplication::sendEvent(widget, ); > > > which confused me a bit. Shouldn’t QTest::mouseMove already have sent the > event? Apparently not. That there is no overload that takes modifiers and > keys is also strange. > > In the end, when running the test locally on my Mac, I never got it ot pass. > > What seems to happen is this: > > * for QWidget receivers, QTest::mouseMove just calls QCursor::setPos > > QCursor::setPos is not guaranteed to generate mouse events. The documentation > of some overloads of that function [1] in fact explicitly advises against > using that function in unit tests. > > > * QMouseEvent uses QCursor::pos if no global position has been explicitly > provided > > A lot of tests don’t explicitly calculate and provide the global mouse > position, but some widgets use the global position (QGraphicsView, for > instance). > > Since QCursor::setPos doesn’t do much of anything on my mac when I’m logged > in (the visible mouse pointer on the screen didn’t move when running tests), > the mouse events received are not the ones the test expects to be received, > and the tests fail. > > I tried to fix this case now by always constructing QMouseEvent objects with > both local and global positions. That is easy, but a bit tedious, and that we > don’t use QTest::mouseMove suggests that this function has not been working > as one would expect for a while. We've run into this in our app's unit tests as well, and found this old bug about it: https://bugreports.qt.io/browse/QTBUG-5232 (That one was sort of inverted to what you're describing though, it would work on Mac, but not X11/Windows, but yea, it's old..) We also construct the events manually and send them. Elvis > > Perhaps someone can enlighten me why QTest::mouseMove doesn’t simulate a > QEvent like QTest::mousePress does? An overload that takes modifiers and > keys, and simply simulates the event, would be a good addition, perhaps? > > > Volker > > > [1] https://doc.qt.io/qt-5/qcursor.html#setPos-1 > > > ___ > 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] Oslo, we have a problem [char8_t]
On Monday, 8 July 2019 10:53:42 -03 Konstantin Ritt wrote:
> > See my reply to Marc: users want US-ASCII case-insensitive text matching
> > and
> > case folding routines, for network protocols that are US-ASCII case-
> > insensitive (DNS, IRC, etc.).
>
> That strnicmp() and std::toupper()/std::tolower() is exactly what for.
No, those are exactly what they are NOT for.
First, those are locale-dependent and should not be used unless you control
the locale or you specifically want to treat your 8-bit content under the
system's locale codec. On most modern Unix systems, that's UTF-8. But it's not
uncommon to find applications run with LC_ALL=C, which force those functions
to US-ASCII.
And then there's tr_TR.UTF-8, which causes strnicmp("I", "i") != 0. If this is
what you want, great. Just be careful when using it and expecting US-ASCII
behaviour, like when parsing the IRC protocol. There used to be an old bug in
ksirc that if you joined channel #irc, it would also join #ırc and then
further open tabs for #Irc and #İrc depending on messages you received.
Finally, std::toupper and std::tolower are FLAWED BY DESIGN. Do not use them,
ever. Uppercasing and lowercasing are string functions, any API that returns a
single character is flawed. SG16 means to fix that in the new std::text
functionality.
--
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] Oslo, we have a problem [char8_t]
On Monday, 8 July 2019 12:42:51 -03 Arnaud Clere wrote: > -Original Message- > From: Thiago Macieira > > > I am not completely convinced of the benefit of adding of an owning UTF-8 > > string class, though I very much agree with a view over UTF-8 strings. > > The reason is not the string class itself (alone it is definitely > > useful), but the fact that it would muddy the waters as to what string > > classes one should use in API. We might end up with some API using UTF-8 > > and some UTF-16. > > Indeed, this is already the case : QJsonDocument::toJson() returns a > QByteArray Which is the expected behaviour, as it returns something suitable for transfer over a socket, pipe to a process or to be saved in a file, like QCborValue::toCbor(), QDataStream, QTextStream (operating over a QByteArray), QXmlStreamWriter (operating over a QByteArray), QDomDocument::toByteArray(), etc. It's just that, unlike those others, it is also a UTF-8 encoded text string. The XML ones, for example, can be configured to write under other encodings and such information is stored in the XML header. CBOR and QDataStream are obviously binary. > on which users can conveniently call toUpper() until some data > from the field makes them understand it does not work... And there's little we can do to prevent that. Even if we removed QByteArray::toUpper and left it only in QLatin1String, people would still find ways to uppercase. That's the reason I would prefer to keep it, with well- defined and locale-independent semantics. > Working for a > regulated industry, getting rid of potential bugs is my #1 concern, not > that of having more fancy utf8 features! However, if deriving a QUtf8String > from QByteArray is inappropriate (of which I am not totally convinced... > cannot see a Liskov-Substitution-Principle violation in this case), I > understand the task may be daunting. It may be argued too that COW is not > interesting for such strings and APIs can be fixed by using u8string, but > then, you ask Qt users to master both QString and std::string like APIs... We don't ask users to use std::string APIs. That is not a text class, std::string is analogous to QByteArray. C++ does not have a text container class and that's not going to come until at least 2023 (C++2b). std::string, like QByteArray, is encoding-agnostic but has some string-like convenience functions over a pure byte storage (like std::vector), like searching for a substring occurrence, instead single value_type elements. QByteArray does when we unified it with QCString in Qt 4.0. -- 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] Assistant WebKit/WebEngine support
On 25/06/2019 17.53, Konrad Rosenbaum wrote: > Option 2: put some elbow grease into QTextBrowser and make it understand > some more tags and more CSS. > Pros: documentation becomes visually more pleasing; minimal dependencies > by assistant - easy to build and easy to bundle with applications; > embedding in Creator or KDevelop etc. stays easy to do > Positive side effect: users will love it, since it becomes much easier > and flexible to use QTextBrowser in their own applications > Con: someone actually has to put in the work Incidentally, does this help rich text rendering *everywhere*? Such as in tool tips, for example? -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Oslo, we have a problem [char8_t]
-Original Message- From: Thiago Macieira > > I am not completely convinced of the benefit of adding of an owning UTF-8 > string class, though I very much agree with a view over UTF-8 strings. > The reason is not the string class itself (alone it is definitely useful), > but the fact that it would muddy the waters as to what string classes one > should use in API. > We might end up with some API using UTF-8 and some UTF-16. Indeed, this is already the case : QJsonDocument::toJson() returns a QByteArray on which users can conveniently call toUpper() until some data from the field makes them understand it does not work... Working for a regulated industry, getting rid of potential bugs is my #1 concern, not that of having more fancy utf8 features! However, if deriving a QUtf8String from QByteArray is inappropriate (of which I am not totally convinced... cannot see a Liskov-Substitution-Principle violation in this case), I understand the task may be daunting. It may be argued too that COW is not interesting for such strings and APIs can be fixed by using u8string, but then, you ask Qt users to master both QString and std::string like APIs... Just my 2c, Arnaud ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
> On 8 Jul 2019, at 16:24, Volker Hilsheimer wrote: > > Hi, > > Executive summary: > > * QTest::mouseMove seems to be broken > * when simulating QEvent::MouseMove events by constructing event objects, > always construct them with global position > > > The details: > > While trying to fix https://bugreports.qt.io/browse/QTBUG-76765 to not update > the mouse cursor when the cursor-fied QGraphicsItem the mouse is on top of is > disabled, I noticed the following pattern in the respective test: > > QTest::mouseMove(localPoint, widget); > QMouseEvent event(QEvent::MouseMove, localPoint, Qt::NoButton, 0, 0); > QApplication::sendEvent(widget, ); > > > which confused me a bit. Shouldn’t QTest::mouseMove already have sent the > event? Apparently not. That there is no overload that takes modifiers and > keys is also strange. > > In the end, when running the test locally on my Mac, I never got it ot pass. > > What seems to happen is this: > > * for QWidget receivers, QTest::mouseMove just calls QCursor::setPos > > QCursor::setPos is not guaranteed to generate mouse events. The documentation > of some overloads of that function [1] in fact explicitly advises against > using that function in unit tests. Yep. Cursor support can be disabled, I think that’s one reason at least. Another is that some platforms (i.e. Wayland) don’t allow applications to set cursor position. Anyway it’s heavy-handed and slow. But tests that need to simulate mouse hover or mouse enter/exit by sending events do need to ensure that the cursor is _not_ on top of the window, to avoid getting spurious events… and that’s usually done by QCursor::setPos(); so we can’t seem to get rid of it after all. https://codereview.qt-project.org/c/qt/qtbase/+/5290 seems to have put it into its current state… it’s old. But before that was https://codereview.qt-project.org/c/qt/qtbase/+/4462 which comments out QCursor::setPos() and sends a platform event instead… at least in one case. Too bad the commit message is so sparse. I suppose there’s the usual tradeoff between the philosophy that real platform testing should involve real platform events (in this case: if you really move the system mouse cursor, then the window system will hopefully send a mouse move event to the window, and aren’t you making the test more realistic that way?) vs. the practical tendency for that kind of testing to be less reliable, with unpredictable latency, needing to use QTRY_ much more because you don’t know how long to wait until the window system reacts, etc. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QTestlib: how not to test mouseMoveEvent handling
Hi, Executive summary: * QTest::mouseMove seems to be broken * when simulating QEvent::MouseMove events by constructing event objects, always construct them with global position The details: While trying to fix https://bugreports.qt.io/browse/QTBUG-76765 to not update the mouse cursor when the cursor-fied QGraphicsItem the mouse is on top of is disabled, I noticed the following pattern in the respective test: QTest::mouseMove(localPoint, widget); QMouseEvent event(QEvent::MouseMove, localPoint, Qt::NoButton, 0, 0); QApplication::sendEvent(widget, ); which confused me a bit. Shouldn’t QTest::mouseMove already have sent the event? Apparently not. That there is no overload that takes modifiers and keys is also strange. In the end, when running the test locally on my Mac, I never got it ot pass. What seems to happen is this: * for QWidget receivers, QTest::mouseMove just calls QCursor::setPos QCursor::setPos is not guaranteed to generate mouse events. The documentation of some overloads of that function [1] in fact explicitly advises against using that function in unit tests. * QMouseEvent uses QCursor::pos if no global position has been explicitly provided A lot of tests don’t explicitly calculate and provide the global mouse position, but some widgets use the global position (QGraphicsView, for instance). Since QCursor::setPos doesn’t do much of anything on my mac when I’m logged in (the visible mouse pointer on the screen didn’t move when running tests), the mouse events received are not the ones the test expects to be received, and the tests fail. I tried to fix this case now by always constructing QMouseEvent objects with both local and global positions. That is easy, but a bit tedious, and that we don’t use QTest::mouseMove suggests that this function has not been working as one would expect for a while. Perhaps someone can enlighten me why QTest::mouseMove doesn’t simulate a QEvent like QTest::mousePress does? An overload that takes modifiers and keys, and simply simulates the event, would be a good addition, perhaps? Volker [1] https://doc.qt.io/qt-5/qcursor.html#setPos-1 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Oslo, we have a problem [char8_t]
пн, 8 июл. 2019 г., 16:43 Thiago Macieira : > On Monday, 8 July 2019 04:38:28 -03 Konstantin Ritt wrote: > > Perhaps there is a particular reason for the user to manipulate binary > data > > as if it were a string? So give him that string, QString. > > See my reply to Marc: users want US-ASCII case-insensitive text matching > and > case folding routines, for network protocols that are US-ASCII case- > insensitive (DNS, IRC, etc.). > That strnicmp() and std::toupper()/std::tolower() is exactly what for. Konstantin > -- > 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] Oslo, we have a problem [char8_t]
On Monday, 8 July 2019 04:24:28 -03 Mutz, Marc via Development wrote: > What I think when I read this is: > > Backed by const char*, never implicit: > - QLatin1String - owner of L1 data [change from today, but not a > breaking one] > - QLatin1StringView - what QLatin1String is now [requires porting, but > it's just s/QLatin1String/QLatin1StringView/g in client code] > > Backed by const char8_t*, implicit: > - QUtf8String - owner of UTF-8 data > - QUtf8StringView - view over UTF-8 data > > Backed by const char16_t*, implicit (from char16_t*, Q*StringView, NOT > from QByteArray) > - QString - owner of UTF-16 data [as before, possibly using char16_t > internally to avoid the tons of ushort casts] > - QStringView - view over UTF-16 data > > Backed by const std::byte*, implicit: > - QByteArray - owner of std::byte data, no string-like functions > [breaking change, but anyway far in the future, as we can't depend on > std::byte, yet] > - QByteArrayView - view over std::byte (uchar, char, ...) data. > > QByteArray, QUtf8String and QLatin1String(new) could use the same > backend, for zero-copy transformations between them. > > Is this a realistic goal for Qt 7? Last time I proposed > QUtf8String/View, it's usefulness was challenged. I think the advent of > char8_t in C++20 and std::byte in C++17 change the game quite a bit, > though. In a green field scenario, yes, that would be a realistic goal. I am not completely convinced of the benefit of adding of an owning UTF-8 string class, though I very much agree with a view over UTF-8 strings. The reason is not the string class itself (alone it is definitely useful), but the fact that it would muddy the waters as to what string classes one should use in API. We might end up with some API using UTF-8 and some UTF-16. But the biggest challenge is converting *every* *single* use of QLatin1String to QLatin1StringView. We can introduce it as a direct alias right now, at some point in late Qt 6 deprecate QLatin1String, at a point where people wouldn't be trying to keep compatibility with Qt < 5.15, then reintroduce it in Qt 7.0. I'm not sure we should go through all that trouble for three functions. People don't want Latin1 case-insensitiveness, they want US-ASCII. It just so happens that it was easy for us to implement Latin1 in those functions that we did so. I propose we make a documented change in behaviour in 6.0 and remove the upper half of the case tables of qbytearray.cpp:latin1_uppercased and latin1_lowercased. That would make those functions operate fully on US-ASCII only, which would in turn make them safe[*] for UTF-8 content too. [*] where "safe" is defined as ASCII-insensitive and non-ASCII sensitive. There are some broken protocols like that, like DNS-SD (used in Zeroconf), which uses UTF-8 encoding over US-ASCII case-insensitive DNS. -- 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] Oslo, we have a problem [char8_t]
On Monday, 8 July 2019 02:54:52 -03 Иван Комиссаров wrote:
> Is it possible to do an inplace toUpper() for the ASCII encoding?
Uh...
Q_REQUIRED_RESULT QByteArray toLower() const &
{ return toLower_helper(*this); }
Q_REQUIRED_RESULT QByteArray toLower() &&
{ return toLower_helper(*this); }
Q_REQUIRED_RESULT QByteArray toUpper() const &
{ return toUpper_helper(*this); }
Q_REQUIRED_RESULT QByteArray toUpper() &&
{ return toUpper_helper(*this); }
[...]
static QByteArray toLower_helper(const QByteArray );
static QByteArray toLower_helper(QByteArray );
static QByteArray toUpper_helper(const QByteArray );
static QByteArray toUpper_helper(QByteArray );
--
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] Oslo, we have a problem [char8_t]
On Monday, 8 July 2019 04:38:28 -03 Konstantin Ritt wrote: > Perhaps there is a particular reason for the user to manipulate binary data > as if it were a string? So give him that string, QString. See my reply to Marc: users want US-ASCII case-insensitive text matching and case folding routines, for network protocols that are US-ASCII case- insensitive (DNS, IRC, etc.). -- 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] Oslo, we have a problem [char8_t]
On Monday, 8 July 2019 07:06:33 -03 Mutz, Marc via Development wrote: > So no, no more inheriting of value classes from each other. QUtf8String, > if it comes, will have to be a separate type, not a subclass of > QByteArray. They can be both derived from the same base, internal, common class. The problem in all your examples was that both classes were public and in use (aside from QBasicMutex, but the issues you've found are also exclusively found inside Qt's own code). -- 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] Got a question on Qy3D
No problem Eddy, Thanks for notifying it. On Mon, 8 Jul 2019 at 15:19, Edward Welbourne wrote: > Sujan Dasmahapatra (5 July 2019 20:43) asked > > I'm loading an obj file in Qt3DWindow. The model is a restaurant which > has many objects as sofa, table etc. > > > > How can I extract individual objects. I'm unable to segregate as the > whole object is root entity. > > > > I actually want to apply texture different for each entity. > > > > Please help me with the possible solution. > > Hi Sujan, > > This looks like a question for the interest@ mailing list, where users > of Qt help one another, rather than development@, which is the list for > discussion of development of Qt itself. I'm afraid I know nothing of > Qt3D, > > Eddy. > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Oslo, we have a problem [char8_t]
Hi,
Before this gets any more traction: Aye! for QUtf8String, nay for the
implementation.
On 2019-07-08 09:46, Arnaud Clere wrote:
//! Explicitely utf8 encoded byte array
class QUtf8String : public QByteArray
{
public:
using QByteArray::QByteArray;
QUtf8String(const QByteArray& o) : QByteArray(o) {}
QUtf8String() : QByteArray() {}
};
Whenever we have publicly derived one value type from another, we've
created a mess. QPolygon : QVector (qvector_msvc.h), QStringList : QList
(QListSpecialMethods), QItemSelection : QList
(qHash(QItemselectionRange)), QMutex : QBasicMutex (invalid casts in
QMutexLocker), ...
So no, no more inheriting of value classes from each other. QUtf8String,
if it comes, will have to be a separate type, not a subclass of
QByteArray.
Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Got a question on Qy3D
Sujan Dasmahapatra (5 July 2019 20:43) asked > I'm loading an obj file in Qt3DWindow. The model is a restaurant which has > many objects as sofa, table etc. > > How can I extract individual objects. I'm unable to segregate as the whole > object is root entity. > > I actually want to apply texture different for each entity. > > Please help me with the possible solution. Hi Sujan, This looks like a question for the interest@ mailing list, where users of Qt help one another, rather than development@, which is the list for discussion of development of Qt itself. I'm afraid I know nothing of Qt3D, Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Oslo, we have a problem [char8_t]
Arnaud Clere (8 July 2019 09:46) wrote
> Instead of asking users to choose correct QByteArray methods depending
> on the data it contains, why not proposing them to explicitly say what
> it contains?
>
> //! Explicitely utf8 encoded byte array
> class QUtf8String : public QByteArray
> {
> public:
> using QByteArray::QByteArray;
> QUtf8String(const QByteArray ) : QByteArray(o) {}
> QUtf8String() : QByteArray() {}
> };
>
> Such QUtf8String can be used everywhere a QByteArray is.
> Qt implementors can fix QByteArray toUpper(), split(), etc. without
> having to guess what to do. Users only have to specify where they use
> utf8 to make sure they use the correct functions. Having a COW
> QUtf8String providing a migration path from ambiguous QByteArray seems
> in line with the addition of char8_t and u8* to C++ standard.
We could then move the string-ish methods to these derived string
classes, deprecating the QByteArray base versions (and not making them
virtual) in favour of using the right 8-bit string type. (The base's
implementation could indeed use that of a derived string class.)
That would glitch the "use anywhere QByteArray is asked for", of
course (you'd get the base's version of these methods), but anything
that accepts a QByteArray and does string-ish things to it is flawed
anyway. It should be deprecated in favour of a templated API taking a
string-type.
Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Oslo, we have a problem [char8_t]
Thiago had observed: >>> Arguably, toUpper() and toLower() should be removed, since >>> >>> QByteArray(u8"Résumé").toLower() >>> is mojibake. вс, 7 июл. 2019 г., 12:58 André Hartmann mailto:aha_1...@gmx.de>>: >> I vote against that. If you got the "raw" data from a device as >> described above, you might want to do .toHex().toUpper() which is fully >> valid. Konstantin Ritt (8 July 2019 04:26) replied: > I'd argue against validity of the `ba.toHex().toUpper()` example, as > it brings false impression that you're operating on a string, where in > fact your intention is to re-code the binary data from one encoded > form to another encoded form (ASCII in this case, and one would have > to `QString::fromLatin1()` it explicitly to manipulate it further). > From the other hand, `ba.toHex(Uppercase)` enforces the reader to > treat it exactly like an uppercased hex (whatever that means), which > is just another encoding form of the binary data. My thought exactly: we can, at least, add this overload to toHex(). Historical baggage precludes removing (or deprecating) the traditional path, but we can at least add the path that avoids use of a suspect API. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Oslo, we have a problem [char8_t]
On Monday, 8 July 2019 09:37:24 CEST Allan Sandfeld Jensen wrote:
> On Samstag, 6. Juli 2019 16:53:13 CEST Mutz, Marc via Development wrote:
> > On 2019-07-06 16:38, Konstantin Tokarev wrote:
> > > 06.07.2019, 17:20, "Mutz, Marc via Development"
> > >
> > > :
> > >> On 2019-07-06 14:50, Fabian Kosmale wrote:
> > >> [...]
> > >>
> > >>> See https://godbolt.org/z/e6OinY for how this would look for a
> > >>>
> > >>> trivial function.
> > >>
> > >> [...]
> > >>
> > >> Now also handle test(NULL) and extend to binary:
> > >> test2([0, NULL, nullptr, "", u8""], [0, NULL, nullptr, "", u8""])
> > >>
> > >> This doesn't scale...
> > >
> > > It can be argued that use of NULL in C++ code is more relict thing and
> > > should not be
> > > supported. It's also much easier to migrate code base from NULL to
> > > nullptr - simple text
> > > replacement is enough.
> >
> > 0 -> nullptr is just as simple: clang-tidy has a fixit for that.
>
> Won't work on Qt code. At least no nicely. When I tried cleaning up QtCore I
> found we do something ugly with QFlags where passing a 0 somehow goes over
> pointer. The fix for
> QFlags a(0)
> is
> QFlags a = {}
>
> or we need to update our hack to not trigger the 0 as pointer constant
> warning.
Sorry for derailing more from the original topic:
But for this case another option would be to extend this particular clang-tidy
checker to support special replacement rules for certain types. It's
relatively easy to make clang-tidy checkers configurable.
So in this case one would instruct clang-tidy to replace the arg to the
constructor call `QFlags(...)` with a '{}' instead of a 'nullptr'.
PS: For others wondering about the details about the "QFlags-hack" accepting
"0", here are all the details:
https://phabricator.kde.org/D3987
Regards,
Kevin
> 'Allan
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
--
Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
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] Oslo, we have a problem [char8_t]
On 2019-07-08 09:24, Mutz, Marc via Development wrote: - QLatin1StringView - what QLatin1String is now [requires porting, but it's just s/QLatin1String/QLatin1StringView/g in client code] → https://codereview.qt-project.org/c/qt/qtbase/+/267375 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Oslo, we have a problem [char8_t]
On Samstag, 6. Juli 2019 14:50:05 CEST Fabian Kosmale wrote: > Hi, > > Actually, most of the time there is actually an option 3. Add yet another > overload, this time for int. This will match the 0 literal without any > conversion, and we can then just call the nullptr overload inside. > Unfortunately, C++20 still does not have constexpr parameters, else we > could ensure at compile time that only 0 is allowed. Currently, we can only > add a runtime assert as far as I can see. Constexpr parameters.. Hmm, will it be possible to mark constructors consteval? That would have to be constexpr parameters then. Unfortunately last I checked no compiler had implemented consteval yet, so no experimentation. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Oslo, we have a problem [char8_t]
Hi all,
> -Original Message-
> From: Thiago Macieira
>
> But QByteArray is encoding-indeterminate since it can carry any type.
> Arguably, toUpper() and toLower() should be removed, since
> QByteArray(u8"Résumé").toLower() is mojibake.
...
> Are we willing to add ubegin() and begin8() too?
Instead of asking users to choose correct QByteArray methods depending on the
data it contains, why not proposing them to explicitly say what it contains?
//! Explicitely utf8 encoded byte array
class QUtf8String : public QByteArray
{
public:
using QByteArray::QByteArray;
QUtf8String(const QByteArray& o) : QByteArray(o) {}
QUtf8String() : QByteArray() {}
};
Such QUtf8String can be used everywhere a QByteArray is.
Qt implementors can fix QByteArray toUpper(), split(), etc. without having to
guess what to do.
Users only have to specify where they use utf8 to make sure they use the
correct functions.
Having a COW QUtf8String providing a migration path from ambiguous QByteArray
seems in line with the addition of char8_t and u8* to C++ standard.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Oslo, we have a problem [char8_t]
пн, 8 июл. 2019 г., 5:44 Thiago Macieira : > On Sunday, 7 July 2019 23:26:40 -03 Konstantin Ritt wrote: > > As we have string views now, I'd vote for deprecating the string > > manipulation methods in QByteArray. I doubt we could make QByteArray a > true > > vector of bytes now, without breaking lots of the user code, but that > could > > be a good first step. > > We don't have any good 8-bit string manipulation functions outside of > QByteArray. They stay. > We don't have any good 8-bit string manipulation functions in QByteArray either ;) > The question is whether the Latin1 methods (toUpper(), toLower() and the > free > function qstricmp) should be moved or removed. Those would work really > well in > QLatin1String, but QLatin1String is a view, since it doesn't own the data. > QLatin1String::toUpper() could return a QByteArray... > Perhaps there is a particular reason for the user to manipulate binary data as if it were a string? So give him that string, QString. > -- > 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 Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Oslo, we have a problem [char8_t]
On Samstag, 6. Juli 2019 16:53:13 CEST Mutz, Marc via Development wrote:
> On 2019-07-06 16:38, Konstantin Tokarev wrote:
> > 06.07.2019, 17:20, "Mutz, Marc via Development"
> >
> > :
> >> On 2019-07-06 14:50, Fabian Kosmale wrote:
> >> [...]
> >>
> >>> See https://godbolt.org/z/e6OinY for how this would look for a
> >>> trivial function.
> >>
> >> [...]
> >>
> >> Now also handle test(NULL) and extend to binary:
> >>
> >> test2([0, NULL, nullptr, "", u8""], [0, NULL, nullptr, "", u8""])
> >>
> >> This doesn't scale...
> >
> > It can be argued that use of NULL in C++ code is more relict thing and
> > should not be
> > supported. It's also much easier to migrate code base from NULL to
> > nullptr - simple text
> > replacement is enough.
>
> 0 -> nullptr is just as simple: clang-tidy has a fixit for that.
Won't work on Qt code. At least no nicely. When I tried cleaning up QtCore I
found we do something ugly with QFlags where passing a 0 somehow goes over
pointer. The fix for
QFlags a(0)
is
QFlags a = {}
or we need to update our hack to not trigger the 0 as pointer constant
warning.
'Allan
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Oslo, we have a problem [char8_t]
On Samstag, 6. Juli 2019 12:43:39 CEST Mutz, Marc via Development wrote: > > Opinions? > I think we need separate functions anyway in order to handle our NO_ASCII_CONVERT macros. Accepting char8_t shouldn't trigger the warning as the encoding is well-definied. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Oslo, we have a problem [char8_t]
On 2019-07-08 04:43, Thiago Macieira wrote: On Sunday, 7 July 2019 23:26:40 -03 Konstantin Ritt wrote: As we have string views now, I'd vote for deprecating the string manipulation methods in QByteArray. I doubt we could make QByteArray a true vector of bytes now, without breaking lots of the user code, but that could be a good first step. We don't have any good 8-bit string manipulation functions outside of QByteArray. They stay. The question is whether the Latin1 methods (toUpper(), toLower() and the free function qstricmp) should be moved or removed. Those would work really well in QLatin1String, but QLatin1String is a view, since it doesn't own the data. QLatin1String::toUpper() could return a QByteArray... What I think when I read this is: Backed by const char*, never implicit: - QLatin1String - owner of L1 data [change from today, but not a breaking one] - QLatin1StringView - what QLatin1String is now [requires porting, but it's just s/QLatin1String/QLatin1StringView/g in client code] Backed by const char8_t*, implicit: - QUtf8String - owner of UTF-8 data - QUtf8StringView - view over UTF-8 data Backed by const char16_t*, implicit (from char16_t*, Q*StringView, NOT from QByteArray) - QString - owner of UTF-16 data [as before, possibly using char16_t internally to avoid the tons of ushort casts] - QStringView - view over UTF-16 data Backed by const std::byte*, implicit: - QByteArray - owner of std::byte data, no string-like functions [breaking change, but anyway far in the future, as we can't depend on std::byte, yet] - QByteArrayView - view over std::byte (uchar, char, ...) data. QByteArray, QUtf8String and QLatin1String(new) could use the same backend, for zero-copy transformations between them. Is this a realistic goal for Qt 7? Last time I proposed QUtf8String/View, it's usefulness was challenged. I think the advent of char8_t in C++20 and std::byte in C++17 change the game quite a bit, though. I'm also looking at all the relational operators we have between our string-like classes, and it's ... frightening. Using views to define relations would allow to cut quite a lot of relational operator overloads. Thanks, Marc ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Oslo, we have a problem [char8_t]
Il 08/07/19 07:54, Иван Комиссаров ha scritto: Is it possible to do an inplace toUpper() for the ASCII encoding? At some past QtCS it was deemed that we should add foo() functions to complement any toFoo() -- the former would act in-place, the latter would return a new value. But I don't think any of that has happened yet, so your best shot is hoping that foo() is overloaded for rvalue *this. toUpper() is, hence the in-place modifying version is the ba = std::move(ba).toUpper(); which IMNSHO is quite *bad* to read. 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
