DirectGui Designer

Hey everyone,

creating GUIs in Panda3D can be a tedious task at times and not everyone designing a GUI is a coder. That’s why I’ve created and now proudly present to you, the DirectGui Designer.

DirectGui Designer

I've created this application to simplify the task of designing and creating user interfaces with Panda3Ds DirectGui system as much as possible.

Currently, it is in a kind of Beta state where all features should work but some things might still be missing and bugs will lurk in the dark corners of the app. That's where I need your help, try to create GUIs using the designer and tell me what's missing and if and where problems arise.


  • Toolbox with all DirectGui elements
  • Drag and drop to re-position elements in the designer
  • Properties editor for most common element options
  • Place elements freely or with a guidance grid
  • GUI structure viewer
  • Save and load projects as JSON files
  • Export to python script for easy integration
  • Keyboard shortcuts for faster editing



The DirectGui designer currently isn't packed up nicely, but if you have Python3 and Panda3D installed, you can simply grab the latest version of the source from github and run the script.

Tech notes

For anyone who's intersted, the designer is completely written with python3 and Panda3D, no extra libraries were used and most of it actually uses the DirectGui system for its UI.

A small part of the Designer was created by using an early version of the Designer

Some DirectGui elements have been overwritten to surpass bugs and add features not yet implemented in Panda3Ds official version.

Ooh, that’s very cool, and very welcome! Thank you for doing this! :smiley:

Can you expand on that, please? What changes have been made?

And does this mean that the behaviour of certain elements will then vary between the designer and the SDK/distributable version? (Or does it work only on the Python-side–thus incurring no issues with the distributable, if I’m not much mistaken–and overwrite the installed SDK’s DirectGUI files–thus causing the designer and SDK to run the same behaviour?)

I have a request, if I may–presuming that this feature isn’t already available: Would it be feasible to have the designer work with DirectGUI sub-classes?

As to how it might detect these, perhaps it might check for a custom Python-file in a pre-determined location that lists the available sub-classes.

I’ll hopefully take a look at this soon! :slight_smile:

Thank you ^^

The exported python script will use the versions shipped with the SDK. Most of the extra features have only be used directly in the designer GUI but not made visible to the property editor yet, so you can’t change those to keep it on par with the SDK version. There’s only one thing IIRC regarding the alignment of the slider which isn’t able to use inverted horizontal in the SDK version yet but you can use and set it in the Designer. I’ll prepare PRs to include those changes in the official SDK in the upcoming days.

This is not yet supported, but it could be implemented kinda in the way you proposed it. Those sub-clases though would probably need to be implemented in the same manner as the actual DGui classes which partly are only sub-classes (mostly of Frames) anyways.
Creating a loader for such custom classes to load them in the designers toolbar and filling the properties’ editor correctly when selected might just take some time to be done right.

This looks very well made, congratulations!

Ah, fair enough! I’m relieved to read that. :slight_smile:

That’s what I have in mind–I have some DirectGUI sub-classes, and it would be really useful to be able to work with them in this designer, I imagine.

Hmm… I’ve been working on an object-inspector that, when done, might help with that. It essentially shows a list of nominated properties and allows the user to edit them. Properties are grouped by class (so you would see the properties of a super-class separate from those of a sub-class), and the groups can be folded or expanded for ease of browsing.

It’s not yet quite ready for public release, I think, but I have had it in mind to do so when it is.

(It could also likely use a much better file-browser than my current, very simple browser.)

Would you mind sharing them so I could get some insight and knowledge for how I should update the editor to support custom classes?

That does sound useful indeed. Does it already create a GUI for changing values and how do you determine the type to prevent users from entering faulty values? My approach currently is hardcoding the property names and bind them to specific entry methods, some with special features as some props of DGui elements can’t be set by the usual element[propName] = … way but need function calls.

I will borrow that, because this was exactly my thought. I will have to wait two weeks (vacation) but after that I will try to use it. Might be exactly what I am looking for :upside_down_face:

Sure! One of them, a “tabbed frame”, might actually be worth putting up on GitHub for others to use anyway. I’ll likely look to post at least that class that sometime soon, perhaps later today (by my time). :slight_smile:

I’m not quite sure of what you mean by this.

In essence, it accesses a list of properties that have been exposed to it–more on that in response to your next question, just below–and generates a set of DirectGui controls to allow the user to set the relevant values. Setting of values can be done by either assignment or method-callback.

That’s a tricky one, especially as DirectGUI doesn’t have numeric-entry controls, as far as I’m aware.

But in general, type is specified in the list of properties exposed for the inspector, and determines what it expects to find when it inspects the object in question, and what it returns to that object on applying the new values.

I do imagine that there is more type-checking to be done on my part, in all fairness!

Right now the list of exposed properties is implemented as a feature of a base-class that inspectable objects are expected to sub-class–but I have it in mind to also provide the inspector with a dictionary that it can check for cases like Panda-classes. With that done, DirectGUI properties can be exposed, with the property-lists for custom classes perhaps being provided in the Python file that informs DirectGui Designer of those classes.

This is a simple example of how a property is exposed; some of the following might change as I work on the inspector!

# Our variables incorporate the variables of our base-class
# I'm thinking about automating this!
editorVariables = InspectableObject.editorVariables + [
            # Each class specifies its properties in a tuple of the form:
            # (class-name, [property-list])
                 # A property. We start with a label used by the inspector, then
                 # the type of property, then getter and setter (which can just be
                 # "property = "). Some properties are followed by other elements,
                 # like a file-path when loading files
                  "setHeight", "getHeight"),
                 # More properties may follow...

And a screenshot of the inspector. This comes from a rather old version, admittedly! Note that I’ve closed the “GameObject” section, thus contracting it. The colour-scheme shown here will likely be undone for release versions.

You answered it with your description and the screenshot.

Yes, that’s one thing I was missing too. They are rather easy to implement thought with normal entry and a value check either when evaluating the entry text when used or directly when the user enters something, I think there was a way to add a function that gets called when text changes.

Anyways, that property editor looks useful and that data structure of how you add variables to the editor might be something I could use for my property editor too as I currently use dicts and lists for that atm.

Also, how have you set up that folding in you editor? That’s something I thought of adding to my prop editor and the structure viewer too.

Ah, good then! :slight_smile:

I think that I’m just taking the risk of casting to either “int” or “float” at the moment–but I do have functions for producing a float- or int- value from a text-string, which I may well get around to applying in my inspector, too!

You can bind the “type” and “delete” events, if I recall correctly. (I haven’t checked the exact names, so those might be slightly inaccurate. There may be other relevant events, too.)

I’m glad! :slight_smile:

I will say that progress on my inspector is slow at the moment, as it’s a side-element in a side-project, and thus doesn’t get a lot of time.

It’s been a while since I implemented it, but looking quickly at the code it seems to be something like this:

  • Each category has a frame, parented to the frame above it (or the base control in the case of the first category-frame).
  • Each frame contains a check-box, and a sub-frame containing the various data-entry controls.
  • When a check-box is toggled:
    • The associated sub-frame is either shown or hidden, according to the state of the check-box.
    • The following frame is repositioned, either directly below the check-box or directly below the sub-frame, according to the state of the check-box.

Since the frames are parented below each other, moving one of them up or down moves all of those below it.

Update: I’m not longer confident about uploading that TabbedFrame class. It looks like I implemented it in a rather un-DirectGUI manner, and that re-engineering it to work in a DirectGUI manner might be tricky–especially as DirectGUI gets upset when you try to create option-defs for components that aren’t created at initialisation. :/

I might look through my code and see whether I have other DirectGUI subclasses that might be worth sharing.

Sorry about that! :/

I stand somewhat corrected–'tis done! :slight_smile:

The implementation is perhaps not perfect, but it seems to work.

Here is the thread for my “TabbedFrame” class: