Re: [Development] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441

[Thiago Macieira]

On Tuesday, 26 May 2020 10:33:21 PDT Edward Welbourne wrote:
> While I'm a linear algebraist ... and aware that the orthodoxy of
> graphics programming does things "a bit differently" than linear
> algebraists do, but allegedly for good reasons (that I might one day
> learn).  It's just the same thing written differently.

[∞] ⎡ 0 1⎤=[8]
⎣-1 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] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441

[Matthew Woehlke]

On 26/05/2020 13.33, Edward Welbourne wrote:

It turns out that either way round works
fine, as long as you're consistent.  Which QTransform appears to be; and
its docs correctly describe it the way it is.


They are? It was *not at all* clear to me in what order the transforms 
would be applied. I will happily argue that the documentation in its 
current state is inadequate.


I can also happily argue that that is, indeed, the only actual "bug" here.

--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441

[Edward Welbourne]

On Tuesday, 26 May 2020 09:17:05 PDT Edward Welbourne wrote:
>> (Matrix multiplication isn't commutative.)

Thiago Macieira (26 May 2020 18:42)
> This more or less summarises all I remember from matrix classes from high
> school.

While I'm a linear algebraist ... and aware that the orthodoxy of
graphics programming does things "a bit differently" than linear
algebraists do, but allegedly for good reasons (that I might one day
learn).  It's just the same thing written differently.

>> I'll try to work out whether QMatrix / QTransform are consistent about it

It seems QTransform was the only one in question here; and its matrices
are the transposes of what I would have expected; hence its
multiplication happens in the reverse of the order I expected.  This is
a self-consistent way to do things, just confusing to those who think
they know how matrices work.  It turns out that either way round works
fine, as long as you're consistent.  Which QTransform appears to be; and
its docs correctly describe it the way it is.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441

[Thiago Macieira]

On Tuesday, 26 May 2020 09:17:05 PDT Edward Welbourne wrote:
> (Matrix multiplication isn't commutative.)

This more or less summarises all I remember from matrix classes from high 
school.

> I'll try to work out whether QMatrix / QTransform are consistent about it

Thanks, Eddy.

-- 
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] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441

[Edward Welbourne]

Thiago Macieira (26 May 2020 18:06) wrote:
> Neither QMatrix nor QTransform have seen any change since the Qt 5.0
> repository import that was related to the underlying math. Only licensing
> and C++ updates.
>
> The task https://bugreports.qt.io/browse/QTBUG-84441 is claiming there's
> some wrong math or at least unexpected behaviour. Can someone who
> understands these classes take a look?

I'll comment.
It's down to the confusing nature of what the order of operations is.
(Matrix multiplication isn't commutative.)
I'll try to work out whether QMatrix / QTransform are consistent about it ...

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441

[Matthew Woehlke]

On 26/05/2020 12.06, Thiago Macieira wrote:

On Tuesday, 26 May 2020 08:59:09 PDT Thiago Macieira wrote:

Neither QMatrix nor QTransform have seen any change since the Qt 5.0
repository import that was related to the underlying math. Only licensing
and C++ updates.

The task https://bugreports.qt.io/browse/QTBUG-84457 is claiming there's
some wrong math or at least unexpected behaviour. Can someone who
understands these classes take a look?


Updated subject: https://bugreports.qt.io/browse/QTBUG-84441 is the right
task.


The documentation is not clear if the scale, rotate, etc. methods of 
QTransform apply *before* or *after* whatever the QTransform is already 
doing. The bug report indicates that they are applied *first*.


Given the potential for breaking existing code which expects the current 
behavior, my inclination would be to clarify the documentation to 
clearly state the existing behavior.


(Note: I didn't actually test this myself or look at the code, I am just 
going off of what the bug report says. In any case, however, the 
documentation should be fixed.)


--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441

[Thiago Macieira]

On Tuesday, 26 May 2020 08:59:09 PDT Thiago Macieira wrote:
> Neither QMatrix nor QTransform have seen any change since the Qt 5.0
> repository import that was related to the underlying math. Only licensing
> and C++ updates.
> 
> The task https://bugreports.qt.io/browse/QTBUG-84457 is claiming there's
> some wrong math or at least unexpected behaviour. Can someone who
> understands these classes take a look?

Updated subject: https://bugreports.qt.io/browse/QTBUG-84441 is the right 
task.

-- 
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] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84457

[Thiago Macieira]

Neither QMatrix nor QTransform have seen any change since the Qt 5.0 
repository import that was related to the underlying math. Only licensing and 
C++ updates.

The task https://bugreports.qt.io/browse/QTBUG-84457 is claiming there's some 
wrong math or at least unexpected behaviour. Can someone who understands these 
classes take a look?

-- 
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] QInputEvent refactoring

