| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding QUIRK_BIT_VISIBILITY
1) More visibility detection on post ConfigureNotify events,
since the latter may not yet contain the updated visibility state
as it whould (WM bug!):
- EnterNotify
- LeaveNotify
- Disabled
- Expose
- VisibilityNotify
2) Introducing quirks.
Setting QUIRK_BIT_VISIBILITY to handle the issue where
visibility -> false could not even be set.
|
| |
|
|
|
|
|
|
|
|
|
| |
Handle case where KDE unmaps the window
Update our internal JavaWindow.isMapped according to MapNotify and UnmapNotify.
This takes care of a situation (KDE) where a window is unmapped
during IconicState.
For unmapped windows we cannot interprete _NET_WM_STATE_HIDDEN
and we have to issue XMapWindow for restoring the window.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
at ConfigureNotify event (2)
On gnome shell WM, sometimes KDE WM,
it has been observed that the _NET_WM_STATE_HIDDEN update (visible or invisible)
is not received at ConfigureNotify event.
Turns out the state is finally updated at FocusOut!
This change tests _NET_WM_STATE_HIDDEN visibility hint
for mapped window also for FocusIn and FocusOut events,
besides the ConfigureNotify event.
Further more, NormalState to restore a hidden but mapped
window did not work, so it is no more being sent.
We limit us here to _NET_ACTIVE_WINDOW.
2 unit tests are prepared to test this issue:
- TestGLWindows00NEWT
- TestParenting01NEWT
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_NET_WM_STATE_HIDDEN; setVisible(true) not restoring from _NET_WM_STATE_HIDDEN
Using Gnome Shell 3.14.4-1~deb8u1 disclosed an issue w/ our newly utilized IconicState/_NET_WM_STATE_HIDDEN,
i.e. visibleChanged(false) was never received.
This is a regression of commit 2d837a7a7130702ad36b694875613fae77c7ef06,
which utilizes WM_CHANGE_STATE_IDX + IconicState for visibility
on top-level windows.
This bug consist out of _two_ isssue:
1) setVisible(false) IconicState not listening to _NET_WM_STATE_HIDDEN
Here, we 'listen' to _NET_WM_STATE_HIDDEN when receiving ConfigureNotify
if supported _and_ XMapWindow has been issued.
In such case existence/non-existence of _NET_WM_STATE_HIDDEN determines visibility.
Otherwise, we have wait for MapNotify/UnmapNotify.
The 'XMapWindow has been issued' criteria is tracked by new field 'JavaWindow.isMapped'
and set/cleared when we actually issue XMapWindow/XUnmapWindow!
2) setVisible(true) not restoring from _NET_WM_STATE_HIDDEN
It has been observed that restoring IconicState/_NET_WM_STATE_HIDDEN
via XMapWindow or even NormalState may not work reliably on WMs.
See <https://stackoverflow.com/questions/30192347/how-to-restore-a-window-with-xlib>
Hence we restore from this WM state via NormalState _and_ _NET_ACTIVE_WINDOW.
Both strategies seem to work well on KDE as well as on Gnome.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WindowImpl
- remove updateMinMaxSize(..) - unused info
- fix appendStateToString: show all maximized state changes if reconfig
- add sizePosMaxInsetsChanged(..) and sendMouseEventRequestFocus(..)
accumulating multiple callbacks from impl.
- add: maximizedChanged(..) notification from native impl.
- refine manual maximized mode
used for OSX and Windows (single extent)
- reconfigMaximizedManual(..)
- resetMaximizedManual(..)
X11 WindowDriver:
- Update maximized at xreconfig, read from _NET_WM_STATE
- Use less Java callbacks from JNI
Windows WindowDriver:
- Use native maximized, if HORZ && VERT,
otherwise use manual maximized for single extent.
- Invisible of top-window -> MINIMIZED/ICONIFY
showing the app in task-bar.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
alwaysOnBottom and sticky/all-desktop (Part 1)
Change also implements Bug 1186: 'NEWT Window: Use a Bitfield holding all state flags and expose it accordingly',
since it is essential for an efficient implementation.
Part 1:
- Bug 1186
- Using Bitfield, holding public (Window) and private state bits/mask
- Bug 1188
- Window adds:
- [is|set]AlwaysOnBottom(..),
- [is|set]Resizable(..),
- [is|set]Sticky(..),
- [is|set]Maximized(..),
- isChildWindow(),
- Full implementation for X11
- TODO: Implement for OSX and Windows
- Manual tests:
- TestGearsES2NEWT, TestGearsES2NEWTSimple and TestGearsES2NewtCanvasAWT
utilize new NewtDemoListener, which has a key-listener to perform
all [new] actions. See source code of NewtDemoListener.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ids, ..
RandR 1.3 XRRSetCrtcConfig related:
- X11RandR13 now sets the new screen size via XRRSetScreenSize(..)
- X11RandR13 now propagates RRScreenChangeNotify events
via XRRUpdateConfiguration(event).
Hence reporting virtual desktop size now.
- X11RandR13 now disables the CRTC before XRRSetCrtcConfig(..)
to avoid invalid configuration (see spec)!
RandR 1.3 General:
- Uses unique id named instead of unstable index
for modes and CRTC.
This allows proper identification even for 'swizzled' devices.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Conversion Utilities (Allowing 'arbitrary' PointerIcon data input)
Commit fe28bc125429b38cdcd016746081f4a6d521c6fd added the notion of toolkit agnostic PixelFormat and conversion utilities,
utilized and further tested by this patch.
+++
- PointerIcon is a PixelRectangle
and hence holds the decoded data.
This allows on-the-fly conversion if required
as well as recreation w/o PNG re-decoding.
- Using array-backed PointerIcon data where possible,
allowing better performance when converting PixelFormat etc.
- NEWT Display adds 'createPointerIcon(final IOUtil.ClassResources pngResource...'
method to support agnostic PointerIcon creation.
- NEWT Display adds methods to allow users to avoid PixelFormat and
Buffer NIO type forced conversion:
- PixelFormat getNativePointerIconPixelFormat()
- boolean getNativePointerIconForceDirectNIO()
+++
PNGImage -> PNGPixelRect
Deleted: com.jogamp.opengl.util.texture.spi.PNGImage
Added: com.jogamp.opengl.util.PNGPixelRect
(We hope nobody was using PNGImage directly since it was a service-plugin for TextureIO)
PNGPixelRect is a PixelRectangle
PNGPixelRect actually is implemented OpenGL agnostic,
however - since our PNGJ support lives under package 'jogamp.opengl.util.pngj'
it cannot be moved up (yet).
PNGPixelRect now handles all PixelFormat for the target format
and also added support for grayscale+alpha (2 channels).
The latter is force-converted to RGB* - similar to paletted.
Further more, PNGPixelRect allows simply passing an OutputStream to write the PNG data.
Used by: TextureIO and NEWT
+++
- OffscreenSurfaceLayer's setCursor(..) uses the agnostic PixelRectangle
instead of a PNG resource.
- AWTMisc uses the PixelRectangle to produce the AWT Cursor
and converts it to the required format.
Hence same pixels are used for NEWT and AWT pointer/cursor icon.
- TestGearsES2Newt and NewtAWTReparentingKeyAdapter 'tests'
iterate over 3 custom PointerIcon when pressed 'c'.
- JOGLNewtAppletBase uses the new custom PointerIcon
'newt/data/crosshair-lumina-trans-32x32.png', which is included in NEWT (213 bytes only).
-
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pointer Icons
- Utilizing JOGL's PNG decoder for all icons, if available.
- Application/window icons:
- Providing default application/window icons in 16x16 and 32x32 size
- NewtFactory.setWindowIcons(..) or property 'newt.window.icons' maybe used to override default icons.
- Using icons at application/window instantiation
- Display.PointerIcons:
- NativeWindow Win32 WindowClass no more references a default cursor
in favor of fine grained cursor control [in NEWT]
- Display provides create/destroy methods,
where display destruction also releases open PointerIcon references.
- Window.setPointerIcon(..) sets custom PointerIcon
- Implemented Platforms
- X11
- Windows
- OSX
- Manual Test: TestGearsES2NEWT (Press 'c')
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
key-codes; Respect numpad printable keys; Use keySym for numpad if possible.
- KeyEvent keyCode/keySym values re-ordered!
- Remove VK_KP_<Cursor> numpad key-codes, use general VK_<Cursor> key-codes.
Numpad cursor keys are not supported on some platforms (Windows),
or not configured on most X11 configurations.
- Respect numpad printable keys,
i.e. don't treat them as non-printable.
- Use keySym for numpad if possible.
Numpad keys require modifiers, hence X11 and Windows shall return keySym.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
defined key encoding and simplify usage.
Note, we use one collision to reduce key-code range:
[0x61 .. 0x78] keyCodes [F1..F24] collide w/ ['a'..'x']
Since keyCode/Sym won't use lower capital a-z, this is a no isssue.
KeyEvent:
- 'printable' type is being determined by a nonPrintableKeys table,
while 'action' type is set in case !printable and !modifier.
- public ctor hidden, use create(..) method instead.
This allows us to ensure modifier bit are properly set (incl. the keySym one) w/o performance loss.
- ctor validates that only one of the type flags is set, printable, modifyable or action.
WindowImpl:
- Using IntBitfield of 255 bits to track pressed state,
while removing the repeat state tracking since it is redundant.
The Windows impl. uses a single field to validate whether a key
was already repeated or not.
- Properly cast keyCode short values to int for tracking!
AWTNewtEventFactory, SWTNewtEventFactory:
- Add translation of keyCode/Sym from and to NEWT
- All tested via:
- Newt -> Awt for AWTRobot
- OSX CALayer: AWT -> NEWT
- SWT tests
X11:
- Add VK_CONTEXT_MENU mapping (XK_Menu)
LinuxEventDeviceTracker:
- Fix apostrophe and grave mapping, i.e. to VK_QUOTE and VK_BACK_QUOTE.
Adapted all unit tests, especially:
- TestNewtKeyCodesAWT: More fine grained keyCode ranges to test
using proper keyCode symbols.
|
| |
|
|
| |
dead-keys (zero keyChar); For 'unshifted' keySym's also unmask Ctrl and Mod* states
|
| |
|
|
|
|
|
|
|
|
| |
dependent and UTF-16 keyChar value
On X11, the layout dependent keySym was not delivered [1],
as well as the UTF-8 to UTF-16 translation was missing [2].
[1] is solved using XLookupString w/o ShiftMask
[2] is solved using JNI's NewStringUTF, which takes UTF-8.
|
| |
|
|
|
|
|
| |
Windows and OSX
- X11: Memorize pressed Alt_R to decide which 'alt' has to be used for non key modifier fetching
- Windows: Only use GetKeyState(..) and compare the US vkey, since int. kbd layout use reduced scancode
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
KeyEvent handling while distinguish keyCode (kbd layout independent) and keySym (kbd layout dependent)
API Changes:
- Virtual key codes and symbols are of type short.
- KeyEvent.keySymbol() shall return a layout dependent value (Bug 641)
- Method returns former keyCode() value, which was layout dependent.
- Returns 'short' value
- KeyEvent.keyCode() returns a short value, instead of int
- KeyEvent.keyCode() shall return a layout independent value (Bug 641)
- To ease implementation, we only 'require' the scan code to be mapped to a 'US Keyboard layout',
which allows reusing layout dependent code while preserving the goal to have a fixed physical key association
- Implementation status:
- Windows OK
- X11 TODO
- OSX: 50/50 TODO
- Using layout independent 'action keys'
- Using layout dependent 'printable keys'
- returning above semantics for both, keyCode and keySym
- Android 50/50 TODO
- Returning the layout independent keyCode
- Mapping probably incomplete
- KeyEvent.EVENT_KEY_TYPED and KeyListener.keyTyped(KeyEvent) (Bug 688)
- Marked DEPRECATED
- No more called for auto-repeat events
- Synthesized in WindowImpl.consumeKeyEvent(..): No more injection by native- or java driver code
- NEWTEvent.eventType: int -> short
- field, as well as all method involving eventType changed to short.
- NEWTEvent.isSystemEvent: REMOVED
- Never used as well as never being implemented properly
Internal Changes:
- Simplified keyEvent driver code
- Especially the Windows native driver's mapping code
could be simplified using scanCode and MapVirtualKeyEx
- NEWT Event Factories: hashMap -> switch/case
Unit Tests:
-
- Added NewtCanvasAWT Offscreen Layer Tests
important to test the AWT -> NEWT translation on OSX/CALayer:
- TestNewtKeyCodeModifiersAWT
- TestNewtKeyCodesAWT
- TestNewtKeyEventAutoRepeatAWT
- TestNewtKeyEventOrderAWT
- TestNewtKeyPressReleaseUnmaskRepeatAWT
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Horizontal Scrolling Behavior (OSX, X11, Win32); Bug 639: High-Res Mouse-Wheel
- API update 'float getWheelRotation()':
Usually a wheel rotation of > 0.0f is up, and < 0.0f is down.
Usually a wheel rotations is considered a vertical scroll.
If isShiftDown(), a wheel rotations is considered a horizontal scroll,
where shift-up = left = > 0.0f, and shift-down = right = < 0.0f.
However, on some OS this might be flipped due to the OS default behavior.
The latter is true for OS X 10.7 (Lion) for example.
The events will be send usually in steps of one, ie. -1.0f and 1.0f.
Higher values may result due to fast scrolling.
Fractional values may result due to slow scrolling with high resolution devices.
The button number refers to the wheel number.
- Fix Bug 659: NEWT Horizontal Scrolling Behavior (OSX, X11, Win32)
- See new API doc above
- X11/Horiz: Keep using button1 and set SHIFT modifier
- OSX/Horiz:
- PAD: Use highes absolute scrolling value (Axis1/Axis2)
and set SHIFT modifier for horizontal scrolling (Axis2)
- XXX: Use deltaX for horizontal scrolling, detected by SHIFT modifier. (traditional)
- Windows/Horiz:
- Add WM_MOUSEHWHEEL support (-> set SHIFT modifier), but it's rarely impl. for trackpads!
- Add exp. WM_HSCROLL, but it will only be delivered if windows has WS_HSCROLL, hence dead code!
- Android:
- Add ACTION_SCROLL (API Level 12), only used if layout is a scroll layout
- Using GestureDetector to detect scroll even w/ pointerCount > 2, while:
- skipping 1st scroll event (value too high)
- skipping other events while in-scroll mode
- waiting until all pointers were released before cont. normally
- using View config's 1/touchSlope as scale factor
- Fix Bug 639: High-Res Mouse-Wheel
- getWheelRotation() return value changed: int -> float
allowing fractions, see API doc changes above.
- Fractions are currently supported natively (API) on
- Windows
- OSX
- Android
- AndroidNewtEventFactory ir refactored (requires an instance now) and
AndroidNewtEventTranslator (event listener) is pulled our of Android WindowDriver.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
modified flags and modifier-key events; Simplify Windows key handling
Preface: Modifier-keys are SHIFT, CTRL, ALT and META and they have a matching modifier-bit.
- Simplify Windows key handling
- Employ MapVirtualKey(..) for virtual-key to character and scancode to virtual-key mappings,
allowing to drop tracking of keyCode to keyChar in java code.
This also removes the platform restriction of delivering keyChar at TYPED only.
- Deliver keyChar w/ pressed and released
- Due to the lift restriction on the Windows platform (see above),
we can deliver keyChar w/ all key events on all platforms.
- Deliver proper modified flags and modifier-key events
All modifier-keys deliver pressed, released and typed events
with their modifier-bit set.
The above is covered by unit tests, which passed on X11, Windows and OSX (manual test run).
|
| |
|
|
| |
disturbing and fatal RuntimeException
|
| |
|
|
|
|
|
| |
- X11: Add VK_QUOTE mapping
- OSX: Add single shift, ctrl alt key press;
Fix mapping: Command -> Windows, Option -> ALT, add BACK_QUOTE and QUOTE.
|
| |
|
|
|
|
|
|
|
| |
and w/o auto repeat. Incl. fix for Windows.
Auto-Repeat tests recognizes whether auto-repeat could be triggered by AWT Robot.
The latter is not possible on Windows, hence manual testing was required on this platform.
Impact: X11, Windows and OSX produce proper key sequence incl. auto-repeat modifier mask.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Utilizing a GlobalToolkitLock in general to lock the display connection results in deadlock
situations where locked surfaces signal other [offscreen] surfaces to render.
We have to see whether we find a better solution, for now sporadic XCB assertion still happen.
But it is preferrable to point to the root cause, then to jumping through hoops to complicate locking
or even to deadlock.
Locking:
- X11GLXGraphicsConfigurationFactory add missing device locking in:
- getAvailableCapabilities
- chooseGraphicsConfigurationStatic
- Newt/X11Window: Discard display events after window close.
Relax ATI XCB/threading bug workaround:
- ToolkitProperties: requiresGlobalToolkitLock() -> hasThreadingIssues()
- NativeWindowFactory: Don't use GlobalToolkitLock in case of 'threadingIssues' the impact is too severe (see above)
- NativeWindowFactory: Add getGlobalToolkitLockIfRequired(): To be used for small code blocks.
If having 'threadingIssues' a GlobalToolkitLock is returned, otherwise NullToolkitLock.
- X11GLXContext: [create/destroy]ContextARBImpl: Use 'NativeWindowFactory.getGlobalToolkitLockIfRequired()' for extra locking
Misc Cleanup:
- *DrawableFactory createMutableSurface: Also create new device if type is not suitable
- *DrawableFactory createDummySurfaceImpl: Pass chosenCaps and use it (preserves orig. requested user caps)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
locking, resulting in a native-lock-free impl.
The X11 implementation details of NativeWindow and NEWT used the X11 implicit locking facility
XLockDisplay/XUnlockDisplay, enabled via XInitThreads().
The latter useage is complicated within an unsure environment where the initialization point of JOGL
is unknown, but XInitThreads() requires to be called once and before any other X11 calls.
The solution is simple and thorough, replace native X11 locking w/ 'application level' locking.
Following this pattern actually cleans up a pretty messy part of X11 NativeWindow and NEWT,
since the generalization of platform independent locking simplifies code.
Simply using our RecursiveLock also speeds up locking, since it doesn't require JNI calls down to X11 anymore.
It allows us to get rid of X11ToolkitLock and X11JAWTToolkitLock.
Using the RecursiveLock also allows us to remove the shortcut of explicitly createing
a NullToolkitLocked device for 'private' display connections.
All devices use proper locking as claimed in their toolkit util 'requiresToolkitLock()' in X11Util, OSXUtil, ..
Further more a bug has been fixed of X11ErrorHandler usage, i.e. we need to keep our handler alive at all times
due to async X11 messaging behavior. This allows to remove the redundant code in X11/NEWT.
The AbstractGraphicsDevice lifecycle has been fixed as well, i.e. called when closing NEWT's Display
for all driver implementations.
On the NEWT side the Display's AbstractGraphicsDevice semantics has been clarified,
i.e. it's usage for EDT and lifecycle operations.
Hence the X11 Display 2nd device for rendering operations has been moved to X11 Window
where it belongs - and the X11 Display's default device used for EDT/lifecycle-ops as it should be.
This allows running X11/NEWT properly with the default usage, where the Display instance
and hence the EDT thread is shared with many Screen and Window.
Rendering using NEWT Window is decoupled from it's shared Display lock
via it's own native X11 display.
Lock free AbstractGraphicsDevice impl. (Windows, OSX, ..) don't require any attention in this regard
since they use NullToolkitLock.
Tests:
======
This implementation has been tested manually with Mesa3d (soft, Intel), ATI and Nvidia
on X11, Windows and OSX w/o any regressions found in any unit test.
Issues on ATI:
==============
Only on ATI w/o a composite renderer the unit tests expose a driver or WM bug where XCB
claims a lack of locking. Setting env. var 'LIBXCB_ALLOW_SLOPPY_LOCK=true' is one workaround
if users refuse to enable compositing. We may investigate this issue in more detail later on.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AUTOREPEAT_MASK modifier bit. Refine InputEvent toString(..) and list modifiers by name.
As now described in NEWT's KeyEvent:
+/**
+ * Key events are delivered in the following order:
+ * <ol>
+ * <li>{@link #EVENT_KEY_PRESSED}</li>
+ * <li>{@link #EVENT_KEY_RELEASED}</li>
+ * <li>{@link #EVENT_KEY_TYPED}</li>
+ * </ol>
+ * In case the native platform does not
+ * deliver keyboard events in the above order or skip events,
+ * the NEWT driver will reorder and inject synthetic events if required.
+ * <p>
+ * Besides regular modifiers like {@link InputEvent##SHIFT_MASK} etc.,
+ * the {@link InputEvent#AUTOREPEAT_MASK} bit is added if repetition is detected.
+ * </p>
+ */
|
| |
|
|
| |
ScreenDriver, WindowDriver] to reduce complexity and programatic selection.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
exceptions. Handles also XAWT BadMatch X_SetInputFocus.
X11ErrorHandler code now dumps proper information about the opcode and error message and the running Java thread.
Having propery "nativewindow.debug.X11Util.XErrorStackDump" or "nativewindow.debug=all' set,
a stack trace is dumped.
Since the X11ErrorHandler may catch an XAWT error: BadMatch X_SetInputFocus,
we cannot throw an exception and better keep running.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- NEWT/WindowImpl:
- 'void windowDestroyNotify()' -> 'boolean windowDestroyNotify(boolean force)', allowing to signal a forced close,
as well as replying whether the window has been closed. (called by native code)
- destroy(): set states before releasing the window lock
- NEWT/X11: Pass windowDeleteAtom for reconfigure window, in case of reparenting child to top-level
- NEWT/OSX:
- Add 'BOOL windowShouldClose()' impl., ie. having a chance to reject the close attempt
- Common impl. for 'windowShouldClose' and 'windowWillClose' -> 'windowClosingImpl'
utilizing new 'windowDestroyNotify' code (see above).
Fixes bug 560.
- NEWT/JOGLNewtApplet1Run: Refine out-of browser window behavior for window-close button
- default: move NEWT window back to browser parent
- closeable: close NEWT window
- jogl-test-applets: Add NApplet-Closeable test (Applet out-of browser window is closable)
|
| |
|
|
| |
massive '!!!' occurence
|
| |
|
|
| |
f3f794fe37a7e33a771a4a702f3f46ead4dc6d03: Unresolved symbols. Disable VERBOSE.
|
|
|
- Allow negative window position, using flag 'autoPosition' to mark a custom user position.
This impacts Windows and X11 window creation code, which supports native auto positioning.
- Screen: Validate Screen-Index.
In 'big-desktop' mode the Screen index is always 0. This is true for X11 with
Xinerama enabled and MS-Windows in general.
Platforms w/o multiple Screen support always use index 0.
- X11: Separate X11 Display/Screen/Window native code in their respective C files
- Windows test scripts: use '%*' to catch all arguments
- Add missing (c)
|
