Is there a good CMP code editor component? RSyntax...
# jewel
f
Is there a good CMP code editor component? RSyntaxArea works nearly perfectly but SwingPanel causes it to layout a frame delayed, which causes gaps in the layout, KodeMirror is buggy and complicated, SyntaxMP only does highlighting, and net.akehurst.kotlin.compose:code-editor is too bare-bones and not really what I want
s
Not currently, no
Best bet is embedding one of the Swing ones
Second best bet is pointing Fable or Sol at one of the good Swing ones and asking it to replicate it in Compose, then hope for the best
๐Ÿ’€ 1
BTW Swing interop is better if you enable a few flags โ€” I forget exactly which ones lol but the main one is the one we use everywhere we use Jewel in IJ โ€” I think it was kotlinlang.org/docs/multiplatform/compose-desktop-swingโ€ฆ#โ€ฆ
f
It seems like compose.interop.blending is only supported on Windows and Mac, is that correct?
My main problem with embedding the Swing components is that they leave this slight gap in the layout when resizing (the one on the window edge is unfixable on my end, I think it's a skiko issue)
s
I know @Alexander Maryanovsky was working on improving the window edge artefacts for CMP 1.13, so that should be better
And my bad, it's
compose.swing.render.on.graphics
not
compose.interop.blending
I was referring to
The flag has one downside: on Windows and Linux (and macOS if not running on JBR) then redrawing is expensive because there's a texture copy GPU -> CPU -> GPU
I'd like to improve that eventually, I know exactly how and have a working almost-prod-quality prototype, but it would require a lot of work โ€” it needs a bunch of work in the JBR, but I am not sure they'd wanna do it. There's a stopgap solution, which is to implement the same shared textures mechanism the JBR shipped for macOS, to Windows and Linux too. Again, it depends on JBR being willing to do it, or at least take the contribution
a
My resizing fixes won't help with Swing interop. That's a direction @Ivan Matkov is working on.
s
Yeah I meant they'd be useful for the window resizing, not for Swing interop :)
f
Doesn't
compose.swing.render.on.graphics
only apply to embedding Compose inside of Swing, not the other way around?
s
As I said that helps with the window resizing issues
๐Ÿ‘ 1
u
s
I did not know it exists
u
I use it, it works very well
s
But it doesn't seem to be an editor component?
u
github.com/SnipMeDev/KodeView they have that too, but it hasn't been updated in 2 years but I understood that he only needed highlight
s
Yeah that'd not be enough for a proper editor component
It's a part of it for sure tho
u
It's a very large library, it seems complicated for Fable or Sol to rewrite it directly in Compose, but forking KodeView seems much more realistic.
s
It would be a fun experiment to put Fable/Sol to take one of the fully featured Swing editors and rewrite them in Compose but I think it would be difficult because a) tons of tokens, and b) swing UI usually has no test coverage and as such there's no solid ground truth to tdd off of
u
LLMs do a good job when they already have a good code base to work on and are supervised, because they tend to want to cheat or duplicate code, but in principle, from scratch, in my experience, it's not really great, especially since Swing doesn't resemble Compose at all.
a
Text editor sounds like it would be fun to write yourself.
u
the next benchmark for AI agents in 2028, rewrite intellig in compose ๐Ÿ™ƒ
s
Maybe Astra will be able to XD
Everyone focusing on models doing 3D models now, next silly benchmark is porting Swing libraries to Compose XD
u
yes it's probably harder to rewrite swing in compose than to do 3d
s
Tell me about that lol
๐Ÿคฃ 1
f
KodeView just wasn't great to use, the documentation was incomplete, didn't match the actual behavior, and felt entirely AI generated, and it itself was complicated to use and very laggy. It seemed to lose a lot of usability in making itself extensible, so I think whatever I make would have a more monolithic architecture. I do want a full editor component that I can turn read-only, since I a. want to keep the possibility of editing decompiled class files and b. it feels better to navigate with shortcuts and stuff. I was actually thinking about writing a code editor component yesterday. You know, how hard could it possibly be? (also I need an excuse to learn about ropes)
RSTA seems to work okay for now, so it'll wait until I finish the rest of the functionality of the app (assuming I do)