Has anyone tried to get FengGUI running with Xith yet? We are currently working on a way to get FengGUI mate with jME and I thought it would be nice to make the same for Xith. After all I am still fond of Xith because it helped me once in a ridiculously laborious CG homework
We’re currently writing a HUD implementation for Xith. Have you already had a look at ord.xith3d.ui.hud.* and org.xith3d.test.ui.HUD3DTest (current CVS)? It is not totally complete, but I think, it should do what you want (when it’s ready). All we urgently need are text input elements, which I’m currently working on.
Is there anything else missing in the Xith-HUD, which is already implemented in FengGUI?
[quote]Have you already had a look at ord.xith3d.ui.hud.* and org.xith3d.test.ui.HUD3DTest (current CVS)
[/quote]
No, not yet. But I will check it out as soon as I can materialize some free time. Thanks for the hint. Are there screenshots/webstarts available?
It is actually a pitty that you guys are having your own UI system now because I spend a lot of effort on building FengGUI and it might have been easier to integrate it into Xith. Perhaps I should have got the word out earlier…
[quote]Is there anything else missing in the Xith-HUD, which is already implemented in FengGUI?
[/quote]
Hmm, not sure how far you are… We have working text input widgets since January including mouse sensitive text selection :-\ You can check out the webstart on http://fenggui.dev.java.net (it is not totally up to date though)
Unfortunately not. You’ll have to ckeckout from CVS until we ahve the time to provide new Webstarts for the currently available demos. But I attached a screenshot of the org.xith3d.test.ui.HUD3DTest.
Actually I had a look at FengGUI before I started to write the HUD system. But there was something that I can’t remember, which made me not use it. I guess it was the unability to use it with xith.
You’re a bit farer. We don’t have text input, trees, lists, tabs and splitpanes. Unfortunately I wasn’t able to launch the WebStart. Could you please look for it?
How did you solve the problem with clipping in frames or scrollable areas? Is there an opengl function, which does it or did you write the necessary code yourself?
[quote]But I attached a screenshot of the org.xith3d.test.ui.HUD3DTest.
[/quote]
The shot looks very nice already. It seems that your GUI library is texture-centric too.
[quote]Actually I had a look at FengGUI before I started to write the HUD system. But there was something that I can’t remember, which made me not use it. I guess it was the unability to use it with xith.
[/quote]
Hmm, but I think these unabilities could have been bridged somehow. In fact that are probably the same difficulties we have with jME and that come with a rendering queue. A quick an dirty hack could have been to simply draw FengGUI after drawing the scene
[quote]We don’t have text input, trees, lists, tabs and splitpanes.
[/quote]
Well… we dont have trees and tabs either. We want to make FengGUI more stable first before we add more fancy stuff… This delays everything a bit.
[quote]Unfortunately I wasn’t able to launch the WebStart. Could you please look for it?
[/quote]
That’s odd. I just doublechecked again and it works fine on my machine (WinXP)… Is there a specific error message?
[quote]How did you solve the problem with clipping in frames or scrollable areas?
[/quote]
We are using glScissors for clipping. This basically defines a rectangular clipping space. It’s quick, reliable and easy to use
Cool. We discussed this glScissors for that purpose, too. But we found it not doing the trick. So I guess we were wrong and can actually use it. Thanks for the hint.
Thanks for bringing the webstart issue up. Apparently it is broken indeed… now that you two people cannot open it I can only estimate how many people else encounter the same thing…
However, after carefully clearing all possible caches on my machine (java webstart cache and browser cache) I still have no problems running it. :-\
Any hints are much appreciated.
That’s odd, because I can access it (with a wrong MIME type though). Maybe there was a temporary problem with the webserver… our CS server is known to break down once in a while.
Because our CS server is unable to send the correct MIME type along with the jnlp file (and it’s not an apache, so I have no clue how to tell him), I have a copy of the same jnlp file on fenggui.dev.java.net. If you click on the link, this copy is opened because the webserver of java.net got the right MIME type. The jars are loaded from my uni. account though, because the signing gets scrambled when uploading jars via CVS. And the commiting the files to the CVS is the only way to upload stuff to dev.java.net that I know of.
[quote]This is necessary anyway. Maybe it could work.
[/quote]
We are currently trying this with jME and it works quite well. We have one minor difficulty to overcome though Everything is just fine when we run FengGUI on top of jME with an empty scene. But as soon as we add a node to the scene graph, some texture states are set in jME that we do not reset in FengGUI such that textures are not mapped in FengGUI. So what we got to do is to find that state and simply reset it in FengGUI. But I haven’t started digging yet… I am missing probably something obvious…
[quote]I took this from your web page:
Quote
FengGUI is a graphical user interface (GUI) application programming interface (API) based on OpenGL. FengGUI will provide all typical GUI components like buttons, sliders, trees, text areas, frames, tabs, etc. which are required to build a complete GUI system…
[/quote]
We had all these items once, but we removed them temporarily because they didnt work reliable enough. We dont want add code before the rest is stable. But actually the widgets aren’t the problem; the layout managers and the theme/layout XML stuff are trickier.
Is it true, that your Frames aren’t resizable, too? I’m planning to implement this feature for the future. But others are much more important for now.
I checked out the FengGUI code from CVS, but I cannot find, where you actually use glScissors or any other OpenGL call for clipping. Could you kindly point me to the right class or paste an example? I would be very greatful
[quote]Yeah, it’s kida impressive.
[/quote]
Thanks! I am glad you like it.
[quote]Is it true, that your Frames aren’t resizable, too? I’m planning to implement this feature for the future. But others are much more important for now.
[/quote]
Yapp, it is sad but true Funny, we just talked about resizable frames our the discussion today
We encapsulated OpenGL as good as possible because we want FengGUI to be able to render with JOGL as well as with LWJGL… this is why we never have direct OpenGL calls which is the reason why they are so hard to find. If you dig in the package org.fengui.render you will find several clues such as an interface IOpengGL which defines all important gl calls we need. This interface is simply implemented one time on the JOGL side and one time on the LWJGL side. For example, the LWJGL implementation of IOpenGL reads for the method setScissors:
public void setScissor(int x, int width, int y, int height)
{
GL11.glScissor(x, y, width, height);
}
where x and y have their origin in the lower left corner. What you will find interesting as well is line 111 in org.fenggui.render.Graphics. Similar to Java2D, Graphics contains several helper methods for drawing text, rectangles, triangles, images, etc. Among them is the following method:
public void setClipSpace(int x, int y, int width, int height)
{
x += offset.getX();
y += offset.getY();
// setup the clip space rectangle that we keep in the Graphics instance
clipSpace.set(x, y, width, height);
gl.setScissor(x, width, y, height);
}
There we translate from FengGUIs display space in the openGL view port space. This method is used in org.fenggui.Container, line 134. This method looks a bit messy due to the addition of recent validity checks:
When it comes to rendering the widget, the containers iterate through the child widgets. For each child widget we first setup the appropriate clip space and then draw the widget (inclduing backgroud, border and content). Note that a child widget can be a container again. I hope this answers your question?
Schabby, feature request : I want to be able to click-drag to a menu item.
E.g. I click on “File” and I drag to “New” then release the button and it works (pressed event on new).
Schabby, typo in the useless TextArea text : “but thar hardly satisfied the little one”.
Feature request : copy/paste from external working (could implement it).
I think I’ll request dev access to FengGui. (Not just now).
Schabby, feature request : when multiple selection is enabled on tables, do multiple selection only when control is pressed, and implement “shift” behavior (select all from first to currently hovered one).
Maybe FengGUI and HUD could complement each other in the Xith framework.
Since FengGUI already aims for kind of general purpose GUI, I would suggest to keep the HUD at a minimum. Just some textured Frames with buttons and a simple text input. Maybe scrollable surface and/or lists at most. No fancy widgets like trees and such, no layout managers, no xml description language. Just a quick way to make start-screens, highscores, inventories etc.
I agree in general. I already thought this way. Rivalry wouldn’t help us and was not in an Open Source thinking.
As you said, cylab, FengGUI is made for general rich GUI applications. The HUD was always meant to be for games. So we don’t need fancy Widgets. But I already implemented the base for layout managers (just one day before this FengGUI discussion came up ;)), but I didn’t write any concrete LayoutManager so far. Any WidgetContainer is scrollable and there is a ScrollPane implementation. There will be TextField Widgets and List Widgets in the near future. So I don’t think I should paddle back and remove the LayoutManager interface. But I also think there’s no need for a first completeness to have concrete LMs. The Tree could maybe come in, too and the Tab. But definitely no menus or splitpanes. This isn’t needed for games.