I have been looking over the Panda3D engine as a possible choice for a gaming project that I am doing. While there are some great things about the Panda engine I feel the the support for creating a graphics user interface is minimal for my needs. There are a couple things I would like to see in Panda in order to make it fit this part of my project goals:
I would like to see the GUI creation become data driven. There are a lot of standards out there that do this. But for modding and internationalization, you really want the GUI description to be separated from the code. If possible you also want the human readable information in the GUI to be separated from the structure document. If you take a look at XML User-interface Language (XUL) from the Mozilla project you will see a good example of what I mean.
The second desire is a WYSIWYG design tool for the GUI.
I wanted to know if anything is being done on these fronts. I do not want to consider altering Panda myself if there is already a project in the works to do this. I saw some preliminary work on a GUI editor by treeform mentioned in the projects forum, but it looked like he has scrapped it.
well the GUI system is intentionally very generic. so you can do whatever you want with it without beeing restricted by any conventional designs like grids or anything.
you can write a small set of helper-functions which will greatly help you to arrange your gui. writing a WYSIWYG editor for your needs isnt too difficult either.
note that you can set your gui-elements to be modifiable at runtime. so you can move around and arrange stuff.
treeforms projects aside, i wouldnt know about any other panda-gui based things.
if you want to write one yourself you dont really need to alter panda. you can write your editor stuff like any other panda application,too.
probably less intresting for you are the integration of panda into other existing guis like tk and such.
my gui is alive an well. Also no visual editor is on the works yet. I use my gui system in my game and so far every thing has worked.
I am doing a great deal of redesign of my GUI and my game’s UI interface so its getting second wave of improvements as we speak.
OK, I understand what you are saying. But I am not sure that you understand exactly what I am saying.
For example, you mention that you can flag the GUI elements to be modifiable at runtime. While this is fine for things like taking a generic screen layout and altering it for differing screen resolutions, it is still based in code. That means that in order to modify screens you need to have a programmer. That makes tasks like internationalization of your GUI very difficult.
Modern GUI management concepts have long understood that by compartmentalizing the GUI layout in an external text file that is editable you can modify the screen layout without a programmer. This has been implemented for many years now in many ways and has become a staple of GUI design philosophy. This is desirable in most team programming projects because it is now possible to tinker with the GUI layout without changing the code base. This allows for faster prototyping and tweaking of the UI.
This concept is also the basis of creating a modifiable user interface such as what you see with World of Warcraft. If you do not want the UI to be modded by the user community then you also have several options you can implement to prevent that.
There is no need to make the GUI support more specific or less flexible in order to accomplish this feature. All you need to do is take the very same objects, methods and properties that you currently have in the GUI and remove the description of them from out of the code and into a text file. Then you write a parser for the file that will generate an object tree and build the screen for you from the object tree, using the very same functions that already exist in the engine. This is how standards like ZUL and Tkinter work.
Now that you have the actual vital information about the GUI design removed into a text file, you can take this a step farther and separate the human readable text from the GUI layout data into a sort of string resource file. This makes it very simple to take the text and translate it into any language that you wish without altering any code at all. As long as your engine can support fonts for character sets like UTF-8 then you are in pretty good shape to internationalize your programs.
Please note that not one single thing I have said here changes the basic GUI support in Panda at all. It merely makes what is there more flexible and easier to use. It will not break any existing code and if you wish to do things the traditional way then you certainly can.
And I believe ThomasEgi knows most of that, his entire point is “You can do it anyway you like.”
Panda3D doesn’t build every feature in for you, and eventually more will be automatically built in but the great thing about Panda3D is that anything is possible as long as you are willing to code it yourself(if they don’t already have it).
They set the “foundation” and leave certain parts for the programmer to do himself, but they leave everything flexible enough that he can do it anyway he pleases. Maybe someday they’ll include some sort of built in GUI system, but I’m sure they’ve got plenty of other things to work on.
I’m sure everyone would agree when I say “You can always build one, and post it for everyone to use, if you like” That’s what is best about Panda3D, in my opinion, is the community.
since panda is basically a API you shouldnt expect too many tools floating around.
about internationalisation. you can do that using general python-like language files. i think they have a *.po ending. i never really used them but they do work.
result of this system is, all text in your apllication is listed inside a textfile which you can easily translate.