kyoripowered / adventure-webui Goto Github PK

To aid with #15, the render hooks should take the context of the call in addition to the thing that is being rendered.

When I type text <rainbow>ここはテストメッセージです</rainbow> and click "Export to JSON" button, and then paste in text editor, it appeared garbled text like this.

{"extra":[{"color":"#f3801f","text":"ã"},{"color":"#e99413","text":"�"},{"color":"#dca80a","text":"�"},{"color":"#cdbb04","text":"ã"},{"color":"#bccc01","text":"�"},{"color":"#a9db01","text":"�"},{"color":"#96e805","text":"ã"},{"color":"#81f20b","text":"�"},{"color":"#6df915","text":"¯"},{"color":"#59fe22","text":"ã"},{"color":"#46fe30","text":"�"},{"color":"#35fc41","text":"�"},{"color":"#25f654","text":"ã"},{"color":"#18ed68","text":"�"},{"color":"#0ee27c","text":"¹"},{"color":"#06d490","text":"ã"},{"color":"#02c3a4","text":"�"},{"color":"#01b1b7","text":"�"},{"color":"#039ec9","text":"ã"},{"color":"#088ad9","text":"�"},{"color":"#1175e6","text":"¡"},{"color":"#1c61f1","text":"ã"},{"color":"#2a4ef8","text":"�"},{"color":"#3a3cfd","text":"�"},{"color":"#4c2bfe","text":"ã"},{"color":"#5f1dfd","text":"�"},{"color":"#7412f7","text":"»"},{"color":"#8809ef","text":"ã"},{"color":"#9c03e4","text":"�"},{"color":"#b001d6","text":"¼"},{"color":"#c201c6","text":"ã"},{"color":"#d206b4","text":"�"},{"color":"#e10da1","text":"¸"},{"color":"#ed178d","text":"ã"},{"color":"#f62479","text":"�"},{"color":"#fc3365","text":"§"},{"color":"#fe4451","text":"ã"},{"color":"#fe573f","text":"�"},{"color":"#fa6b2e","text":"�"},{"text":"\n"}],"text":""}

https://chrome.google.com/webstore/detail/i-dont-care-about-cookies/fihnjjcciajhdojfnbdddfaoknhalnja?hl=en

Really, the viewer shouldn't be handling the literal string \n at all.

When you head to a fresh webui page, the parser will send a zero width space when the input text area is empty, causing elements to render (such as the chat box) when they shouldn't.

Similar to LuckPerms' editor, it would be nice to allow plugins/etc to utilise some form of "editor" system to change config values/etc.

There's apparently no MOTD view, and seeing as MiniMOTD is a thing I thought it'd be a good odea to request such a feature.

When writing text with placeholders, one might want to see how it looks like with "real world" values. Replacing it in the input field directly is cumbersome, so it would be nice to have extra fields for placeholders where you can put actual values in (and e.g., a check box to enable replacement). Not sure how that can be integrated nicely though...

While working with minimessage, i use hex colors a lot. I think it would be nice to see a color picker on the page, because its not super convenient to search picker in the google everytime.

Some modes should have defaults:

• Lore should be purple
• Lore should be italic (blocking on https://github.com/KyoriPowered/adventure-text-minimessage/issues/133)
• Server list should be gray

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): Update patch-release dependency changes to v2.3.12 (io.ktor:ktor-server-compression, io.ktor:ktor-server-caching-headers, io.ktor:ktor-server-websockets, io.ktor:ktor-client-okhttp, io.ktor:ktor-client-core, io.ktor:ktor-server-netty, io.ktor:ktor-server-core)
• chore(deps): Update dependency org.jetbrains.kotlinx:kotlinx-serialization-json to v1.7.1
• chore(deps): Update gradle and github actions (docker/login-action, gradle, com.google.cloud.tools.jib)
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

no place for ugly code in my kotlin/(js+jvm) multiplatform hacked together component rendering system

Would be cool to be able to parse old messages that uses old legacy color codes to new ones in the ui, so translating old messages could become a lot easier, without everybody doing a program for it

also could be cool if there was a possibility to translate a tipic messages.yml files to use mini messages, that would allow a lot of simple users to change their modified/translated messages.yml to new format, without blaming devs for dropping support for legacy codes

e.g <hover:show_text:"Test">Test

