Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (526)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (593)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  GUI in JOGL, AWT/SWING or SWT port possible?  (Read 4749 times)
0 Members and 1 Guest are viewing this topic.
Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Posted 2005-03-09 03:09:55 »

Hi,

I need a sophisticated GUI (you know, Buttons, Lists, Tables, Frames and so on) in my JOGL app and I'm wondering whether there exist already some library for that.

If not, wouldn't it be possible with relatively small effort to implement the low level drawing functions of the AWT (or Eclipse's SWT) for JOGL so that every GUI component is drawn on a JOGL GLCanvas?

Offline cylab

JGO Ninja


Medals: 55



« Reply #1 - Posted 2005-03-09 08:05:42 »

Do you really need those GUI-Elements on the canvas? If not, you just put your Canvas on a Frame and use AWT like normal (and even Swing with some "workarounds" regarding heavyweight  vs. lightweight components)

Mathias - I Know What [you] Did Last Summer!
Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Reply #2 - Posted 2005-03-09 08:36:26 »

Quote
Do you really need those GUI-Elements on the canvas?

Yes, for two main reasons:

I would like to run my program in fullscreen mode. Only one frame can be put in fullscreen mode and for instance overlapping dialogs are not possible.

In addition, I would like to make use of the advantage of the depth buffer. The objects that are below a window do not need to be rendered.

I know that there is a trick with this pseudo fullscreen mode where you use an undecorated JFrame which size matches exactly the screen. But I believe this does not tell OpenGL not to render the things that are below a GUI component.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online princec

« JGO Spiffy Duke »


Medals: 425
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2005-03-09 08:52:48 »

Well, there's the Shaven Puppy GUI (Spaghetti) but that's for LWJGL and you'd need to port it to JOGL, but it does more or less the kinds of things you want within reason.

Cas Smiley

Offline DaveLloyd

Junior Devvie




Making things happen fast with Java!


« Reply #4 - Posted 2005-03-14 11:08:53 »

I've had a go at using Swing to write into the GL buffer with only moderate success - part of my desire here is to have transparent swing panels over my main display. You can also map a swing panel onto a 3d object which makes for some interesting UI interactions. Project Looking Glass and Xith3D have working models for this and all use a bitmap buffer to get swing to write in and then texture map (or raster map) this onto the gl buffer. Can be rather slow for big panels as that means a lot of pixel copying (and argb <-> rgba conversions) in Java rather than via native buffers.

As an alternative I've been thinking of late that what would be even more useful is an implementation of java.awt.Graphics for a GL display....

Offline DaveLloyd

Junior Devvie




Making things happen fast with Java!


« Reply #5 - Posted 2005-03-14 11:10:02 »

Oh I forget to add the real pain of using Swing is that you don't get lightweight peers until you have a visible frame. There's some real nasty awt hangovers there that are continually tripping me up... Shame as in principle they should not be necessary and swing should work in vacuo.

Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Reply #6 - Posted 2005-03-14 13:01:12 »

Quote
As an alternative I've been thinking of late that what would be even more useful is an implementation of java.awt.Graphics for a GL display....

This exists already Smiley You can switch it on with the VM system property -Dsun.java2d.opengl=true. But the VM crashed on my machine with this property enabled.

But anyway, thank you very much for the input. I will check Project Looking Glass and Xith3D out (I tried the latter one once, but I did not know that it has that kind of features!).

Something came to my mind after I posted my initial question. Assuming that the information of the size and the position of a frame are available, one could draw on the GLCanvas a rectangle that exactly fits the covering frame.  In other words, the actual frame is not drawn on the GLCanvas, but at least OpenGL has not to render the part of the viewport image that is masked by the overlapping frame. This may not work out in fullscreen mode... What do you think?

-edit- removed awkward spelling mistake -edit-

Offline c_lilian

Senior Devvie


Projects: 1


Java games will probably rock someday...


« Reply #7 - Posted 2005-03-14 13:17:46 »

Quote

Yes, for two main reasons:

I would like to run my program in fullscreen mode. Only one frame can be put in fullscreen mode and for instance overlapping dialogs are not possible.

In addition, I would like to make use of the advantage of the depth buffer. The objects that are below a window do not need to be rendered.

I know that there is a trick with this pseudo fullscreen mode where you use an undecorated JFrame which size matches exactly the screen. But I believe this does not tell OpenGL not to render the things that are below a GUI component.


I'm not sure to understand well your needs, but, why don't you just use a borderlayout (or any layout) to isolate your glcanvas from your AWT/Swing components ? AWT/Swing also work on full screen mode...

