Fork me on GitHub
#events
<
2022-11-16
>
bruno.bonacci10:11:14

Hi all, here is the recording of last night’s event at the London Clojurians Reveal: lessons learned (by Vlad Protsenko) https://www.youtube.com/watch?v=lZtxc66zU5s

🎉 3
phronmophobic19:11:26

@U47G49KHQ, Thanks for sharing! Lots of interesting insights. I keep coming back to the idea that all we need is a decent clojure-based text editor so that we can integrate all the various tools into a cohesive app.

vlaaad19:11:05

Another alternative would be pitching an LSP interface for REPLs.

phronmophobic19:11:24

• I'm not super familiar with LSP, but I thought LSP already had a programmatic interface • Does that address the problems of multiple windows that you talked about?

vlaaad19:11:06

Eh, I meant pitching to LSP maintainers an extension of LSP that defines a protocol for adding generic REPL support. The intention is to not have yet another text editor, but instead to have a standard that can be implemented by any text editor and integrated with language-specific tools

vlaaad19:11:19

That will allow defining a way to embed such tooling into text editor, so there won't be extra window problem

phronmophobic19:11:45

So the result would allow for embedding something like reveal?

phronmophobic19:11:38

Are you imagining something like https://github.com/BetterThanTomorrow/joyride, but with an API that would work with any editor?

vlaaad19:11:55

Yes, embedding something like reveal, and without having to write bindings for every possible IDE that we want to integrate with

vlaaad19:11:15

Joyride is vscode-specific, I want to avoid IDE-specificity. LSP is IDE-agnostic, basically an interface that can be implemented by text editor to support language tooling

phronmophobic19:11:44

Yea, I hadn't thought about that because it's really uncommon to embed UIs from other languages/environments/runtimes. Maybe that's possible? I know ChromiumEmbeddedFramework does that.

phronmophobic19:11:09

There's also onscreen rendering, but that would require pretty deep integration for both the IDE and the tool.

vlaaad19:11:11

I was thinking, maybe this interface will not be about embedding UI, but instead about a common DSL for UI. THE problem to solve here is what this DSL will look like.

phronmophobic19:11:23

That's one of the problems I'm trying to work on for membrane, but in my experience, it's not a problem anyone really wants to work on.

phronmophobic19:11:10

I think the data model that Figma has is like 80% there, but there are a lot of details to work through.

phronmophobic19:11:21

IMO, the general gist is to define your UI in terms of shapes, text, and images (which is platform/framework independent).

vlaaad22:11:45

How would an expandable tree view with scrolling work there?..

phronmophobic22:11:43

Why wouldn't it work?

vlaaad22:11:27

Because something has to implement scrolling

phronmophobic22:11:06

I've written a lot about how I think that should work, but the short answer is that's what membrane does. Here's an example of a treemap view that runs inside portal (on the web) and inside reveal (in cljfx). It's the same component (the slight differences in output are because they're using slightly different versions of treemap-clj). This particular example isn't an expandable tree view with scrolling, but I've built those before and it would work the same way. https://clojurians.slack.com/archives/C02V9TL2G3V/p1647286579886189?thread_ts=1647170441.434869&amp;cid=C02V9TL2G3V