Re: [Development] QTestLib: sending mouse move and release events outside windows

Ahhh, right. Well, I hope someone who knows this code well can chime in. From: Gatis Paeglis Sent: Monday, 16 April 2018 5:39 PM To: Mitch Curtis ; development@qt-project.org Subject: Re: QTestLib: sending mouse move and release events outside windows > I think that maybe

Re: [Development] QTestLib: sending mouse move and release events outside windows

> I think that maybe we’re talking about different things, because the > functionality works for me (both in the app and testlib), I just want to > disable the warnings. :) Its all related :) > QTest::mouseMove(, QPoint(600, 600)); It is not clear to me what is the expected to happen after

Re: [Development] QTestLib: sending mouse move and release events outside windows

I think that maybe we’re talking about different things, because the functionality works for me (both in the app and testlib), I just want to disable the warnings. :) From: Gatis Paeglis Sent: Monday, 16 April 2018 5:08 PM To: Mitch Curtis ; development@qt-project.org

[Development] Coin maintenance notification

Coin production has been updated with a new baseline today. These are the most fundamental improvements: - Coin now supports common folder split (for instance, changing Linux common scripts no longer causes reprovisioning Mac and Windows machines, etc) - Performance improvements in creation of

Re: [Development] QTestLib: sending mouse move and release events outside windows

> I was thinking of something that would be public API, as any user who wants > to tests drags that end up outside a window will run into the same issue. That kind of API I think requires serious redesign in qtestlib. If you want to drag outside a window and then back to test Enter/Leave

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

> -Original Message- > From: Development [mailto:development- > Keeping release tags is OK for me. Motivation behind my proposal was to stop > planning other release dates than FF & final target. Currently we are trying > to > estimate also alpha, beta and RC release dates and it seems to

Re: [Development] qdds image format

On 16/04/18 12:23, Иван Комиссаров wrote: So, how those issues are checked? Any tool or what? Looking at the email archives: it was fuzzed through AFL. I don't have the test images still around, but in my experience a simple multi-image file was enough to trigger a crash. (I used to see this

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

On mandag 16. april 2018 11.35.28 CEST Jani Heikkinen wrote: > Hi! > > Keeping release tags is OK for me. Motivation behind my proposal was to stop > planning other release dates than FF & final target. Currently we are > trying to estimate also alpha, beta and RC release dates and it seems to >

Re: [Development] QTestLib: sending mouse move and release events outside windows

> That warning message was added by [1]. I have never fully understood the > motivation for that warning. The documentation from [2] does not say if > global coordinates are allowed. I suppose it could be useful if you didn’t intend to send events outside of the window. > QTest sends all

Re: [Development] QTestLib: sending mouse move and release events outside windows

That warning message was added by [1]. I have never fully understood the motivation for that warning. The documentation from [2] does not say if global coordinates are allowed. QTest sends all mouse events down to QWindowSystemInterface, which does expect a window as an argument, or nullptr on

Re: [Development] qdds image format

So, how those issues are checked? Any tool or what? 2018-04-16 0:41 GMT+03:00 Thiago Macieira : > On Sunday, 15 April 2018 12:59:35 PDT Giuseppe D'Angelo wrote: > > Hello, > > > > Il 15/04/2018 18:14, Иван Комиссаров ha scritto: > > >> The usual amount of parsing a

[Development] QTestLib: sending mouse move and release events outside windows

https://bugreports.qt.io/browse/QTBUG-67702 explains that sending mouse move and release events outside of a window causes warnings: void Test::test_case1() { QWindow window; window.resize(400, 400); // Start inside and drag outside (e.g. moving a selection to the edge of a //

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

Hi! Keeping release tags is OK for me. Motivation behind my proposal was to stop planning other release dates than FF & final target. Currently we are trying to estimate also alpha, beta and RC release dates and it seems to cause some delays for us: persons aren't fixing blocker issues or

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

Tuukka Turunen (16 April 2018 08:59) > I very much like continuous flow of snapshots. I don't think anyone is challenging that part of the plan. The only objection to the plan has been to the change in naming. > Sometimes we have a tendency to fall into a "let's wait and get still > this one fix

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

Hi, From a releasing perspective I agree that the set we should update our packages often. We should also stop delivering source only alpha packages, and have binaries from the get go. But from a user perspective, I agree that it's good and important to put a name to those releases so people

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

On 16 April 2018 at 09:43, Simon Hausmann wrote: > Hi, > > Same here. At first this seemed like a good idea, but it becomes awkward when > you look at it from the dev workflow point of view: After fixing a bug, what > is the fix version? Reported in snapshot-24062918 and

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

Hi, I very much like continuous flow of snapshots. Sometimes we have a tendency to fall into a "let's wait and get still this one fix in" mode, which is very inefficient. It is beneficial when making .x patch releases and the fix is for a regression. But in other situations, it is typically

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

Hi, Same here. At first this seemed like a good idea, but it becomes awkward when you look at it from the dev workflow point of view: After fixing a bug, what is the fix version? Reported in snapshot-24062918 and fixed in snapshot-14072918? That sounds like it would create a mess in JIRA.

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

> -Original Message- > On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote: > > And at this same time I want to propose that we stop delivering alpha > > or beta releases and just do snapshots instead. Publishing regular > > snapshots should be done until we are ready for RC. That