Lilian


Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Reply #8 - Posted 2005-03-15 11:03:16 »

Well, what I actually want is that my GLCanvas covers the whole screen in fullscreen mode and not only partially which would be the case if I put the GLCanvas in a Borderlayout together with an adjacent panel Smiley A static panel at the side of thew canvas is not what I intend to have. Rather, a small and simple window system that is displayed _in_ the GLCanvas would be great. Since I plan my app to have a lot of internal frames, they would cover a quite high percentage of the GLCanvas which may have some positive impact on the performance since the parts of the scene that are masked by the internal frames do not need to be rendered.


Offline c_lilian

Senior Devvie


Projects: 1


Java games will probably rock someday...


« Reply #9 - Posted 2005-03-15 11:19:17 »

well... check if Z-ORDER meets your needs ... (jdk1.5 only)

http://java.sun.com/developer/JDCTechTips/2005/tt0118.html

Lilian

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Reply #10 - Posted 2005-03-17 08:42:08 »

Hmm, that may help. But I&#8217;m not sure yet, but thanks anyway. I have to play around a bit with it. At least it probably helps to realize my former idea which I described above (drawing a rectangle on the GLCanvas where a pop up menu masks the scene in order to save some rendering).

Offline zingbat

Senior Devvie




Java games rock!


« Reply #11 - Posted 2005-03-17 19:39:55 »

What we really needed was the Swing api rewriten on top of JOGL with all that awt compatibility crap taken away for good. The problem is that Swing is too much dependent on AWT and that is too much dependent on Sun proprietary apis.

Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Reply #12 - Posted 2005-03-18 04:29:29 »

Quote
What we really needed was the Swing api rewriten on top of JOGL with all that awt compatibility crap taken away for good. The problem is that Swing is too much dependent on AWT and that is too much dependent on Sun proprietary apis.


yeah, I totaly agree. Maybe I should take IBMs SWT (http://www.eclipse.org/swt/) under closer consideration. It's much cleaner, smaller and neater. If I put SWT on the top of JOGL, do you think that someone except me would use it? I guess more people are familiar with AWT/Swing than SWT, although the differences are not huge... :-/

(SWT has an own OpenGL Binding, but only within SWT, like JOGL in AWT/Swing. The binding requires SWT frames and is not fullscreen supported)

Offline zingbat

Senior Devvie




Java games rock!


« Reply #13 - Posted 2005-03-18 14:20:57 »

Swing is the most widely used API. There are tons of good books about and its from Sun. For good or bad this counts a lot.

So if you want to make a clean Swing port to JOGL you only need to implement the basic Swing classes and ignore awt components completely.

There is a problem with this however. For some strange reason JOGL is being built upon awt (an api said to be abandoned by Sun in favor of Swing in the future) so you would not only have to rewrite Swing basic classes but you would also have to change JOGL to work with your native Swing components.

This is an interesting project. If you ever decide to go on with it (JOGL/Swing that is) count me in to help in any way i can.
Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Reply #14 - Posted 2005-03-18 14:27:23 »

I had a closer look on SWT and it appears to me as way to much work for a lonesome student like me (even though it's not AWT/Swing) Sad

I think i'm going to reduce my ambition to my former idea (to prevent the rendering of parts of the scene that are masked by an UI element... see above).

Offline Daire Quinlan

Junior Devvie





« Reply #15 - Posted 2005-03-18 15:05:23 »

Quote

There is a problem with this however. For some strange reason JOGL is being built upon awt (an api said to be abandoned by Sun in favor of Swing in the future)


JOGL is built on top of AWT because AWT supplies the native peers that the jogl library needs to get an OGL context. I'd like to see that dependency folded into JOGL itself, so that you could use JOGL in isolation without relying on AWT. OTOH I have absolutely no idea what would be involved in doing this, I presume it woulnd't be as simple as merely having native code within the JOGL library to create a window and supply whatever platform specific handle to the JOGL lib.

D.
Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Reply #16 - Posted 2005-03-19 01:21:56 »

Quote
So if you want to make a clean Swing port to JOGL you only need to implement the basic Swing classes and ignore awt components completely.


Okay, I will get the Swing sources and look what I can do. I appreciate your offer to help me. I bet I'll need it Smiley

Offline Daire Quinlan

Junior Devvie





« Reply #17 - Posted 2005-03-19 09:14:27 »

I wrote a standalone GUI for the stuff I'm working on with all the basic GUI functionality. Looking at the swing source is quite educational, 'instanceof's all over the place for example, with looks like a very clumsy and slow method for passing the messages through the components. The thing about coding your own GUI is that initially it seems hunky dory, you have the base prototype working and you're quite proud of yourself, and everything is nice and elegent and designed well. THEN you start getting into making sure focus works properly, mouseover events, modal dialogs, minimizing , maximizing, toolbars, layout managers for the windows, and before you know it, your code is a mass of special cases and dodgy looking bits and bobs. Much like the swing source :-)

Lets just say that having done it myself I can understand why Cas called his GUI library 'spaghetti' :-)

D.
Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Reply #18 - Posted 2005-03-19 10:10:31 »

I also wrote a GUI in JOGL and I ALSO ended up in a near death experience. Smiley This was how this very idea came up to my mind.

My hope is, when I only have to deal with some basic low-level classes then I don't have to care about the spaghetti overhead. However, the SWT code taught me the lessen that there seems to be no clean low level since a GUI system is pretty interlocked with the underlying platform because of callbacks, mouse handles, Drag and Drop stuff and so on. I' afraid that it will be the same for Swing. A JOGL port would have to simulate the underlying level, at least most of the parts. For example, Swing often uses AWT LayoutManagers which on their own use AWT classes...


Offline zingbat

Senior Devvie




Java games rock!


« Reply #19 - Posted 2005-03-19 11:38:27 »

Yes the AWT/Swing linking code is probably the most messed code Sun as ever done. However the situation is not as bad as it seams. I looked a bit into the AWT and Swing and i believe that by changing just a couple of critical classes you can get about 80% of the Swing code working on top of it.

Heres a quick-and-dirty plan about how things could be done for this hypotetical JOGL/Swing api.

Graphics2D -> Graphics2D would extend an opnegl context

AWTEvent -> would become SwingEvent
AWTError -> SwingError

GraphicsConfigTemplate
GraphicsConfiguration
GraphicsDevice
GraphicsEnvironment

Toolkit -> SwingToolkit, from it we get a NativeWindow and OGLNativeWindow and an OGLContext form the window

JComponent -> SwingComponent
JTextComponent -> SwingTextComponent

Like i said this is a quik-and-dirty analisis so a lot of stuff must be missing.

The harder part would be to modify the SwingToolkit to obtain an opengl native window and integrate it with JOGL.
Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Reply #20 - Posted 2005-03-19 14:50:28 »

Quote

The harder part would be to modify the SwingToolkit to obtain an opengl native window and integrate it with JOGL.


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



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 ? Smiley

Thanks in advance!

Offline zingbat

Senior Devvie




Java games rock!


« Reply #21 - Posted 2005-03-19 18:22:32 »

Quote

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.*.


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:

Quote

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.  Cool 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.
Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Reply #22 - Posted 2005-03-19 23:16:03 »

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

- 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).


Offline zingbat

Senior Devvie




Java games rock!


« Reply #23 - Posted 2005-03-20 16:04:26 »

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.
Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Reply #24 - Posted 2005-03-21 03:39:23 »

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

Offline c_lilian

Senior Devvie


Projects: 1


Java games will probably rock someday...


« Reply #25 - Posted 2005-03-21 04:32:10 »

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

Lilian

Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Reply #26 - Posted 2005-03-21 05:12:31 »

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

Much appreciation in advance

Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Reply #27 - Posted 2006-01-28 02:19:28 »

Hi!

Not sure if anyone still remembers this thread...

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

Well... After almost one year I want to let you know that I did as I have been told  Grin 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 Smiley . Maybe you can check it out once in a while.

Johannes

Offline zingbat

Senior Devvie




Java games rock!


« Reply #28 - Posted 2006-01-28 21:58:10 »

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.
Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Reply #29 - Posted 2006-01-29 03:55:50 »

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

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

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

toopeicgaming1999 (73 views)
2014-11-26 15:22:04

toopeicgaming1999 (62 views)
2014-11-26 15:20:36

toopeicgaming1999 (15 views)
2014-11-26 15:20:08

SHC (29 views)
2014-11-25 12:00:59

SHC (27 views)
2014-11-25 11:53:45

Norakomi (32 views)
2014-11-25 11:26:43

Gibbo3771 (27 views)
2014-11-24 19:59:16

trollwarrior1 (40 views)
2014-11-22 12:13:56

xFryIx (78 views)
2014-11-13 12:34:49

digdugdiggy (56 views)
2014-11-12 21:11:50
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!