Support DirectGuiExtention widgets

[Augustifolia]

I was thinking that it would be useful to be able to use the widgets from your DirectGuiExtention in the designer. But, before I work on that, I would first like to make some changes to how custom widgets get loaded in the editor:

Most, but not all, options in a .widget file use CamelCase. For consistency I would like to rename:

1. visiblename to visibleName.
2. the editType optionmenu to optionMenu.
3. displayName to visibleName for consistency
4. classfileName to classFileName

Other changes:

5. To match naming between editType and internalType, I would like to rename the option int to integer in internalType.

6. It could be useful to have an option to specify to what node new items should be attached to. This would be useful for classes similar to DirectScrolledFrame that has a canvas to attach new nodes to. Or would you prefer that custom widgets just define an addItemFunction instead?

7. For example the DirectGridSizer requires some extra arguments to be passed to its addItemFunction, which is not supported at the moment. For this we could add an option with some extra args for the addItemFunction in the .widget file.

I do however fell like it might be better to keep the complexity of the custom widget loader down and simply add workarounds in DirectGuiExtention to deal with 6 and 7.

What are your thoughts on the matter?

[fireclawthefox]

Yes, the DirectGuiExtension widgets should be usable in the designer and I created some widget definition files which are stored in the repository of the DGExtensions. I haven't touched them in a long while though, so they may not work fully but may service as a starting point.

1-4.: Regarding the naming, renaming some things to be CamelCase should be fine, just not sure about the displayName to visibleName. Need to check if it could cause trouble, also I'd be more in favor for displayName.

5.: The internal type is the type class. It defines the type of the property and uses the actual classes. The edit type is for determining which widgets to use in the editor to be able to "edit" the property. So, I don't think you can rename that.

6./7. If you can come up with a good way for defining how to get the node new items should be attached to, that would be nice. I know I did struggle with finding ways to actually get into object specific details without defining some python code especially since it can need different things like calling a function to get the right parent or simply using an object of the class or whatever. The addItem function may be nice, but I'd prefer to make the widget feature not strongly dependent things given in the widgets themself. It basically should work for any widget that is similarly built to the DirectGui widgets. Then we can say if it feels and works like a DirectGui widget, even custom ones, we can support it in the Designer. I mean, some form of defining some extra calls that have to be made or arguments that should be gathered and passed will definitely be useful for a broader availability and reusability, but I'm not quite sure how to do that in a text based definition file. But I'm open for proposals to enhance it and make the widget definition file kind of a standard.

I also like the idea of keeping the complexity low, since that would definitely reduce the work we may have to do later as long as it supports everything we need for the basics without too many workarounds since that on the other hand would not be good enough for a generic custom widget loader.

Well, that was quite some text, I hope everything was clear so far, esp. points 6 and 7 are a big topic and require quite some thinking to implement it well but not overengineer it.

[Augustifolia]

Yes, I saw those files. They are not currently working, but they should be rather straightforward to update.

displayName is currently used for the name of the class, while visibleName is used for all the properties. I just thought it would make sense to use the same naming, but perhaps there is a reason that they are different?

5.: Right, but we don't have to rename it in the code base. We would just have to change the parsing of the .widget file. Something like this (in CustomWidgets.py):

if prop["internalType"] == "integer":
    t = int

6. / 7. This definitely requires some thought. I think that we should at least support the most common cases (like an addItem function or the name of the parent node). But I don't think it would be useful for the user if the .widget files become to complex. At some point it will probably just be easier for the user to write a few lines of python instead.

The easiest way to handle extra args would be to just allow the user to specify the values directly in the .widget file. Of course this would not be very flexible.

Another option would be to let the user define the type of the arguments and then ask the user to type in the values when the widget is created. Perhaps via some OkDialog with some text fields. Perhaps some code from the properties panel could be reused for this.

[fireclawthefox]

Need to check the DisplayName vs VisibleName thematic again, can't remember from the top of my head.

As for the int to integer, yes, I think that is ok, but then we should probably also enlarge the other things like boolean and string to make it coherent.

To points 6/7. Yes, I'm with you there, we should give enough functionality to make it work for most common cases. In case there is something very specific, a new issue can be opened and it can be tackled specifically. I just want to make sure it's not too hard to extend this part of code. Maybe we can even prepare some kind of plugin system to parse your own widget definition sections somehow, but that's for the distant future indeed, basics come first.

A small dialog for extra args may be the first step, but I guess most arguments will be kind of dynamic so it should be possible to get some data from other parts like from existing widgets and so on. Not sure how, maybe with some special syntax where one can give the ID or name of a widget and access it somehow. Defining those extra args in the widget definition should maybe also be possible, since it's simple and there may be cases where it come in handy.

[Augustifolia]

I have thought a bit more about int to integer, and I think I would prefer to just rename integer to int in editType instead. Mainly to have consistent naming with python.

6. / 7.: Yes, extendability is really important.

As for a plugin system, that would be very useful. And I think that the widget definition format should work fairly well for integrating plugins as well. But that will have to wait.

To access other widget from the dialog, typing the name would probably work, but something like a dropdown to select from or just being able to click on the widget to select would be more user friendly. In my opinion.

[fireclawthefox]

If you see it fit and if it enhances consistency without raising other problems, renaming that part should be fine.

A fully featured plugin system is definitely something out of scope for now, but we should at least keep a section even though while unused yet in the definition that can be used for filling with custom data.

Accessing other widgets shouldn't be a problem. Just parse through the widgets in the editor and gather their names and IDs and it should be easy to fill a list of widgets to select from. I wouldn't use a dropdown box though since that may get a little too large for bigger scenes. I'm more in favor of a list of radio- or checkboxes to scroll through and select from. Being able to select the widget on the designer directly would be even more user friendly and we should probably add both options in the end but start with the list first.

[Augustifolia]

Sure, I think that sounds reasonable. Then I will start implementing stuff.