2021-09-27 15:44:57.637 [eventLoopGroupProxy-4-2] ERROR Application - Unhandled: POST - /api/mini-to-tree
java.lang.NullPointerException: null
	at net.kyori.adventure.text.minimessage.Context.parse(Context.java:214)
	at net.kyori.adventure.text.minimessage.transformation.inbuild.HoverTransformation.load(HoverTransformation.java:81)
	at net.kyori.adventure.text.minimessage.transformation.TransformationRegistryImpl.tryLoad(TransformationRegistryImpl.java:78)
	at net.kyori.adventure.text.minimessage.transformation.TransformationRegistryImpl.get(TransformationRegistryImpl.java:96)

ideally support minecraft:uniform etc. but the browser's (custom) fonts ought to be supported as well
<font:Arial>

As you can't render newlines in the title/subtitle, the first line should be the title and the second should be subtitle

The chat and server list display modes are not pixel perfect and the wrapping/lengths are not accurate representations of how the text will be displayed in game. These modes should have a warning, possibly a little ! icon in the top right of the output box, or something, that lets users know this.

Now that the contents of the editor are persisted, we don't need this anymore.

It's bulky and we don't need it - there are plenty of slimmer alternatives or perhaps something fun with webpack to only include the icons we need?

The Minecraft font you use was designed to render perfectly sharp at multiples of 15px 30px (but I have a 2x screen so it's effectively 15px). You currently use 28px which has antialiasing artifacts for me:

30px is not antialiased:

cf. KyoriPowered/adventure#717

Never renders, but also doesn't allow further input ever: https://webui.adventure.kyori.net/?mode=chat_closed&input=asd%3Cre%2Fd%3Easd&st=%7B%22re%2Fd%22%3A%22%3Cblue%3E%22%7D

no errors or anything client-side, just closed with 1006 (abnormal closure), probably an error server-side

Sorta related: KyoriPowered/adventure#723, but that bug causes a logged error in the JS console

The goal is to simulate a vanilla-like layout, with chat, titles, bossbars, scoreboards etc.

Would be difficult to implement on mobile, but tablet and up is reasonable.

Minecraft doesn't like rendering most control characters, notably things like tab (0x9) and carriage feed (0xD), which in-game, become a square placeholder.

This can lead to a misleading representation, where "invisible" control characters are hidden in the preview by the browser, but suddenly become ugly boxes when shown ingame, particularly when copying from other places on particular operating systems.

Or alternatively: expose /mini-to-html as a non-websocket endpoint

It may be useful to be expose the HTML endpoint without having to setup a whole websocket communication.
(Could also be expanded so the websocket communication may also be able to use other, currently POST-only, endpoints without opening a separate connection.)

For reference, the following link should display in the textarea on multiple lines.

https://minidigger.github.io/MiniMessageViewer/?input=This%20is%20one%20line%0AThis%20is%20definitely%20another%20line%0AWHY%20ARE%20THEY%20ON%20THE%20SAME%20LINE

The share button should open a menu that allows for different sharing options. These options could include:

• What specifically you want to share (just mm, mm+templates, all settings, etc).
• If you want the share link to be permanent (using the long url), or a fixed length short URL.

Would need to investigate how to display players in the tab list, perhaps just example players?

By running the project with the JS and JVM modules separate, we would be able to better utilise the Kotlin/JS environment with a node-like system, or similar.

Probably a lot more work than it sounds

Not really sure what I was thinking here..

It's typical these days that people will open a bunch of tabs. It's easy to close them all at once, and if you have changes made in the editor, you could potentially lose your work. Implementing a prompt on close to confirm you want to close the tab would prevent changes from being accidentally lost.

A message like <rainbow>hello<blue> will cause loads of lag.

Right now, all assets from the JVM side (including render responses, HTML, CSS, and JavaScript) are being served without compression. They should be compressed for better performance.

Relevant Ktor documentation: https://ktor.io/docs/compression.html

The navbar has lots of buttons that are very confusing, not-labeled and not-accessible.

Some elements could be hidden behind a burger, nested into proper drop-down menus or even moved into a footer.

Something like the little "run this code" boxes you see on tutorials. Would be amazing for embedding into documentation.

Thats it. When you open a tag, it suggests you possible tokens that starts with user input and completes the tag when you press tab.

Information about the following would be useful to know:

• When this instance of the viewer was started
• What MiniMessage version it is running on
• What commit hash it was built from

This was a regression following the merge of #28

Akin to something like right here on github (desktop) on the top right ↑↑↑

The justification is that it could help people unfamiliar with the intricacies of minimessage syntax (who might be there because of the new editor API ❤️) use the tag syntax, including tags like <hover:show_text> and such.