Changes

Bug 1421: NEWT OSX Invisible: Refining child window visibility setting, commenting on child-window orderOut

Actual small change is to have child-NSWindow to use '[myWindow orderWindow: NSWindowAbove relativeTo:..'
instead of 'orderFront' in creation and use the simple 'orderFront' to set a top-level NSWindow visible.

Adding comment why we can't use 'orderOut' on child-NSWindow setting it invisible,
this is due to OSX 10.7 changes and testing detaching the child-window from its parent
causes havoc w/ SWT at least.
Hence we only issue 'mWin orderWindow: NSWindowOut relativeTo:..]' and the result is
having the child-NSWindow below the application.

This in turn will make it visible again when moving the application around,
as this child-NSWindow will no more follow the position.

Suggestion is to have this 'fake invisible' child-NSWindow to be moved
out of the overal viewport (all screens).

NEWT OSX/IOS WindowDriver: Minor cleanup of local var usage (prefer reuse); reconfig: Only orderOut w/ valid window-handle

NEWT OSX MacWindow.c: Add parentWindow to DBG_PRINT

Bug 1421: NEWT OSX Invisible: Fix orderOut0 re commit d92dc518eb891f2d125a8136efd6ed603d74a6e9

We also cannot use 'mWin orderWindow: NSWindowOut relativeTo:..]' as it also removes the child-NSWindow from its parent like 'orderOut'.
Hence only use 'orderBack' to keep the relationship inplace.

Fake invisible child window is in progress,
i.e. moving it out of the overal viewport (all screens).

Bug 1421: NEWT OSX Invisible: Implement 'Fake invisible child window'

'Fake invisible child window' is implemented by simply moving the window out of sight (viewport).

- orderOut0 needs to use '[mWin orderWindow: NSWindowBelow relativeTo:..' parentWindow
  instead of '[mWin orderBack:..', otherwise the whole parent application gets invisible w/ SWT ;-)

- NewtNSWindow may also needs to use parent's Screen instance if moved offscreen,
  as the own Screen is invalid (zero size) in this case.

- WindowDriver: Adding special treatment for 'Fake invisible child window' (tagged as such):
-- reconfigureWindowImpl: setWindowClientTopLeftPointAndSize0(..) will be called
   using the viewport's max position -> out of sight.
-- screenPositionChanged: ignore the 'new' position
-- sizeChanged: ignore the 'new' size

This sensitive NEWT change set shall benefit other toolkits being used as parentWindow
besides SWT, as this behavior is the same across MacOS.

NEWT.Window: Add 'StringBuilder append(StringBuilder sb)' supporting building custom efficient presentations

Bug 1421: NEWTCanvasSWT: No action on SWT.Activate, use SWT.FocusIn. Also remove all SWT listener on dispose.

Additionally print more details about the newtChild's state in DEBUG mode.

Bug 1421: Conclude OSX: Forward SHOW and HIDE events to NewtCanvasSWT instances if 'below notification threshold'

'below notification threshold' here is simply being a child SWT Control of like a Composition or SashForm etc
where these events won't get propagated.

Bug 1421: NEWT OSX Invisible: Refine 'Fake invisible child window' off-viewport position

Ensure it stays out of sight by moving it to 2x width/height of viewport.
Otherwise one could see the child window moving from lower-right to upper-left ;-)

TestGLCanvasSWTNewtCanvasSWTPosInTabs: Only use 1 Animator to easy example code

Otherwise one would want to pause the Animator instance for the hidden GLWindow,
otherwise such animator with zero visible drawables will become a CPU hog.

Nativewindow Rectangle*: Cleanup up union(..), intersection(..): Return a new Rectangle instance (mutable)

Also return 'this' for setter methods for chaining.

Bug 1422: Emulate DPI Scaling on non-native DPI autoscale platforms (!MacOS)

Bug 1422 shows that it seems to be desired to emulate DPI scaling where
the native toolkit does not implmement the same.

On GTK, DPIUtil.mapDPIToZoom (int dpi) reads:
  double zoom = (double) dpi * 100 / 96;
  int roundedZoom = (int) Math.round (zoom);
  return roundedZoom;

While having dpi calculated as:

  dpi = 96 * GDK.gdk_monitor_get_scale_factor(monitor);

Well, this seems to exist to allow 96 dpi fixed layout to
'look' OK on high-dpi screens.
However, you get in trouble if you layout high-dpi aware,
i.e. using percentages etc.

There is one exception: If DPIUtil.useCairoAutoScale() is true, scalingFactor is 1f
and hence the scaling emulation dropped.

'DPIUtil.setUseCairoAutoScale((sx[0]*100) == scaleFactor || OS.isGNOME);'