|
Administrator
|
bvj asked about a way to use JOGL within JavaFX [1.3].
Not to hijack his thread, I like to open a new where I like to discuss
viable ways to use a UI within JOGL.
A UI toolkit should be agnostic (as possible) in regards to the
windowing toolkit (NEWT) and maybe event to the rendering toolkit (JOGL).
So allow me to start with the Windowing Toolkit.
(REQ-WinTK-01) Windowing Toolkit: Seamless integrations into the underlying native one.
The following sub requirements shall be implemented if supported by the
underlying native windowing toolkit.
Proper behaviour in case of lack of support, shall be achieved.
NEWT covers sub-requirements [01-01 .. 01-06] already.
(REQ-WinTK-01-01) Creation/Destruction of top level and child windows
(REQ-WinTK-01-02) Multithreaded Window Surface Access
(REQ-WinTK-01-03) Parenting and Re-Parenting
(REQ-WinTK-01-04) Decorated- or Undecorated - Windows
(REQ-WinTK-01-05) Passive Fullscreen Mode, no change of display mode
(REQ-WinTK-01-06) Event handling, at least per creation thread (-> REQ-WinTK-01-01)
(REQ-WinTK-01-07) Transparency
- API prepared
(REQ-WinTK-01-08) Active Fullscreen Mode, change of display mode
- API prepared
(REQ-WinTK-01-20) Drag & Drop
- Pending
+++++
Phenomenon for a UI toolkit may start with the following:
(REQ-UITK-01) UI Toolkit: Generic UI Object Rendering
(REQ-UITK-01-01) Should be abstracted from the windowing toolkit.
(REQ-UITK-01-02) Should support multithreading (-> REQ-WinTK-01-02)
(REQ-UITK-01-02) Should include implementation using native rendering TKs (JOGL, ..)
(REQ-UITK-01-03) Render primitives on a 2D plane
(REQ-UITK-02) UI Toolkit: User Interaction
(REQ-UITK-02-01) Should be abstracted from the windowing toolkit -> Events.
(REQ-UITK-01-02) Mouse feedback from a picked 2D plane
REQ-WinTK-01-02 and REQ-UITK-01-01 already reject AWT/Swing usage.
REQ-UITK-01-03 and REQ-UITK-01-02 almost request at least a little basic scenegraph,
or an offscreen UI rendering (texture) approach will be used.
It may turn out that a seamless integration of a UI
cannot be completely application independent, since such application
already utilized a scenegraph and some meaning of UI.
IMHO the only generic UI TK path would be supporting offscreen
rendered UI elements, the application may add on a 2D place in the scene
and propagates events to the UI TK event dispatcher.
Additionally we could just offer such a 'realizer' adapter for simple applications,
ie render the UI textures and propagating catched events on it's plane.
Please join and discuss these ideas here,
I would think that the above requirements could suit most use cases.
Cheers, Sven
|
Locked
