-
-
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 search keywords to the class reference #78990
Add search keywords to the class reference #78990
Conversation
38cf495
to
4747fe9
Compare
a42398d
to
643c2e2
Compare
What's the use case for not wanting to search by keywords? |
Right now, the keywords do not show up anywhere in the UI, so I'm not sure if power users are gonna be happy that seemingly unrelated results suddenly show up in the search results. If I had more time to work on this PR, I'd show the keyword that matched next to the search result, with greyed out text. Might take me a bit before I can get that implemented. But I'm fine with taking the button out if there's no apparent need for it. |
Well the point of having keywords would be to make sure we show more related results than we do now. Hiding them behind a toggle makes them harder to access and less useful. |
92497d4
to
325c8a7
Compare
Removed the toggle so keyword searching is always enabled now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally, it works. Code looks good to me.
There's a small usability issue however:
- When you search for a node directly, it's automatically focused:
- When you search for a keyword, the node that matches the keyword isn't automatically selected:
Getting this working is important to reduce the number of keystrokes you need to open the documentation page, so I suggest looking into this if possible.
325c8a7
to
aaf7ee9
Compare
@Calinou Done! Updated
|
Reducing the weight makes sense, as it's an indirect match. |
660771a
to
5f97bb1
Compare
I'm not too fond of having keywords as XML tag attributes. Attributes are usually things generated from the codebase, and human-written content should be filled within tags (e.g. So it might make more sense IMO to add an optional |
@akien-mga While I agree with your reasoning, it seems like it would have to be a breaking XSD schema change. Maintaining a backwards compatible parser sounds problematic (especially now that the version attribute is gone) and it would make new documentation features hard to discover. Let me know what you think! |
I don't understand, how would Edit: Oh nevermind, re-read and checked the link, I see the problem. Hm... I guess using an attribute is the least bad solution then. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally (rebased on top of master
57919be), it works as expected with correct focus behavior now.
I can do a pass over the class reference to add keywords once this PR is merged.
Would be nice to address the conflicts. Reception on this seems fairly positive. Although the current implementation seems out of reach for translators, if that was ever a concern. |
5f97bb1
to
f0f60c6
Compare
Rebased onto latest master. Thanks for letting me know! ^^
Since the API is not translated (so method names, property names, etc.), I don't think it matters. You wouldn't search for a Spanish keyword when all the possible results are only ever in English. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Took a deep look. You can get a lot of mileage out of this feature in the future.
It is kind of confusing to get search results from terms that are not directly visible, although that can be figured out later.
Note for the future: Vector2/3's |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good otherwise
Yeah that's my main concern with the current implementation. I'd like to see something that makes it obvious to the user why the filtered entry matches their search. There could e.g. be a "(keyword: ragdoll)" added after the node name in the list, in the OP's example. It shouldn't necessarily be blocking for this PR though, it could be worked on in a follow-up, possibly by someone else if wanted. |
Allows for finding methods, properties, signals, constants, theme items and annotations more easily. - Allow "keywords" attribute in aforementioned locations in the class reference XMLs - Extends doctool, to preserve these attributes - Update the XSD schema for the class reference - Update the RST generator to include a meta tag for class keywords - Update the editor help to support filtering by keywords
More should be added in future PRs, wherever there is demand.
f0f60c6
to
5911a12
Compare
Thanks! |
Fixes godotengine/godot-proposals#5085
Allows for finding methods, properties, signals, constants, theme items and annotations more easily.
Ideas and Future
@keywords ...
comment in GDScript to define keywords for script classes and members? Implementation would look like GDScript: Add@deprecated
and@experimental
doc comment tags #78941