Bug 1421: Tackle wrong position of TabFolder, SashForm etc

getClientArea() on MacOS produces a 'difficult' result regarding the position,
which usually is returned as zero.
Using a zero position issues the bug w/ SashForm, where the offset doesn't seems
to be covered by the native NSView nor an SWT parent Composition.

Then using the getLocation() as is (i.e. the view's frame position)
may also cause issues with the TabFolder, as it includes the tab's trimming.
Here the native NSView 's position includes the tab's trimming,
gladly the parent (TabFolder or a Composition)'s clientArea includes this offset.

Therefor, as a testbed - on OSX, getClientArea2(..) returns
- position: getLocation() - getParent().getClientArea().position
- size: getSize()

This at least works OK'sh using
- no special layout parent
- TabFolder
- SashForm

++++

Unit test TestGLCanvasSWTNewtCanvasSWTPosInTabs: Adding 'addComposite' to test matrix.
'addComposite' wraps our GLCanvas or NewtCanvasSWT into a Composite instead of
adding it directly into the layouting parent.

It demonstrates an issue with the new test 'test32_NewtCanvasSWTTabSashGLWComp',
i.e. the NewtCanvasSWT is shown on the left as the SashForm's offset is being dropped.

Summary:
- No more issues with High-DPI pixelScale observed!

- GLCanvas is being most well layouted, no issues in tests

- NewtCanvasSWT may show severe positioning issues -> test32_NewtCanvasSWTTabSashGLWComp
- NewtCanvasSWT always shows a small positioning offset into the lower-right corner w/ overlapping
- NewtCanvasSWT overall positioning is not perfectly understood
- NewtCanvasSWT misses to hide the NEWT child when changing tabs in TabFolder

0 files changed, 0 insertions, 0 deletions