-
-
Notifications
You must be signed in to change notification settings - Fork 97
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 descriptions/tooltips to editor settings #1339
Comments
Project settings already have tooltips, which are defined in the documentation: Perhaps, something similar can be done for EditorSettings as was done for ProjectSettings here: https://github.com/godotengine/godot/blob/69c81309cc786cc5702fb8d558636fb31f207971/editor/doc_data.cpp#L287-L291 |
Related: godotengine/godot#29694 |
Unfortunately, you can't just move the EditorNode registration around as the engine will crash on startup if you do that. (I tried doing that a while ago.) |
Ok, so I just slapped something together to "brute force" a solution. It works... but lay it on me if this is a bad idea: In if (name == "EditorSettings") {
EditorSettings::create();
EditorSettings::get_singleton()->get_property_list(&properties);
own_properties = properties;
} Just before this: And it works. Docs get generated with all properties... I can add descriptions in the xml and it shows up in the editor settings at runtime, all that good stuff. No build/compile warnings. Obviously this is hacked together and I would need to clean it up a bit, but I just figured since all we need to get properties when using --doctool is a created instance of EditorSettings, why not just do that? Edit: ok so I guess one issue is that the EditorSettings is now registered and created in DocData every time... which is kinda dumb. I was hoping I could make a "temporary" instance of it. |
Ok so basically at this stage it looks like it is impossible to get all editor definitions when you run the doctool. You can get the ones created in the constructor of For example, To summarise, it seems that with the current system, if we wanted to get editor definitions from the doc tool, only about 200 would be able to be included. The other one hundred (approx) come from editor classes which register their settings in their constructor (or other setup) and as a result are not done before the doctool is run. So some options would be:
As a side note, the system works for |
Might be a good idea to move all the non-module settings there. |
Also, as a result of the EditorNode and related classes not being constructed, some project settings are actually left out of the documentation, such as @bojidar-bg interesting idea... So we just move all So then if you wanted to make a new editor setting? Put it in the central location and used |
Hey 👋
Long story short, it feels a bit off having the ability to create entries in almost every part of the editor and still not having the possibility to give the end user information about them in their respective tooltips. Sorry if that's not 100% exactly what this issue is about, there's already quite a lot of open issues about tooltips and after reading them, this one seemed the right one to comment on... Cheers. |
This is already implemented in |
@EricEzaM You workaround seems to generate the documentation fine (thanks a lot 🙂). However, I get a segfault when
(I had to use gdb as the built-in crash didn't work here.) |
The tooltips should appear when you click on a property or its value. The user is showing he probably wants it- it maybe should listed in the project settings as an option. |
Describe the project you are working on:
Using the Godot engine.
Describe the problem or limitation you are having in your project:
Sometimes it would be helpful to have additional information/context about editor or project settings.
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Add ability to set descriptions for these settings which show up in the tooltip when hovered.
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Not the best example but you get it. Most properties have self-explanatory names, but some could do with some additional context.
In code:
If this enhancement will not be used often, can it be worked around with a few lines of script?:
N/A
Is there a reason why this should be core and not an add-on in the asset library?:
Part of the editor.
The text was updated successfully, but these errors were encountered: