Improve tooltip API greatly. Fixes issues #6 and #29. #30
Conversation
Works even better than mkremins#13 and mkremins#19. Disclaimer: Not tested with complex textual values which include ChatColor.toString()-marked colors.
This now uses JsonString to wrap a string as a Json value in an OOP way.
This commit adds formatted text by accepting a FancyMessage without click or hover data (enforced upon set). The abstraction made possible by JsonRepresentedObject allows easily writing formatted or unformatted text to the stream, which is needed because two distinct types of data are used here: raw string (not composite object), and formatted message (composite object).
This commit implements that by iterating through message components of each message, and after reaching the end of a message, appending a newline message component.
|
Out of curiosity, why were you using items to represent multiline text? My testing shows that the newline character works just fine. |
Fixed documentation as such. This is consistent with the API not having any form of root characteristics, and is probably a good thing for consistency's sake.
method accepting Iterable<FancyMessage> This was broken because |Iterable<FancyMessage>| == |Iterable<String>| (type erasures), so I changed the tooltip methods to be tooltipUnformatted and tooltipFormatted
This is actually done by invalidating the internal state temporarily to remove the default MessagePart created by the constructor. Doing so is necessary to make sure there isn't a (GSON equivalent to a) NPE later down the line.
This allows for more logical iteration through objects, and although the method is explicitly marked as not for public API consumption, it is still publicly visible. This may not be the best option, in which case I will happily revert the commit.
|
I suspect that the use of item descriptions to represent multiline text is a holdover quirk from a time before the Minecraft client was able to correctly handle newlines in ordinary text tooltips. Fanciful started out as an attempt to canonicalize and modularize some of the patterns emerging around the new chat API, and some of the existing code I looked at as reference during the initial development period handled multiline tooltips the same way. |
|
Does this fix the tooltip issues? If so, please merge it. Would be great. |
|
Planning to merge as soon as I've finished reviewing all the changes :) |
|
The one thing I'm not completely sure of is the last commit, as it is somewhat out-of-scope and more of a developer convenience, I'm perfectly fine removing it but it's up for debate. I do, however, think that |
|
Could we restore the old (strings-only) definition of Other than that, everything here looks good. |
|
Done. |
|
I merged the changes from my other PR into this one. If all other issues are resolved, we're ready to merge. |
This PR improves the API for dealing with tooltips. The first change is not using items to represent multiple line tooltips, and instead joining a string with newlines. This prevents the ominous colon/comma bug.
The second change added by this PR is accepting fancy message as a tooltip. The code will validate that the fancy message does not contain tooltip or click data, then it will apply it as a formatted JSON tooltip to the message component.
The final change addressed by this PR is allowing multiple lines of formatted messages. This is implemented by cloning each message component, and adding a
MessagePartrepresenting\nin between each line of formatted text. As a result, one of the features I noted on #23 (cloneability of core objects) was implemented.