Java2D UI library without Swing, and runs in sandbox

Hi,

Does anyone know of a UI library, or at least a bunch of components that don’t use Swing, are painted using Java2D and can run in the security sandbox?

The closest that I’ve seen is in Pulpcore (http://www.interactivepulp.com/pulpcore/api/). I was thinking of asking David Brackeen if I could rip off his widgets and re-factor them to make it render using regular java2D.

I know about PureSwing (http://www.java-gaming.org/index.php/topic,21430.0.html) but it requires all-permissions.

I also know about the openGL ones (TWL, FenGUI) but I’d like a java2D-rendered UI.

Thanks,
Keith

What do you want to do with it? You can customize Swing components to match your look and feel, so maybe you can elaborate on why you absolutely don’t want to use Swing :slight_smile:

Mostly because swing is a mess. It’s too difficult to control when it is painted, which thread it’s painted in, what events it gets, what is painted.

I’ve hacked it up before to try and make it do direct rendering (rendering outside of the Event Dispatch Thread) but it was very messy, and it is not meant to be done according to the API.

There is the Thinlet GUI library. It was famous for being a single class, not sure if its still the case but is a small fast lightweight java gui.

It also has a slick2d port called Thingle which is useful if you later decide to move over to opengl.

That does look pretty good, thanks for pointing it out. What a pity that it’s GPL :frowning:

How strange, on the Thinlet website it says that it’s GPL, but on the thingle site it says that its LGPL ??? Maybe the old version of thinlet was LGPL…

there is an older version still available here which is LGPL.

Thanks kapta!

I have made a framework in java2d. At this time it is mostly for me but that can be changed.

A brief introduction to its design:
The main class is a Screen. Subclass it for each game state (menu, profiles, high scores, actual game, inventory screen etc). It takes care of updating and painting.
Also it listens (with empty methods like an adapter) to mouse and keyboard, simply override what you need and you will be notified. The screen controls the flow between screens, you can goto and call other screens.

So far nothing special. But, a screen can have what I call SubScreens. A SubScreen is a small rectangle that is painted, updated and informed of input events.
A SubScreen can be invisible. Then it will not be painted(!!!) :slight_smile:
A SubScreen can be disabled, then it will not get input events.
A SubScreen can be focusable, then it can receive keyboard focus. (some other rules for this also applies, if no object have focus, the subscreen under the mouse gets the keyboard events first and can consume it).
A SubScreen operates inside it’s own coordinate system. This means that when it gets mouse events they are translated to be relative its local origo. This also holds true for painting. So paint from 0,0 and then move the SubScreen around, it still works.

I have made a number of special subclasses from SubScreen:
FocusableSubScreen
Label
StyledSubScreen (for widgets that have text)
TextField (single line of editable text)
Button (you still have to paint it to make sense, just override the paint method)
Checkbox

Also, a subscreen can implement the interfaces DragSource and/or DragTarget. When dragged from it returns a Draggable object (interface draggable). When dropped on a SubScreen implementing the DragTarget interface, this object is notified. You still have to do the plumbing behind. But it works very well for the inventory system I am currently working on.

Is this near what you are looking for?

A screenshot showing a multitude of different custom widgets. Most are clickable, some can be dragged etc.

That sounds pretty cool, especially the widgets you’ve made which is what I’m looking for. TextFields are hard to make.

Nice screen shot. I like top-down view games.