| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
XPeekEvent(..)
The wait loop uses XPeekEvent(dpy, &e),
which can block indefinite if queue is empty.
Replace with timeout only _and_ only wait on CreateWindow0(..)
not when queried via X11Display dispatch loop on events
when it is assumed the information has been propagated already.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I got access to a touchscreen laptop w/ Debian 9, hence I could fix and test the implementation.
X11 DisplayDriver.java:
- Store and pass through xi_opcode of XI extension, queried at initialization stage
X11Window.c Fixes:
- Initialize JavaWindow's xiTouchCoords[].id w/ -1, as required to track the pointer
- Pass through xi_opcode as stored in X11 DisplayDriver
X11Display.c Fixes:
- sendTouchScreenEvent: Throw RuntimeException if 0 > actionId (Internal Error: based on xiTouchCoords[].id tracking)
- DispatchMessages's windowPointer determination:
-- Query potenial XI Event first: IF XI Event, must use XIDeviceEvent's event Window
-- Only IF not an XI Event, we can use evt.xany.window as the event window
- DispatchMessages's XI Event Handling:
-- Always break deviceid search loop if id found, preserving index and time spend
Works on my Debian 9 device, tested w/ com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT:
- One pointer (finger) press, drag and release (click)
- PinchToZoomGesture works
- DoubleTabScrollGesture works
+++
Potential Issues:
JavaWindow's xiTouchCoords[].id accuracy is crucial to pointer tracking
during XI_TouchBegin -> XI_TouchUpdate -> XI_TouchEnd.
In the normal course of action:
- XI_TouchBegin sets the id, assuming it is yet set
- XI_TouchUpdate assumes it is set
- XI_TouchEnd clears the id, assuming it is set
This field in the JavaWindow array only gets reset to -1 once at native window
creation. We may need to figure out when to reset this field to -1.
If the XI_TouchEnd events would get lost for whatever reason,
the above tracking state would be broken.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
92006e4baef57f1f3fb647dd307aed5989fd4c8d
Previous commit 92006e4baef57f1f3fb647dd307aed5989fd4c8d
(Note to Danny: I cannot test this now - please re-test and/or review)
X11Common::JavaWindow
- Owns XI extension's xiOpcode, selected xiTouchDeviceId and tracked XITouchPosition array
X11Window::CreateWindow
- Query XI extension only once @ window creation and earmark xiOpcode in JavaWindow instance
- Fix: Device selection code was "class->type != XITouchClass",
but shouldn't it be 'XITouchClass == class->type' (as patched here)
- Fix: Free XIQueryDevice returned XIDeviceInfo array via XIFreeDeviceInfo
- Earmark deviceid in JavaWindow instance
X11Display
- Moved global static touch_coordinates to JavaWindow::xiTouchCoords instance
X11Display::DispatchMessage
- Changed event handling structure similar to https://keithp.com/blogs/Cursor_tracking/
- Fix: Free XGetEventData's optional memory allocation via XFreeEventData
- Reuse JavaWindow's queried xiOpcode
- Fix: Don't overrise windowPointer, instead validate and require a match. JavaWindow must match!
- Fix: Also validate chosen deviceid with JavaWindow's registered device
Newt Build:
- Added libXi in build recipe and doc
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
start RandR13 coding.
|
| |
|
|
| |
to pluggable impl. for RandR 1.1 and 1.3 (todo)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
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.
|
| |
|
|
| |
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)
|
