diff options
author | Sven Gothel <[email protected]> | 2020-01-13 06:52:22 +0100 |
---|---|---|
committer | Sven Gothel <[email protected]> | 2020-01-13 06:52:22 +0100 |
commit | 12bbb049b716282321c979ae78918801ef071884 (patch) | |
tree | 39693b99cb6506603fb90dc7c04c6484cc3c1b2b /src/oculusvr | |
parent | e3e671e3ca63235830a2ebf7875650a4c86ce18e (diff) |
Bug 1421, Bug 1358, Bug 969, Bug 672: Fix NEWT's coordinate conversion on MacOS (fixes NewtCanvasSWT on SWT positioning)
Newt's OSX Window consist out of NSView wrapped up within its own NSWindow.
It's position is being set via its NSWindow's client-area position on screen (frame),
which we derive from NSView's client-area position.
When NEWT reparents into a new 'window',
on OSX it uses the parent's NSView and its NSWindow
to attach its own NSView and NSWindow as a subview and childwindow.
SWT's OSX implementation uses NSView's for each Compositor,
but an individual NSWindow is only established for the Shell (Window).
An oversight in Nativewindow and NEWT's coordinate translation:
'top-left view <-> top-left screen'
by missing the 'view <-> window' translation caused this whole issue.
The oversight occured as NEWT's 'view <-> window' translation
had no impact due to its 1-view to 1-window mapping.
Fixing the coordinate translation resolves the mess
for SWT and for potential other toolkits on OSX.
NewtCanvasSWT behaves same on OSX as on X11 etc finally.
Diffstat (limited to 'src/oculusvr')
0 files changed, 0 insertions, 0 deletions