-
-
Notifications
You must be signed in to change notification settings - Fork 21.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a way to add categories to the script variables section from GDScript #4378
Comments
Could this be a subset of a more generalist inspector system like Unity? |
@Zylann I believe in Unity it's like it's because they cant modify C# directly, while we have the power to adapt our language to the editor. I think the things you want to do will be possible with more complex plugin api (currently in the works). |
I personally like the 1 option the most, it's the most straightforward and simple to me, the second for me would be 4, however maybe 2 and 3 are better fit for current Godot syntax? |
@kubecz3k they use annotations most of the time. But using a custom class also allows to present an inspector that doesn't looks 1:1 as the script, because sometimes a script is too complex to be just presented as its key/value properties. Sometimes you even have popups and contextual buttons, which in Godot are located in the toolbar when you select a node. You need a way to specify that too, and annotations/language additions become limited at this if you don't want your script to become a mess, so... to decouple editor and script, you end up making a separate class for editor features :) But I digress. +1 for having categories :) |
@Zylann ~ That's the idea behind editor plugins/addons. |
I'd be for the hint solution, i.e. (2):
That's the most intuitive syntax IMO (and most GDScript-like, as well as flexible for potential future bindings), and having to respecify the category for each variable is IMO better than having a new keyword that would needlessly complexify the parser (we'd have to add a |
@kubecz3k Unity has its own C# interpreter, it's not Microsoft's, they just try to be as compatible as possible to the "official" C# (but fail at that here and there). They could still be C#-compatible and use attributes for that, so that's probably not the reason they don't do it like that. I guess they wanted a rather "complete" solution for even more specific inspectors. Anyway, I'd be against the category "block", and would prefer the hint solution (2). Introducing a whole new block feels rather messy than python-esque. |
Not critical for the upcoming 2.1, so moving to the next milestone. |
I would vote for '4. category block' I think it will make the code looks good also |
As a workaround, and as the inspector respects the orders of my exported variables, to categorize them, i use pseudo-exported vars as separators :
|
I think of a fifth option by adding an "into" word:
also nesting can be possible:
I am not sure about the implementation pros and cons. |
Everything but not more keywords please. It is of good design to not introduce needless keywords. export(category="blablabla") or anything, just in the context of export, would be more useful. |
What about mixing (2) and (3). Need for retyping category names may be little discouraging
but sort of nested tree as in (4) may eleminate retyping need.
For clarity "export" may be changed with a "category" keyword which implies exporting as well.
OR as @RayKoopa said using category in hinting may be more simple
But I fear that this solution may be like torturing export hinting mechanism and coders as well. :) |
I think retyping the category name is not a really big deal... |
I don't like this kind of nesting. It takes metadata to code structure, which can be confusing. Again, in other languages what I would do is something as simple as an attribute like [Category("This Category")], which is usually a standalone feature that doesn't dictates how different properties should be written. btw, what about translation? Maybe sounds crazy, It just went into mind for a second :p |
So in the end something like
will be simple and sufficient without nesting, and with nesting
will do the trick IMO. |
@hubbyist Yes, but with a comma separator. There's no existing precedent for a So |
I'm assuming creating the "category" for export like |
@henriquelalves I would break no compatibility -- since we would make the category optional. I have some unpushed local changes concerning it, but the biggest issue with it is not the export syntax -- it is making GDScript code concerning set/get aware of categories. |
I guess it should be made similar to the new property grouping in the inspector for 3.0+. |
Closes godotengine#4378 via the 4th proposal, as it is easiest to implement
I am not sure if this exists, but wouldn't it make sense to create a new class\struct for categories of variables which would then be the category? I.e
This to me feels more OOP-like, which is the feel Godot is going for I think. |
@nhold while it would make sense, this is not always the best solution. Sometimes you just need to group many variables in categories but still have them in the same class, as well as their getter/setters and associated code. Having that working for subclasses would be nice, but this should not be the only way of making categories (and isn't for the editor anyways). |
@Zylann Great point, then yeah I would personally prefer both options available(Composed classes and manual export with category string) as well as base classes(Ones we extend from) showing under their own categories similar to built in nodes. |
Is this still considered ? While looking into this, would it also be possible to optionally add limits and other possible properties relevant to the type? something like:
would be nice if the system for this is extensible. |
could be interesting to brainstorm a list of possible 'export arguments'. like the former, there could be a ui-min and hard-min, to suggest a min value but still possible to override until hard-min. Not sure if exporting user defined types are supported, have not tried that yet... , possibly to restrict what you can set as a nodepath for example ? That would be a hard one , ie a specific sub type allowed, or a list of allowed / disallowed types. |
@FrederickDesimpel Reading through the GDScript export docs might be helpful -- Also, if brainstorming, please do the brainstorming in chat and then open an issue on the godotengine/godot-proposals repository -- we wouldn't want this issue to have too many off-topic comments. |
Sadly this is actually the only easy/practical way to group export vars. |
This should probably be closed in favor of godotengine/godot-proposals#1255 |
(Inspired by a question on QA)
When doing scripts with a lot of configurable variables, it is nice to be able to group them in the inspector.
So, instead of having:
We can have
With @kubecz3k we discussed on IRC about how might we do the syntax, and we ended up with the following:
category_name.variable_name
, or justvariable_name
@reduz ~ Which one of the four proposals above do you like the most?
The text was updated successfully, but these errors were encountered: