Refactor this to not use Java

[MattAllison]

I have no desire to install Java and wanted to know if you were open to refactoring this into a different language/runtime.

I did some experimentation refactoring this into TypeScript + Svelte + Tauri and gotten it to mostly work. Admittedly a whole lot of vibe coding.

I'm happy to just keep this for my personal use and don't want to publish a fork without it being ok with you but I'm also happy to put a branch up here if you want to look at it.

Let me know.

[Azhrei]

I’m curious about your conversion. Can it properly extract images from PDF files? And does it allow adding custom overlays? Those are the two things that I most use TokenTool for…

Thanks.

[MattAllison]

Honestly, I've only spent a couple hours on it and have validated core functionality. Those aren't my use cases, but I can spend some time tomorrow to see if I can get them to work. I've never used those features in the original tool (and didn't have it installed on my new PC which is how this snowball started rolling) so I don't have a comparison, but I'll give it a shot.

Edit: I got PDF extraction of images working to create tokens from. No idea what can/should be done about other images like maps but I'll probably just try and add a button to save the image to a file and a Save All button.

[Azhrei]

Wow, great! I ask about the PDFs because I am often prepping NPCs from published modules... And the overlay question was because I use custom overlays to designate types of NPCs.

Sorry to detail your issue, but I'd be interested in taking a look at what you've put together, if your willing to put up a repo for it...?

[MattAllison]

Take a look at https://github.com/MattAllison/TokenTool/tree/refactor/tauri-option-a. I've validated PDF extraction and importing token frames.

Mandatory disclaimer of "This works on my PC, was developed/tested on Windows - cross platform should be viable but is untested".

Instructions for use are in the readme.

If someone thinks I'm a horrible person for this experiment, LMK and I can take it down.

[cwisniew]

I have no desire to install Java and wanted to know if you were open to refactoring this into a different language/runtime.

You don't need to install Java separately. it's included in the installer for the platform, completely contained within the TokenTool app (managed by the installer, too, so if you uninstall TokenTool, it's uninstalled along with it).

I have toyed with/thought about refactoring it using Vue or Rect (or Godot) for a while now (not Svelte as I have never tried Svelte :) ).

I did some experimentation refactoring this into TypeScript + Svelte + Tauri and gotten it to mostly work. Admittedly a whole lot of vibe coding.

If I were to consider recreating it in another language, I wouldn't really consider vibe coding it. Vibe coding little features is ok (as long as you are able to read the code and understand what the LLM did), but not the majority of app from scratch (I know a lot of people are doing it, I also know a lot of apps doing it have security flaws they struggle to fix becuase the people "coding" it don't know what the code is doing, and the LLMs aren't great at fixing the problems found, this also applies for other bugs too). It's probably more work to read all of the code and understand what it is doing than write it yourself.

I'm happy to just keep this for my personal use and don't want to publish a fork without it being ok with you but I'm also happy to put a branch up here if you want to look at it.

Let me know.

[MattAllison]

I completely understand and respect the concerns about writing and supporting code you don't understand but LLM-generated code can be good code - it requires some extra diligence. Treat your LLM like an intern and you're off to a good start.

That said, I (via Antigravity+Opus) did a code analysis of my repo prior to sharing it and I have one from the main branch here if you want it. Happy to share it with you but don't want to just attach it here without approval (not that anyone can't generate it).

Let me know if/how you'd like me to provide it.

[Azhrei]

Take a look at https://github.com/MattAllison/TokenTool/tree/refactor/tauri-option-a. I've validated PDF extraction and importing token frames.

Sorry for replying here, but I couldn't find a way to DM you and issues are closed on that repo. Anyway, I like your solution! It's very modern and the interface is quite responsive. I'm going to play around with it some more, but I did find that on macOS Tahoe (26.4) the hand-drag operation will not copy the image anywhere — not to the desktop, nor to a file manager window, nor to a Discord post. Strange, because it does appear to work to drag it to another browser window. I may play with that some myself.

The only thing that would make this even better would be for a package that can run entirely within the browser. But this is still a nice update. Thanks!

[MattAllison]

Yeah - sorry about that. I enabled issues/discussions. but, again, my intent is not to distract from the great work the RPTools team has done and can bury this if needed.

[cwisniew]

I completely understand and respect the concerns about writing and supporting code you don't understand but LLM-generated code can be good code - it requires some extra diligence. Treat your LLM like an intern and you're off to a good start.

See my comments below. I don't disagree that an LLM can generate good code, but I would argue that it hasn't done so in this case.

That said, I (via Antigravity+Opus) did a code analysis of my repo prior to sharing it and I have one from the main branch here if you want it. Happy to share it with you but don't want to just attach it here without approval (not that anyone can't generate it).

Let me know if/how you'd like me to provide it.

So I spent some time learning a little Svelte ( a few beginner tutorials), so I could look at the code.
Already, I can see that this is structured in a way that is recommended against. It's quite monolithic, and while I have only done beginner tutorials, I doubt that the more advanced ones advocate moving to monolithic code after learning to create components at the beginning (just because that goes against decades of programming knowledge).

It's also overcomplicated in several areas in a way that LLMs tend to do. The thing that sits at the forefront of my mind when reviewing this is "needs a major rewrite to make it maintainable". Sure, I could vibe-code the fixes, but vibe-coded fixes on top of vibe-coded fixes can be like compounded interest, and you end up with a code base only the LLM dare tackle, and often the LLM rewrites large parts for a feature fix, introducing new bugs when you go down that path.

There are also several warnings during the build process that are red flags.

As I said, I am not against people using LLMs to help with their coding when contributing to RPTools orojects, but so far from all the evidence I have seen doing code reviews I would say that vibe coding is not at a point where it creates good code that is easily human maintainable, unless they are done in really smally steps, and even then the changes on top of changes can lead to hard to maintain code, (small projects where the LLM has seen many examples of the exact thing requested aside).

[MattAllison]

My objective here was to test a hypothesis about a rewrite and, to some extent, fiddle with Antigravity. I wasn't trying for perfect or maintainable code - though for fun, I'll take a stab at that (which I wouldn't necessarily trust Gemini for).