As we all frustratingly know there's no GUI being developed for Ren-c, which is the only actively developed branch of Rebol3. Atronix do have a GUI build on their website, but it's an old build which lacks many of the changes that exist in the current builds. We did discuss this before but that ended with the view that r3/view was imminent. Unfortunately it seems Atronix don't have the time to prioritize the move to Ren-c.
So, I was thinking how one could usefully build something with what we have, and I thought back to my GUI demo. So, I am thinking that there's a common set of functions which each client knows about. It could be a script present on the local file, or it could be embedded in the server. Each client then polls the server for a task. The server marks off each task as it is collected by a client so that another client can't take that task. A callback to update the GUI is attached to that task. The client then posts the results back to the server which marks the task as completed, executes the callback with the resulting data, and then removes the task. So, this would be totally asynchronous as the hard lifting is done by the clients of the GUI based server.
This means that the GUI could be Rebol2, R3/View or even Red when it gets TCP working. But how much more work would this create? Is it a feasible way of creating an application?
First of all, WAITING for Red to get TCP working is not a good option. It is a dependency we have zero influence on, might as well wait on Carl to join in and create a GUI for us for Ren-C. Who knows how long that could take.
About Atronix, it would be great if they did prioritize move to REN-C but there is a risk for them too, all changes for the better by Brian mean they have to be aware of more migration issues for their codebase.
So the best thing is indeed work together on a solid base for a GUI for REN-C. Perhaps one of the VID projects by Henrik and others can be a good start. (VID-ext-kit, VID junior)
We "all" want it, so Mac, Linux and Win back/frontends are needed.
I say just get it started and go for minimalistic for starters and get the basic principles put down in documentation once a start is made the rest will follow.
Using vid-ext-kit is a possibility that I hadn't considered. I don't know much about it except Henrik is still actively developing for it. I guess that would mean it would run on windows, Linux and Mac.
Like RebGUI, VID-ext-kit is built upon VID that uses Rebol/View.
I think you really want to build Ren-C/View capabilities first to support a new GUI building interface like VID?
For the latter part, creating the VID alternative, I think the start Henrik made https://github.com/henrikmk/VID-Junior is a promising one. Taking the best of all VID like GUI-interfaces but not syncing all possibilities at all costs for all platforms. The RebGUI by Ashley ( http://www.dobeash.com/rebgui.html ) I like for its minimality philosophy.
So how to start getting View on Ren-C is the big question.
For bridging that gap we could take a look at how it is done elsewhere but there are lots of missing pieces of info and looking at other languages they tend to use multi GB big frameworks so that isn't a serious option in many cases.
Serious options are to go and use Qt or use OpenGL. From the thread I get that using OpenGL is the way Saphirion and Atronix are going. So perhaps that is the best way for this project to follow. And maybe persuade Atronix (szheng) to make a contribution to get things started and guide this project in the right direction, thus helping 'us' creating the /View module for Ren-C that will be compatible for them too.
@hostilefork pointed at the file rebol/src/tools/file-base.r at master · rebol/rebol · GitHub for an unrelated issue, but in here we can see that there is a file view-funcs.r containing the view engine. Also there is something called agg-files that collects cpp agg files for some import I hope.
Thus:
a) what is missing to get this working?
b) if one would like to use another framework (OpenGL it is), how to connect this instead (or additional).
c) can we find extra expertise on the internet? (more information/ people with knowledge looking for a better hobby?)
d)
shall we stop contemplating that eternal dependency on other people once and for all?
We are going to build that feature no matter what it takes right? Right!
I am at a point where it would be very helpful to have a design of the module structure to be followed. For example, there will have to be C code that must be compiled with the R3 source code and for OS specific support there will be C code for binding that that must be compiled, and there will be some Rebol code to get the view dialect supported.
A sketch and some design talk asked for.
The rebmake specification is all still very much in its infancy; Shixin worked on it for a while and then stopped, and I haven't really stopped to look into it much. But he did add a way for a file in the extension's directory to specify some things about how that extension is built...what libraries and includes, etc. In ODBC's case that's in %odbc/make-spec.r
A sketch and some design talk asked for.
As much as I would like to see the build system improved, it's not something I'm going to be talking about or instructing anyone on. It's something I've kind of "inherited" and most everything I've done to it has been attempts to simplify what was there.
It's a rather gargantuan task to be trying to get a cross-platform build system that runs on only Rebol and can pull together linking of libraries in a ton of different build environments. I could give a design talk just on how big a problem that actually is--without needing to mention Rebol. But that's another thing I don't have time for.
What we can do is going to be to tease out Rebol as a library. Then what most people would do is to build their application using whatever build system is most comfortable to them (CMake, GNU make, autotools, Visual Studio Project files, etc.) And they'd simply add in libRebol.
But for the moment, building the r3.exe requires rebmake, and extending it is something people are going to have to either be self-starting on or do without.
I have my focus now on glfw.org Oldes made a binding for Red/System for it.
I have to figure out next if it is C or C++.
And if somehow I compile this library with the rest of the Ren-C sources,how to address the new functions from a Ren-C script.
If I see how many people were thanked for contributing to glfw, I know also how many people with IT skills, retired or youngsters starting C looking a challenge, are out there somewhere unaware of the opportunities here. And now filling their time with Netflix, Youtube, Twitter and Facebook. (I suppose this last alinea is food for the rants!)
learn some new tricks 
!