@HugoBD-Unity any chance that some of the private members of TMP classes could be made protected ahead of the next update? I’m currently incurring a growing tech debt from duplicating and editing TMP classes within my project
1 Like
I agree with this, opening some of those classes would help many developers. No reasons why they need to be private, especially since there are not many other alternatives out there and pretty much everyone use TMP.
+2 especially if it will be closed source in the future. Not only protected but also virtual in most cases and public made public virtual.
@Kamyker , @LorenzoNuvoletta and @jack-gravitysketch I decided to move your posts as I think the subject deserves its own thread.
As we move TMP from a package to Unity core, I believe it’s a good opportunity to reevaluate the accessibility of some APIs with the intent of making it more extensible and easier to customize.
So I am turning to the community and asking for feedback. I’d be interested in learning which Classes / Methods you would benefit the most from being exposed. Please accompany these with an explanation of why it would be beneficial and how you would use it.
Hi Hugo, thanks for the response to this.
Personally, I’m using a copy of the TMP_InputField class to support tagging of other users to notify them. When the user’s caret is on a word starting with @ then the tag options will be open and therefore certain key presses will behave differently - return and tab will select the tab option and add it to the existing text, up and down arrows cycle between people to tag. This means that I have to alter the KeyPressed function where we deal with key inputs.
The current way I’m doing this, by keeping a copy and manually making all the changes again when we update our new TMP package, is just not maintainable. Thanks for taking the time to look at this and please keep us updated
1 Like