Package sdl.test.gui

Demo to exercise various API in a minimal awt-like gui system.

See:
Description

Interface Summary

GUIHierarchyListener

Class Summary

GUIComponent	for gui demo - unfinished, Minimal Component implememntation for awt-like gui that uses SDL graphics and events.
GUIComponentEvent	for gui demo -unfinished, Custom events for minimal awt-like gui
GUIContainer	for demo gui - unfinished, Minimal Container for awt-like gui based on SDL graphics and events
GUIGraphics	for gui demo - unfinished, Rudimentary prototype for SDL implementation of a java.awt.Graphics object.
GUIHierarchyChangedEvent	for gui demo - unfinished, Used to notify components they have been added to a parents container.
GUIRuntime	for demo gui - unfinished, Rudimentary prototype for SDL implementation of a java.awt.Toolkit object.

Package sdl.test.gui Description

Demo to exercise various API in a minimal awt-like gui system.

Work in progess. Test with sdl.test.gui.unit.Test* As of 09/28/02

• Minimal "Graphics" operation, no clipping yet so we do "updateRawPixels()" after each drawRect(). Slow! but faster than Microwindows
• Minimal containers and components work
• Paint works, but unbuffered, each paint does an updateRect(0,0,0,0) after each draw.
• Native event thread running, but componet level input events no yet captured and fired per component

Big questions?

Why? Because I want to do non-X console guis in java.

Why not j2se1.4 java2d Fullscreen? Because I wanted to do non-X console guis in java without any real/fake X server running.

Can it work for embedded java GUI, games and media players? Maybe, depends what you call embedded and what your constraints are.

Pros
• JSDL can work directly with the framebuffer so you don't need X windows running.
• You have total control over the state of the video and audio devices.
• you can leverage everything else Java can do (JMF, XML, network, threading, etc)

Cons
• Runtime disk space: Only tested this GUI with standard Java 2 VM's (J2SE). J2SE 1.4 requires a ton of storage for all its packages.
• Runtime memory: ditto. The J2SE JVM has a rather sizable ram footprint, even doing a simple System.out.println("hello world");

Why not Java ported to Microwin? Because its DOG SLOW, has a poor widget set and locks the framebuffer for you. What if I wanted to run mplayer in Microwin?

Why not SDL for Perl or Python? Just Because.

Why not a new GraphicsDevice for J2se1.4 instead of a custom gui engine? Good idea. We couldn't do it with 1.2, because even if you successfully registered a new GraphicsDevice, GraphicsContext, etc, you still could not affect java.awt.Graphics. There would be no way to make a component paint(java.awt.Graphics g) to your device. However, if we can now in 1.4, porting Swing would become a non issue.

Why not java for FBDev? Hmmm... I like it, but what about audio?

To get demo to work at the framebuffer console (without Xwindows), see the HOWTO doc on getting SDL to run from the console.