| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Callbacks as recommended
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a native dispatch'ed event like key/mouse/touch input
SIGSEGV on use after free of native X11 Display* at XEventsQueued in DisplayDriver.DispatchMessages0.
This potentially happens when an application destroys
the NEWT Window/Display from an action being called directly
from DisplayDriver.DispatchMessages0 (itself), i.e. keyboard or mouse input.
DisplayDriver.DispatchMessages0 stays in the event loop and the next
XEventsQueued call causes a SIGSEGV due to already deleted
display driver connection and hence invalid native X11 Display*.
This issue also exist for other Windowing System drivers,
where the native (dispatch) method sticks to a loop
and still (re)uses the window or display handle.
One is WindowsWindow, where touch events are looped,
but such handler could have closed the window.
Querying the status of a window / display instance before dispatching
is not be good enough
- resource could already be GC'ed, so we also would need to query jobject status
- would imply an addition Java callback
+++
This fix: Having the Java callbacks return
a boolean with the value Window.isNativeValid().
This way the dispatch logic
- can bail out right away w/o using the resource anymore
- must be reviewed by myself due to changed Call{Void->Boolean}*(..)
invocation change.
This review shall resolve potential similar issues.
+++
Tested on X11/Linux/GNU, Windows and MacOS
with new TestDestroyGLAutoDrawableNewtAWT,
which tests all destruction invocation variants.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
size and position via atomic-replacable int arrays
NEWT's Soft-PixelScale supports software pixel-scale by multiplying the underlying surface pixel-size with the scale-factor
and dividing the window position and size by same scale-factor.
Hence the window position and size space is kept virtually steady at virtually assumed DPI 96 at higher actual screen DPI
and the surface size is adjusted.
+++
This window- and pixel-unit separation also includes all callbacks for the native driver implementations,
hence the changes native code - allowing to determine whether window- or pixel-units were given.
|
| |
|
|
|
|
|
| |
TSMGetInputSourceProperty(), crashing on MacOS >= 13
Perhaps we want a replacement?
Fallback code uses keyCode, i.e. dropping the current keyboard layout (-> US).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
insetsChanged + insetsVisibleChanged
|
| |
|
|
| |
argument. Method only changes state.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AppKit NSWindow creation
MacOS 10.14.6 + OpenJDK11U produces occasional freezes on AppKit Main Thread
Latest manual tests after resolving Bug 1389
disclosed a few occasional freezes using NEWT + Java11.
These are related to probable AWT changes since Java8,
as these do not occur with Java8.
Fix: Spun off orderFront0(=setVisible) async off-thread on AppKit after sync AppKit NSWindow creation.
This fix also aligns the macos createWindow code with the new simplified ios implementation,
see commit 004c67c73a0309158c30929cd0d6513e23f34803
|
| |
|
|
|
|
|
|
|
|
| |
- IOSUtil/OSXUtil: Return float value and refine name to GetScreenPixelScale*
- WindowDriver's updateMaxScreenPixelScaleByDisplayID(..) and updateMaxScreenPixelScaleByWindowHandle(..)
will only update the maxPixelScale, as actual user pixelSize change should not be triggered here.
A user pixelSize adaption to the changed underlying scale capabilities (e.g. switch monitor)
should be supported by the implemented WindowDriver's: updatePixelScale(..) called by native code.
|
| |
|
|
|
|
|
|
|
| |
Adding the missing JogAmp copyright tag on certain files.
Currently in debate whether 'JogAmp Community' is a legal Copyright tag in the first place,
we might need to add (or replace it with) my authorship.
However, as authorship is well documented via the git repository,
this should be no real world issue.
|
| |
|
