Ren Garden is a project which was originally written in about a month, when I was trying to feel out what a client of the C++ API might look like. It has been periodically brought up to date so that it runs. Recently I brought it up to date so it would build, and made a debug drop for Windows:
http://hostilefork.com/media/shared/garden/garden-6-Jan-2018.zip
We pretty much have Ren Garden to thank for the existence of Ren-C at all. If I hadn't tried to wire up a Rebol evaluator to Qt and a C++ API, I'd not have learned enough about how Rebol was written to start fixing it up.
I think it is a neat demo, and I like to use it when giving presentations (as opposed to just typing in an ordinary console). But while it is a promising application, it has no shortage of flaws and difficulties in its design.
One smart thing Ren Garden does is build on Qt. Qt is a nice, fluid, well-documented layer of abstraction across operating systems. It is true that the DLLs for Qt are somewhat large (the debug ones in particular, and I'd rather people be running debug builds for now). When the pieces Ren Garden wants are put together (Core, GUI, Network) the release build size w/DLLs is going to be in the ~10mb range. Doing a static build which only takes the parts of Qt that you use and puts them into the executable is a labor-intensive process--and not one that sufficient incentive has been around to do. But even then you're not going to see less than ~5mb for that exe.
I'm not too concerned about that. And if you're using KDE on Linux, you already have Qt--so long as you build for the same version as the shell is using, you shouldn't need any separate libraries. (Linux distributions try to build all the KDE apps to use the same library versions as the shell is using, and a packaged Ren Garden would do the same.)
Yet what it does is apply a QTextEdit widget in a somewhat creative way. I was trying not to pull in a full WebKit browser, being a bit size-conscious...and not wanting to make something like an Electron app. This was probably short-sighted, as with the emscripten build we would probably want to make an in-browser experience like Ren Garden, and it would be more able to share code. In either case, since it's a text editor, there has to be some amount of logic to prune off the old history if you have a long-running/long-printing process, because it just gets slower and slower as you add more lines. That's one of the many things that haven't been attended to yet.
The INPUT command doesn't currently work, and it goes through some rather experimental I/O code that works with C++ classes. Writing a C++ "iostream" turned out to be kind of more of a hassle than I realized, and I'm not sure if it's the right direction to be going. PORT!s in general need a major design review, and then thinking about how such ports will interact with C (or if it will have a special C++ interface) is something that needs to be thought about.
Having Ren Garden around helps stress the API a bit. It shows weak points, one weak point of which is still threading... it has a separate GUI thread from the evaluator thread, but even that treads on some dodgy territory.
Because it is basically the largest (only?) app that uses Rebol in an embedded way, it is a good test of new ideas and catching design problems...and so I'm glad it's there. But how to prioritize bug fixes? What features or experiments should be done with it? What is the likelihood that having honed drops of it would expand usage? Who would help, and how?
These are questions people have to answer. @szeng has brought up an interest in whether or not Rebol a Rebol/Qt linkup could supplant the AGG-based /View code... and @gchiu keeps bringing that up too. I've been hesitant to invest more in this because I don't want to be the only one doing it.
Where do other people see this standing, and is anyone willing to commit anything to it? Or is it just another "if I develop it you might use it" situation?
