| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
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 ;-)
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
remove all SWT listener on dispose.
Additionally print more details about the newtChild's state in DEBUG mode.
|
|
|
|
| |
building custom efficient presentations
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'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.
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
| |
reconfig: Only orderOut w/ valid window-handle
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
| |
independent UI interaction coding
|
|
|
|
|
|
| |
deadlocks on OSX and Windows
Essentially same code path as NewtCanvasSWT
|
|
|
|
|
|
| |
(its a property!)
Missed the SWT headless unit tests altogether ;-)
|
|
|
|
| |
pattern
|
|
|
|
|
| |
Show and Hide handling resolves TabFolder layout,
i.e. hiding the 'hidden' and showing the current tab.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
b91c680fb93a03720ff9fcb39cf052cfe8d40e76
See commit b91c680fb93a03720ff9fcb39cf052cfe8d40e76
To support static libraries JEP 178, we have to provide JNI_OnLoad_<libname> etc.
Hence change and add function entries accordingly.
|
|
|
|
|
|
| |
This also demonstrates that on non MacOS, SWT's scale-factor is artificially imposed
on the actual pixel-units, as SWT's getClientArea() is simply returning:
DPIUtil.autoScaleDown(getClientAreaInPixels())
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
| |
'setNEWTChild(..)'
|
|
|
|
| |
position
|
|
|
|
| |
Due to issues on MacOS, added the src.zip for MacOS as well.
|
| |
|
|
|
|
|
|
| |
TestGLCanvasSWTNewtCanvasSWTPosInTabs (2/2)
Complete merging unit tests.
|
|
|
|
| |
setBounds(..)
|
|
|
|
|
|
| |
gets realized on MacOS
This fixes GLCanvas's High-DPI scaled size issue on MacOS of Bug 1358.
|
|
|
|
| |
get[Location|Size]InPixels(..) and getLocationOnScreen()
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TestGLCanvasSWTNewtCanvasSWTPosInTabs (1/2)
Testing the TabFolder and a SashForm in the 2nd tab
covering both SWT layout use cases on both out SWT support classes SWT GLCanvas and NewtCanvasSWT.
Merging TestBug1421NewtCanvasSWTPosInTabs + TestBug672NewtCanvasSWTSashFormComposite
into TestGLCanvasSWTNewtCanvasSWTPosInTabs.
TestBug672NewtCanvasSWTSashFormComposite exposes that SWT GLCanvas
still requires work for proper High-DPI scaling on OSX!
|
|
|
|
| |
regardless of High-DPI
|
|
|
|
| |
layout using NewtCanvasSWT on MacOSX with High-DPI Retina
|
|
|
|
| |
cross-compilation 32bit on 64bit
|
| |
|
|
|
|
| |
compilation - as 32bit builds are no more supported since SWT 4.10
|
| |
|
|
|
|
| |
reverting commit cb092e517461b3047c966c38e92668010a3b7ef6
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even w/ commit fb211581fefc994d1458a2a74801dfb937170f39, propagating the SWT pixelScale to NEWT-Child,
hasPixelScale was never updated via updatePixelScale() through native callback [NSView viewDidChangeBackingProperties]!
[NSView viewDidChangeBackingProperties] not being called on [created] child windows (NewtCanvasSWT)
confused the overal pixelScale state, i.e. no hasPixelScale update via updatePixelScale(..).
This change explicitly queries OSXUtil.GetWindowPixelScale(handle) (commit e6d53e29f05a6928192f6c4a988b2aa558be8d65)for:
1) updateMaxScreenPixelScaleByWindowHandle(..), which now updates the actual hasPixelScale after native creation
and for
2) setSurfaceScale(..), which directly calls updatePixelScale(..) with the queried actual pixelScale
instead of relying on the native callback [NSView viewDidChangeBackingProperties].
|
|
|
|
|
|
|
|
|
| |
utilize it for convertTo*Units(..)
Detected pixelScale on SWT should be propagated to the NEWT Child
using 'newtChild.setSurfaceScale(pixelScale)' to allow an impact.
Also utilize computed pixel for converTo*Units(..) implementation.
|
|
|
|
|
|
|
|
| |
pixel-units
Commit ca7f0fb61b0a608b6e684a5bbde71f6ecb6e3fe0
did one thing wrong: Using the pixel-unit size for
NEWT child window operations where window-units are required.
|
|
|
|
|
| |
It is now possible to retrieve the pixel scale [NSWindow backingScaleFactor]
after native creation by NEWT - as we have changed the lifecycly (all-in-one native method on AppKit)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lib lookup
New property 'jogl.ffmpeg.lib' may be set to 'internal',
setting PREFER_SYSTEM_LIBS:=false (default it true)
Non system internal libraries are named 'internal_<basename>',
e.g. 'internal_avutil'.
System default libraries are named '<basename>',
e.g. 'avutil'.
If PREFER_SYSTEM_LIBS is true (default),
we lookup the default library first,
then the versioned library names and last the internal library.
If PREFER_SYSTEM_LIBS is false,
we lookup the internal library first,
then the versioned library names and last the default library.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specialization
On MacOS, commit 12eed5d38616d23b6e8e2e5b497dfc2f54d90c90 replaced all
parent.getLocationOnScreen(..) calls with OSXUtil.GetLocationOnScreen(parentHandle, ..)
avoiding the EDT + Appkit Deadlock with native parenting.
On MacOS AWT and JAWT are using offscreen CALayer since Java >= 1.7.0,
therefor the MacOSXJAWTWindow's native window handle can't be used to gather
the screen position via OSXUtil.
However, the JAWT Window specialization MacOSXJAWTWindow implements a non-locking code-path
and we can decide to use it by querying the general interface OffscreenLayerOption.
|
| |
|
|
|
|
| |
of -DisIOS*=true
|
| |
|