Except that standard Leo nodes don't render graphics and other non-text items. That's a big difference. We get around it to a degree with VR/VR3. Hmm, instead of rendering those nodes in a separate frame as VR/VR3 does, we could overlay the rendering frame over the editing frame. We could switch in and out of rendering mode to allow editing. I bet that wouldn't be too hard. One way would be to use a 2-frame tabbed widget. Leo would then have no disadvantage compared with Trillium and its ilk, and would keep all of its advantages.
Yowee! On Thursday, April 25, 2024 at 5:12:02 AM UTC-4 Edward K. Ream wrote: > On Thu, Apr 25, 2024 at 3:49 AM Christoph <rho...@gmail.com> wrote: > > Of course, dealing with hierarchical data sooner or later requires a >> mechanism that allows to put data in more than one branch of the >> hierarchy so this seems to be a logical step. However, Leo has taken >> this step more than 20 years ago and made it its fundamental design >> feature. >> > > And Leo has way better programming features, including c, g, p, > generators, @others, @clean, and the Mulder/Ream update algorithm. > > I'm not worried about competition, and Félix is several years ahead of > would-be imitators. > > Edward > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/0589aa0a-96a9-4a47-9531-ac40397f5d56n%40googlegroups.com.
