DirectGui Designer

Showcase
1

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.

This editor is part of the modular editor FRAME

Features:

  • 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

Screenshots

Download

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 DirectGuiDesigner.py 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.
10 Likes
2

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:

3

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.

4

This looks very well made, congratulations!

5

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

6

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.

7

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:

8

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])
            ("Wall",
             [
                 # 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
                 ("Height",
                  InspectableObject.VAR_TYPE_NUM,
                  "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.

Screenshot%20from%202019-07-04%2018-10-56
Screenshot%20from%202019-07-04%2018-10-56483×512 31.8 KB

9

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.

10

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.

[edit]
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! :/

11

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:

12

It’s finally there, custom widget support landed in the latest commit to the DirectGui Designer in addition to some other smaller changes.

The Designer now has a menu bar as well as a simple options dialog to set a few settings. Dialogs have also been reworked a little and most path entries now use the Builtin folder browser.
Other than that, performance improvements have been introduced and bugs fixed thanks to @Epihaius for reporting them.

I hope those new features are working well for you and help you in creating even better GUI designs. If you are missing some features that would help you to use the Designer even better, don’t hesitate to share them with me.

2 Likes
13

Those sound like some really solid changes, I think! The options-dialogue in particular sounds useful. :slight_smile:

Sorry that I never go around to polishing and uploading that inspector of mine–I ended up moving over to work on other things, and haven’t given it much attention. ^^;

14

Don’t need to be sorry, so far the property editor of the designer is working fine. Though, for the custom widgets, it might be a bit to limited yet, but the support for custom widgets isn’t that flexible yet too, so there’s still lots of work left. For example if I try your TabbedFrame element, I already see a few things to improve, esp. for the properties’ editor. Things like custom functions to call as well as custom properties. Currently, there can only be properties known to the designer be enabled for the widgets.

15

Fair enough, on all counts. :slight_smile:

Discovering custom functions does seem to be a bit of a tricky thing in Python, I’m afraid: if they don’t come with code that register or lists them in some way, there doesn’t seem to be an easy way of getting hold of them–without getting every method and variable available within their class’s scope, at any rate!

16

The problem is less the discovering, as they could simply be defined in the widget definition file, but making them available in the designer, especially if they need arguments passed to them or have other requirements.

17

Well, if they’re defined in a given file, can that definition not also provide arguments and the like? Something like the framework that I showed about for my own inspector?

18

That depends on the function and argument. For example if you have a method that require knowledge of other elements, that would be a bit tricky as you’d need to select another element while having the to be edited element selected which currently isn’t really possible yet. And there probably are a lot more use cases which require information passed to functions that can’t be easily aqquired by the designer or given through the definition file.

19

Hmm… Fair enough, then; that does make sense.

It almost sounds like a good situation for a visual designer–something like Blender’s node-system, in which one can not only enter data directly into entry-fields for GUI elements, but also connect properties of other elements to a given entry-field. More-complex logic could be handled via intermediary blocks that either perform simple processes themselves (e.g. take an input and halve it), or run arbitrary functions given by the user.

However, this is a fairly large project, I fear! ^^;

20

A node editor sure would be a good idea for this kind of functionality but yes, you probably are right with your assumption that this will be a large project.
Though, as it is an interesting topic and if held generally, a node editor for Panda3D could be an interesting thing. But, before I tackle that, I already had plans for creating something like a non-linear editor for Pandas interval system.

1 Like