Re: [Development] QTestlib: how not to test mouseMoveEvent handling
On 11.07.19, 05:55, "Development on behalf of Jason McDonald" wrote: I also recall that there used to be a wiki page that listed some best-practices for writing unit tests. If that list still exists somewhere, this advice should be added there. Did you mean this page: https://wiki.qt.io/Writing_Unit_Tests ? -- Kavindra. This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] char8_t summary?
On Wed, Jul 10, 2019 at 10:01:04PM -0300, Thiago Macieira wrote: > On Wednesday, 10 July 2019 09:55:02 -03 André Pönitz wrote: > > As far as I understand there's a perceived need to have "full" utf8 > > literals, and there's a need to have ASCII literals. First could be > > served by some QUtf8*, second by QAscii*, both additions, no need to > > change QLatin* semantics. > > ASCII = Latin1 bool = char ? circle = ellipse ? It's a subset, it is special enough to be called by its name. Especially if it has features (e.g. toUpper/toLower operating on single letters) that are not present in the larger set. The line of discussion here is - people (correctly, happily) use toUpper on (7-bit clean US-ASCII) data - ASCII is claimed to be identical to Latin1 - since it is identical it is superfluous to have both and ASCII is dropped - toUpper does not work per-char for Latin1 in corner cases - so it needs to be dropped "to avoid wrong use" In the end this deprives users from a useful tool in a scenario where it was perfectly fine to use. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
On Thu, Jul 11, 2019 at 5:57 PM Palaraja, Kavindra wrote: > On 11.07.19, 05:55, "Development on behalf of Jason McDonald" > wrote: > > > > I also recall that there used to be a wiki page that listed some > best-practices for writing unit tests. If that list still exists > somewhere, this advice should be added there. > > Did you mean this page: https://wiki.qt.io/Writing_Unit_Tests ? Yes, that's the one. There's a "Hints on writing reliable tests" section where this kind of advice would belong. Thanks Kavindra. (And thanks to the folks who have improved on my old text for that page.) Cheers, -- Jason ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
Den tors 11 juli 2019 kl 05:54 skrev Jason McDonald : > > On Tue, Jul 9, 2019 at 1:39 AM Shawn Rutledge wrote: > > > 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 > > That's good advice for now. I think it would be worth filing a bug to > see if this part of testlib can be fixed/improved in the future. At I think https://bugreports.qt.io/browse/QTBUG-5232 could be re-used/re-opened for this. It was closed with resolution "Won't Do", but with a comment ""Won't Do" => actually we will do this. In Qt 6 we will drop some legacy code paths and this stuff will start working fine." comment from Gatis. Elvis > the very least, it will make it clear that we're aware of the issue. > > I also recall that there used to be a wiki page that listed some > best-practices for writing unit tests. If that list still exists > somewhere, this advice should be added there. > > >>That there is no overload that takes modifiers and keys is also strange. > > Most likely this omission is simply because nobody ever asked for such > an overload. I'm fairly sure that that part of testlib existed before > modifiers and keys were part of the Qt API and testlib never caught up > when those were added elsewhere. > > > 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. > > I think it got that way a bit earlier than that patch. The patch > appears to just move code around without modifying any functionality. > > > 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. > > Unfortunately, our approval process wasn't followed very well for > either of those patches. Both patches were pushed through very > quickly outside the working hours of the testlib maintainer (me, in > GMT+10 timezone, where the patches were each pushed through in my > evening). If I had had an opportunity to review them I would > certainly have objected to the uninformative commit message. (Those > who were around in the Trolltech and Nokia days may remember my vocal > campaigns for meaningful commit messages, motivated by the fact that > for some years I was the poor sucker who had to read thousands of > commit messages every few months and turn them into release notes.) > > > 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. > > I have always been a little uncomfortable with the part of testlib > that handles mouse and keyboard events because it feels like some of > it crosses the line from unit testing into integration and system > testing, and thus really belongs in a separate system-level test > framework rather than in testlib. The system-level tests that > masqueraded as unit tests were always more likely to be flaky than > 'pure' unit tests. > > In the period before Qt 5, I had been hopeful that there would be an > opportunity to tidy this up and cleanly separate the true unit tests > from the others. At that time there was a team working on a separate > system-level testing framework for Qt, but that team was in Brisbane > and evaporated when the decision was made to eject Qt from Nokia and > the new system-test framework was never completed. > > Cheers, > -- > Jason > ___ > 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] Looks like code.qt.io is down!
Konstantin Podsvirov (10 July 2019 22:52) > The code.qt.io at 34.244.34.65 hase not response. Seems to be back now, at least for me. Shout if you're still not seeing it ! Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] char8_t summary?
On 2019-07-11 10:13, André Pönitz wrote:
On Wed, Jul 10, 2019 at 10:01:04PM -0300, Thiago Macieira wrote:
On Wednesday, 10 July 2019 09:55:02 -03 André Pönitz wrote:
> As far as I understand there's a perceived need to have "full" utf8
> literals, and there's a need to have ASCII literals. First could be
> served by some QUtf8*, second by QAscii*, both additions, no need to
> change QLatin* semantics.
ASCII = Latin1
bool = char ?
circle = ellipse ?
It's a subset, it is special enough to be called by its name.
Especially
if it has features (e.g. toUpper/toLower operating on single letters)
that
are not present in the larger set.
The line of discussion here is
- people (correctly, happily) use toUpper on (7-bit clean US-ASCII)
data
- ASCII is claimed to be identical to Latin1
- since it is identical it is superfluous to have both and ASCII is
dropped
- toUpper does not work per-char for Latin1 in corner cases
- so it needs to be dropped "to avoid wrong use"
There is a cost associated with another string class, too, and it's
combinatorial explosion. Even when we have all view types
(QLatin1StringView, QUtf8StringView, QStringView), consider the overload
set of QString::replace(), ignoring the (ptr, size) variants:
{QL1V, QU8V, QSV, QChar} x {QL1V, QU8V, QSV, QChar}
that's 16 overloads. And that's without a possible QUtf32StringView.
Ditto for the relational operators. Add QAsciiStringView and you're up
to 25. Mind you, this is the math for the end game: no more const char*,
const char8_t*, and (ptr, size) overloads as they've all been subsumed
by their corresponding views. We'll be there, maybe, come Qt 7. The math
is even worse until then.
In the end this deprives users from a useful tool in a scenario where
it
was perfectly fine to use.
I don't see how. Users will be able to use QU8V or QL1V's toUppper() and
they'll just work for US-ASCII. The L1 algorithm can be coded such that
only ß and \xFF are on a slow path. Or maybe it's the case that
toUpper() doesn't extend the length of UTF-8-encoded text? Maybe we're
lucky and Unicode finally gets that the capital letter ß isn't SS, but
ẞ, and we can then just document that if the capital letter isn't
representable in L1, then it stays unchanged.
I'm still not convinced that QAsciiString is needed for any of this.
Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
Jason McDonald (11 July 2019 05:53) wrote: > I also recall that there used to be a wiki page that listed some > best-practices for writing unit tests. If that list still exists > somewhere, this advice should be added there. Possibly: https://wiki.qt.io/Writing_good_tests Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
On 11 Jul 2019, at 10:26, Elvis Stansvik mailto:elvst...@gmail.com>> wrote: Den tors 11 juli 2019 kl 05:54 skrev Jason McDonald mailto:macadd...@gmail.com>>: Welcome back Jason :) On Tue, Jul 9, 2019 at 1:39 AM 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 That's good advice for now. I think it would be worth filing a bug to see if this part of testlib can be fixed/improved in the future. At I think https://bugreports.qt.io/browse/QTBUG-5232 could be re-used/re-opened for this. It was closed with resolution "Won't Do", but with a comment ""Won't Do" => actually we will do this. In Qt 6 we will drop some legacy code paths and this stuff will start working fine." comment from Gatis. Elvis There’s https://bugreports.qt.io/browse/QTBUG-63991 which links to a bunch of related issues in that respect. See Gatis’ reply in this thread from a few days ago. the very least, it will make it clear that we're aware of the issue. I also recall that there used to be a wiki page that listed some best-practices for writing unit tests. If that list still exists somewhere, this advice should be added there. That there is no overload that takes modifiers and keys is also strange. Most likely this omission is simply because nobody ever asked for such an overload. I'm fairly sure that that part of testlib existed before modifiers and keys were part of the Qt API and testlib never caught up when those were added elsewhere. Thinking about that a bit more, having QTest::mouseMove deliver a QEvent::MouseMove that uses the button, key, and modifier states as per the previous calls to QTest::keyPress or QTest::mousePress/Release would be the correct thing to do. The widget’s internal state would not be realistic if we would deliver a mouseMove that has a button down without first sending a mousePress, after all. The QWindow case seems to do exatly that, but the QWidget case doesn’t; will try to have a look into that, if noone else happens to beat me to it ;) 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. I have always been a little uncomfortable with the part of testlib that handles mouse and keyboard events because it feels like some of it crosses the line from unit testing into integration and system testing, and thus really belongs in a separate system-level test framework rather than in testlib. The system-level tests that masqueraded as unit tests were always more likely to be flaky than 'pure' unit tests. Agree; our Qt classes are significant and entangled enough. Dragging windowing systems and other stuff that is entirely outside of our control into this makes it much harder to test our own logic, without adding substantial coverage. Platform interfaces like QPA could be a great opportunity to establish testable boundaries within Qt, so that we can verify “translation of events from system into Qt” separately from “handling of events inside of Qt”. We are naturally reluctant to build a lot fo tests against those interfaces, as they are private and continuously evolving. But I think it’s a better investment of our time to fix a few tests when we change private APIs, than to contstantly deal with very complex test setups and unreliable tests. Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Nominating Kavindra Palaraja for approvership
Hi all, I’d like to nominate Kavindra Palaraja as approver. She is a very active contributor and reviewer, in particular for documentation related changes, focusing on the Qt Automotive platform. She’s a former employee of Trolltech and Nokia, and has a lot of experience with Qt’s documentation. Currently, she is employed as tech writer for Luxoft. If you're curious, here's a list of her changes: https://codereview.qt-project.org/q/owner:kpalaraja%2540luxoft.com and a list of changes she's on as a reviewer: https://codereview.qt-project.org/q/reviewer:kpalaraja%2540luxoft.com Best, Paul ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Kavindra Palaraja for approvership
+1 from me. \topi From: Development on behalf of Paul Wicking Sent: Thursday, July 11, 2019 5:27 PM To: development@qt-project.org Subject: [Development] Nominating Kavindra Palaraja for approvership Hi all, I’d like to nominate Kavindra Palaraja as approver. She is a very active contributor and reviewer, in particular for documentation related changes, focusing on the Qt Automotive platform. She’s a former employee of Trolltech and Nokia, and has a lot of experience with Qt’s documentation. Currently, she is employed as tech writer for Luxoft. If you're curious, here's a list of her changes: https://codereview.qt-project.org/q/owner:kpalaraja%2540luxoft.com and a list of changes she's on as a reviewer: https://codereview.qt-project.org/q/reviewer:kpalaraja%2540luxoft.com Best, Paul ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Kavindra Palaraja for approvership
+1 From: Development on behalf of Topi Reiniö Sent: Thursday, July 11, 2019 5:33 PM To: development@qt-project.org Subject: Re: [Development] Nominating Kavindra Palaraja for approvership +1 from me. \topi From: Development on behalf of Paul Wicking Sent: Thursday, July 11, 2019 5:27 PM To: development@qt-project.org Subject: [Development] Nominating Kavindra Palaraja for approvership Hi all, I’d like to nominate Kavindra Palaraja as approver. She is a very active contributor and reviewer, in particular for documentation related changes, focusing on the Qt Automotive platform. She’s a former employee of Trolltech and Nokia, and has a lot of experience with Qt’s documentation. Currently, she is employed as tech writer for Luxoft. If you're curious, here's a list of her changes: https://codereview.qt-project.org/q/owner:kpalaraja%2540luxoft.com and a list of changes she's on as a reviewer: https://codereview.qt-project.org/q/reviewer:kpalaraja%2540luxoft.com Best, Paul ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Kavindra Palaraja for approvership
Paul Wicking (Thursday, July 11, 2019 5:27 PM) >> I’d like to nominate Kavindra Palaraja as approver. Topi Reiniö (11 July 2019 17:33) > +1 from me. And another +1 here. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] char8_t summary?
On 11/07/2019 05.05, Mutz, Marc via Development wrote:
> There is a cost associated with another string class, too, and it's
> combinatorial explosion. Even when we have all view types
> (QLatin1StringView, QUtf8StringView, QStringView), consider the overload
> set of QString::replace(), ignoring the (ptr, size) variants:
>
> {QL1V, QU8V, QSV, QChar} x {QL1V, QU8V, QSV, QChar}
>
> that's 16 overloads. And that's without a possible QUtf32StringView.
So?
The right way to handle this is for those methods to be templated, in
which case a) the code only needs to be written O(1) times, not O(N)
times, and b) users can potentially specialize for their own string
types as well.
If done cleverly, even the (pointer, size) variants should be able to
wrap the arguments in a View, such that those method definitions are
trivial.
--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Kavindra Palaraja for approvership
+1 from me too. I have reviewed a number of her doc patches and she would be a good asset to help with approving too! Andy From: Development on behalf of Paul Wicking Date: Thursday, 11 July 2019 at 17:29 To: "development@qt-project.org" Subject: [Development] Nominating Kavindra Palaraja for approvership Hi all, I’d like to nominate Kavindra Palaraja as approver. She is a very active contributor and reviewer, in particular for documentation related changes, focusing on the Qt Automotive platform. She’s a former employee of Trolltech and Nokia, and has a lot of experience with Qt’s documentation. Currently, she is employed as tech writer for Luxoft. If you're curious, here's a list of her changes: https://codereview.qt-project.org/q/owner:kpalaraja%2540luxoft.com and a list of changes she's on as a reviewer: https://codereview.qt-project.org/q/reviewer:kpalaraja%2540luxoft.com Best, Paul ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] char8_t summary?
On Thu, 11 Jul 2019 at 18:43, Matthew Woehlke
wrote:
> On 11/07/2019 05.05, Mutz, Marc via Development wrote:
> > There is a cost associated with another string class, too, and it's
> > combinatorial explosion. Even when we have all view types
> > (QLatin1StringView, QUtf8StringView, QStringView), consider the overload
> > set of QString::replace(), ignoring the (ptr, size) variants:
> >
> >{QL1V, QU8V, QSV, QChar} x {QL1V, QU8V, QSV, QChar}
> >
> > that's 16 overloads. And that's without a possible QUtf32StringView.
>
> So?
>
>
I have nothing to say in this discussion, but just want to throw in one
small hint/request/worry:
please, if it can be avoided, don't add yet another string-related class to
Qt. Knowing when to properly use QString, QByteArray, QLatin1String,
QStringLiteral, QStringRef and QStringView (I may have missed a few) is
already a challenge. And I imagine for people new to Qt it can even be a
strong deterrent (after all, strings are something you tend to use even in
a simple Hello World - the first app most people see or write in a new
language/ framework).
> The right way to handle this is for those methods to be templated, in
> which case a) the code only needs to be written O(1) times, not O(N)
> times, and b) users can potentially specialize for their own string
> types as well.
>
> If done cleverly, even the (pointer, size) variants should be able to
> wrap the arguments in a View, such that those method definitions are
> trivial.
>
> --
> Matthew
> ___
> 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] Nominating Kavindra Palaraja for approvership
+1 ! > On 11 Jul 2019, at 17:27, Paul Wicking wrote: > > Hi all, > > I’d like to nominate Kavindra Palaraja as approver. She is a very active > contributor and reviewer, in particular for documentation related changes, > focusing on the Qt Automotive platform. She’s a former employee of Trolltech > and Nokia, and has a lot of experience with Qt’s documentation. Currently, > she is employed as tech writer for Luxoft. > > If you're curious, here's a list of her changes: > > https://codereview.qt-project.org/q/owner:kpalaraja%2540luxoft.com > > and a list of changes she's on as a reviewer: > > https://codereview.qt-project.org/q/reviewer:kpalaraja%2540luxoft.com > > > Best, > Paul > ___ > 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] char8_t summary?
> please, if it can be avoided, don't add yet another string-related class to > Qt. Knowing > when to properly use QString, QByteArray, QLatin1String, QStringLiteral, > QStringRef and > QStringView (I may have missed a few) is already a challenge. And I imagine > for people > new to Qt it can even be a strong deterrent (after all, strings are something > you tend > to use even in a simple Hello World - the first app most people see or write > in a new > language/ framework). I totally agree. Maybe this helps (I could not find such a document): https://bugreports.qt.io/browse/QTBUG-77020 -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
