GUI in JOGL, AWT/SWING or SWT port possible?

Schabby · March 19, 2005, 2:50pm

Well, for the frame drawing part, I already wrote some frame drawing methods.

http://user.cs.tu-berlin.de/~schabby/images/GUI_in_JOGL_screeny.JPG

I browsed as well through AWT/Swing a bit today and I agree in your approach. But I don’t completely understand the idea behind java.awt.Toolkit and java.awt.peer.. One passes an AWT/Swing generated component to its corresponding java.awt.Toolkit method and this binds it to the system specific UI component? Why don’t we just forget about java.awt.Toolkit and would simply re-implement JFrame, JComponent, Graphics2D, etc.? Or alternatively, why not porting only java.awt.Toolkit and java.awt.peer. and let Java use our Toolkit class as the “glue” between AWT/Swing and the JOGL ?

Thanks in advance!

zingbat · March 19, 2005, 6:22pm

I don’t understand it very well either. I think that a similar Toolkit class exists on the Xfree86 api so its possible that Sun engs tried to imitate their design. If i recall well on X each window gets its own instance of the toolkit and can have its own color format or something.

From the AWT library docs:

This class is the abstract superclass of all actual implementations of the Abstract Window Toolkit. Subclasses of Toolkit are used to bind the various components to particular native toolkit implementations.

Many GUI operations may be performed asynchronously. This means that if you set the state of a component, and then immediately query the state, the returned value may not yet reflect the requested change. This includes, but is not limited to:
* Scrolling to a specified position.
  For example, calling ScrollPane.setScrollPosition and then getScrollPosition may return an incorrect value if the original request has not yet been processed.

* Moving the focus from one component to another.
  For more information, see Timing Focus Transfers, a section in The Swing Tutorial.

* Making a top-level container visible.
  Calling setVisible(true) on a Window, Frame or Dialog may occur asynchronously.

* Setting the size or location of a top-level container.
  Calls to setSize, setBounds or setLocation on a Window, Frame or Dialog are forwarded to the underlying window management system and may be ignored or modified. See Window for more information. 
Most applications should not call any of the methods in this class directly. The methods defined by Toolkit are the “glue” that joins the platform-independent classes in the java.awt package with their counterparts in java.awt.peer. Some methods defined by Toolkit query the native operating system directly.

The main purpose of the toolkit is to have all methods that call native os services or create native os object (called peers in AWT jargon) accessible from a single class.

If you look into the Toolkit methods you will notice that these methods include all the basic functionality that something like Glut, for example, would provide.

There are methods to:

register event listeners
emit a beep sound
using the old image model
create a lot of useless peers when we would only need a native window
accessing cursor details for the os
using system dragndrop native features
using native font services
using print job native features
bean like properties
screen device details
using native clipboard services
system colors
native event queue
sync graphics state

So in short the Toolkit is a big mess that tries to include every cool feature found in most popular os. Even if the programmer doesn’t require that stuff the Toolkit will still alocate resources for it.

A good model would be to have the Toolkit have functions for query/open/close os services (interfaces instantiated by native classes) and use the service interfaces to access those os features.

From the Toolkit docs there would be PrintJobServices, InputDeviceServices, OutputDeviceServices, ClipboardServices, DesktopPropertiesServices, DragnDropServices, FontLibraryServices, GraphicsSevices, ImageTranscodingServices.

From the previous paragraph i can see that there would be a lot of services that didn’t really belong in a gui api like Swing so it would’t make much sense to have it in there or it would not make much sense to have the SwingToolkit at all but some other class like JavaKernel or something.

Ok so i have just messed up this entire thread. 8) But really don’t feel you have to follow the Toolkit thing or make a SwingToolkit class altogether. Its probably better not to remake the same mistakes the programmers of AWT did in the past. Anything from JComponent bellow is probably better be ignored.

Schabby · March 19, 2005, 11:16pm

Captains Log, star date 1: The first day on duty

To get started somehow, I made a plane copy of the swing source tree.
I renamed the javax.swing package stem to joglswing and let Eclipse change all the package declarations in the classes.
Changed all imports that target on javax.swing to joglswing (actually process is still going on, since my Ant script that is supposed to do it for me isn’t done yet).

zingbat · March 20, 2005, 4:04pm

If you are going for it, it would be cool to request a project:

https://games.dev.java.net/

See the “Request Project” in the top left box with all the links. Then you get your own cvs space and other users of this site can help you.

Schabby · March 21, 2005, 3:39am

Great idea! My master thesis and university stuff would indeed appreciate to get more attention.

c_lilian · March 21, 2005, 4:32am

java.net project : wouldn’t you be facing license problems ? (forking a non open source library ?)

Lilian

Schabby · March 21, 2005, 5:12am

Hmm :-[ I have no idea… Could somebody comment on this who is more familiar with SUNs license for javax.* than me?

Much appreciation in advance

Schabby · January 28, 2006, 2:19am

Hi!

Not sure if anyone still remembers this thread…

Well… After almost one year I want to let you know that I did as I have been told ;D I baptised the project FengGUI which is a malapropism for Feng Shui (you know, the ancient Chinese philosophy about dead people and positioning furniture). It is still not done yet but it is coming to a stage where it makes sense to use it.

With the rollout of the Swing-Jogl Bridge, we had to realign FengGUIs mission a bit. It addresses developers who want a super-leightweight, fast, really customizable and well integrated GUI in their OpenGL app. It currently supports LWJGL 0.99 and JOGL/JSR 231 Beta 02. Ok, sounds a bit like from a sales representative . Maybe you can check it out once in a while.

Johannes

zingbat · January 28, 2006, 9:58pm

Hey thats cool. I will give it a good look. I was going to to do something like this for myself but i may just use FengGUI instead.

Schabby · January 29, 2006, 3:55am

great! Let me know if you have any problems using it and/or you miss a feature.

I uploaded a new Nightly Build Yesterday evening containing enhanced key handling for text areas. I am going to complete that today (I guess I will merge Text Fields and Text Areas to one Text Widget like in SWT).

The next thing to tackle will be to improve the font support by providing a font-texture loader and saver as well as a font-prerenderer toolkit that maps fancy colored characters on textures. I suppose that’s something many people need.

Johannes