[Shawn Rutledge]

> On 2020 May 26, at 17:27, Shawn Rutledge  wrote:
>  If it worked with a native swipe gesture instead, maybe it would only 
> receive the gesture if you are swiping from the screen edge, and only on 
> certain platforms.

But the swipe gesture can be something else on touchpads, come to think of it; 
so maybe that’s useful on desktops after all.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QInputEvent refactoring

[Shawn Rutledge]

> On 2020 May 26, at 16:27, Henry Skoglund  wrote:
> Hi, I tried some QGestureEvents this winter in my first Qt iOS app, and got 
> bored having to use 3 fingers on my iPhone for swiping (1 finger seems to be 
> the norm on Android and iPhones). And I discovered that it was pretty easy to 
> integrate the vanilla standard iOS 1-finger swiping with Qt, see 
> https://bugreports.qt.io/browse/QTBUG-81042 
> 
That sounds like what we have been using QNativeGestureEvent for.  The plugin 
should probably call QWindowSystemInterface::handleGestureEvent() or 
handleGestureEventWithRealValue() rather than directly posting a QGestureEvent. 
 So far only the cocoa plugin does that, though.

Do you have to swipe from the edge of the screen with one finger?  Then I 
wonder if that would work well on a desktop if your window isn’t maximized.  
Like with Drawer in Controls… swiping from the edge is fine when you can feel 
the edge, but opening a Drawer with the mouse isn’t much fun, and opening it on 
a desktop touchscreen isn’t either, if the edge of the window is in the middle 
of the screen.  (You might resize it instead, or end up pressing some other 
window and changing focus, or…)  But Drawer works with mouse and touch events: 
you simply start dragging an invisible item along its edge.  If it worked with 
a native swipe gesture instead, maybe it would only receive the gesture if you 
are swiping from the screen edge, and only on certain platforms. (Maybe it 
should handle that too though, optionally?)  So it’s a bit confusing when you 
need a gesture recognizer and when you need to use raw events.

The old gesture framework started out assuming that it could only get raw 
events, and also with a very ambitious goal of being able to detect any kind of 
gesture from any kind of event.  So it filters all events, just in case one of 
the recognizers might be able to detect a gesture in any part of the event 
stream.  Thus it is a bottleneck, and slows down all event delivery slightly.  
That’s what’s wrong with the architecture.  But for the sake of widget API, 
QNativeGestureEvents can also turn into QGestureEvents during delivery.  I 
haven’t dug too deeply into the impact on widget API if we get rid of the 
gesture recognition framework in Qt 6.  I think widgets ought to be able to 
handle QNativeGestureEvent just as well as Qt Quick does, as long as they get 
delivered properly.  But at that point, maybe we might as well rename it back 
to QGestureEvent?  Either way we can probably say that the future is for most 
gestures to be native.  Either you process raw touch events in leaf 
items/widgets, or you get a gesture event that the OS has already recognized.  
Qt Quick does both.  But the more we depend on the OS to recognize gestures, 
the more we need every platform to provide them.  So eventually we might need 
to find or write another gesture recognition engine just for use on platforms 
that don’t already have one.  (Although now that libinput does it, maybe that’s 
good enough on Linux.  Someone contributed a WIP patch for that already, too.)  
I think gesture recognizers should live below the QPA interface though, 
probably not in QtGui and certainly not in the widget module (as the existing 
one does), because the main desktop platforms won’t need it.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt Design Studio 1.5 is released

[Thomas Hartmann]

Hi all,

We released Qt Design Studio 1.5 today, see 
https://www.qt.io/blog/qt-design-studio-1.5-released

Big thanks to everyone involved!

Best Regards,
Thomas Hartmann
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt 5.15.0 released

[Jani Heikkinen]

Hi all!

We have released Qt 5.15.0 today. More information about the release can be 
found from Qt 5.15.0 release blog post: https://www.qt.io/blog/qt-5.15-released

Big thanks to everyone involved!

br,
Jani Heikkinen
Release Manager

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development