Ultimately whatever GUI gets developed is not going to depend on which system is ultimately best in terms of long term maintenance and flexibility, but upon whoever does the work, and what their needs are.
I think that this is better than the alternative of nothing at all.
My basic idea is that it's something common that will be easily updated and basic. Most of the processing should be done in Rebol/Red for the widgets. I know X-Windows is a huge hair ball but it's not going anywhere and is likely to be available for most all platforms. Display PDF is used on the Mac. It is interactive of course. A great aspect of postscript is there's lots of graphics programs where you could save to pdf and then use that as your graphics. If you look at Gabriele Santilli's article I linked above he really lays out a great path. I want to add to it that you can draw widgets without being a x-windows programmers.
I looked at RED source code and was not able to tell where he was calling what to do what. I'm not knowledgeable enough to do this. My only programming experience is FORTRAN and assembly language on 8088 processors so I'm not a complete idiot but the gap in my knowledge is huge to say the least.
I sure you're correct. It doesn't hurt to ask through. Maybe someone will think the same.
OK I made a mistake. QT is it. I assumed that QT was built on top of X Windows. I think it used to be. I just looked at the QT wiki and it has changed a lot since the last time I looked at it. It's been rewritten and works on a huge number of platforms and will probably be maintained. It's looks like QT is the best way to. Also it uses the underlying OS's functions just like RED is trying to do so...why not just use QT instead of RED trying to rewrite all this stuff?
QT works on everything and X Windows so with X Windows you cover all the Unixes. Great! Not only that it has widget design tools. Can't beat that.
When I was looking last weekend I downloaded this V-Play cross platform mobile framework that's on top of Qt. It wasn't perfect but it looked pretty good to me considering it's cross platform where the same code works for iOS and Android.
Not arguing it's the right answer for the main Rebol 3/Ren-C option but I was just imagining maybe as an alternative option down the road... I thought maybe a first stab at it should just use the Qt 2D drawing api and see if it can match what the AGG library had been doing and see if the Saphirion gui stuff could work again:
Leading maybe later to a separate effort using Qt widgets instead of drawn widgets.
(likewise the same idea using HTML5 Canvas in the browser with that emscripten build of Ren-C)
I should say I've never used Qt btw I've just played with it a couple times evaluating the possibility.
The two things I remember was just that the file sizes were on the bigger side (I remember around 30MB for a mobile app install for a somewhat modest app).
And the other was that I wasn't 100% clear on their license policies. My recollection is that you are free to use it in Open Source for free, but if e.g. in this case a Rebol user wrote a commercial app to sell using this Rebol running atop Qt then I'm not sure but I think that becomes an issue and they are expected to have paid for a Qt license.
(I'm not sure about this take with a grain of salt but I think it might be true)
I can see one problem. QT license is not BSD and you would have to release all code. I don't have a problem with that but I bet there's lots who would. Sigh...
Interesting about the BSD license stuff I confess I've never looked closely at what the different open source license types do/don't require. I believe when I was looking at Qt's mobile stuff a couple years ago I'd exchanged some emails asking their salespeople directly what the restrictions were (I should try and find that email if I do I could post it).
Otherwise fwiw when I put aside thinking about this stuff last weekend I said to myself if I found time to play with this more, for me personally I thought I would start by seeing if I could replace the AGG stuff (see e.g. "host-draw.c" in the rebol 3 source) with HTML5 canvas equivalents and see if it would possible to get the "load-gui" (drawn widgets stuff) working in the browser atop this emscripten Ren-C build @hostilefork and @rgchris have got working.
Partly just cause these days I'm mostly a javascript/browser web app kind of person. 
But also to me that doesn't replace the Qt idea, it would be in addition and could be a parallel effort if somebody else pursues the Qt ideas.
(at one time I thought the Qt stuff would be the answer even in the browser because I'd seen the Qt emscripten demos at
http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Wiki
but I've since looked closer and I notice those aren't from the Qt people they're from a third party, and they're even an older version of Qt it's not up to date with the recent cooler stuff they've been doing with e.g. a more mobile look and feel)
Update: here's some efforts to get the newer Qt widgets working with emscripten (still looks pretty green though):
Sorry, did you say that you have something working right now??
No not me so far I'm mostly just talk 
I was referring to this "Try Ren-C" repl that @rgchris created from the emscripten build of Ren-C that is working in the browser just fine:.
http://reb4.me/tt/rc
It's just it's quite limited without any gui abilitities.
This is where @hostilefork explained that he's stripped Ren-C of the AGG gui code because he intends Ren-C as the new "core" - i.e. the foundation that other things would build on so he wants it minimal and e.g. devoid of GUI.
(which I think does make sense e.g. with this idea of there possibly being one path doing gui with Qt and another with HTML5 Canvas or later maybe with html DOM components such as react.js etc)
Oh well, I was hoping!
I think this wouldn't be the case if linking against Qt dynamic libs. Also, as it's been pointed out recently, Qt has been making some pretty good progress in making code more modular and hence Android apps might not be so large. Having said this, I'm not sure if the modularity they described would be applicable to dynamic libs - possibly those would have to retain the form in the original distribution.
I've thought about this also and using browsers for rendering.
Here's one other idea I ran across. Back in the day Sun made a window GUI system called NeWS (Network extensible Window System)
The cool thing is it's postscript and therefore can be made to look whatever you want it to look like. Apple has done great with this as their display is postscript based. I bet the OpenWindows is not a large library as it was done in the 80's.
The whole gist of why I'm even talking about this is that you could make the engine with postscript then have the various widgets drawn by people with less programming talent. The display could be done with people of a more artistic ability while keeping the same underlying technical base. Also it would be there for most of our lives as postscript is not going to change. It's there. Let's say there's a new OS then compiling and changing the widgets with a paint program to mimic the look and feel and your done. No low level library work is necessary.
I think the Open desktop made a huge mistake when they went with gnome libraries instead of with Sun's postscript based system. Apple stuck with a Display Postscript based system and it looks great. Gnome has a huge confusing mash up of libraries all smashed together to do what one display technology(postscript) could do.
There's a open source version of Apple work that is available although it's a whole windowing system and all. Maybe parts of it could be taken. It's a continuation of NextStep and OpenStep.
https://www.revolvy.com/main/index.php?s=OpenStep&item_type=topic&nojs=1
GNUstep
Re:
HTML5 Canvas
I've thought about this also and using browsers for rendering.
Just in the course of looking at Rebol and these various options I've come to appreciate more that the whole emscripten/webassembly idea is pretty powerful i.e. that looking 5 years out or something there may be a lot more C code running in browsers... it's just really early days yet as this stuff is maturing.
(note e.g. the gui examples here: http://floooh.github.io/oryol-samples/index.html)
i.e. At first I just assumed that a bunch of work would be needed with a ton of javascript written to get the equivalent of rebol-view (i.e. the r3 saphirion/atronix load-gui widgets) running in the browser.
Now I don't think that's the case i.e. ren-c can remain the solution for the browser. There's no need for some big time rewrite to javascript. And that saphirion/atronix r3 gui should be able to work. Of course assuming people are willing to live with some of the look and feel compromises of those widgets (but rebol has a tradition of multiple gui options right, so it's not like this would be "the" gui widget solution just "a" gui widget solution right).
Right now I'm struggling to get started because the builds are a bit shaky and/or my own C/make skills are pretty rusty (so when the docs aren't completely spelled out or if I hit even the smallest snag it's a bigger problem for me than probably it should be). I filed an issue and was asking questions about it here:
https://github.com/metaeducation/ren-c/issues/585
(they explained they are transitioning to a new all-rebol build system back away from cmake).
@SamTheTruck
Re the Display Postscript / OpenStep / GNUStep ideas I confess I'm old enough when I was just out of college I did do X Windows apps on OpenWindows and I do remember NeWS was on the Sun Workstations I worked with.
Otherwise I'm pretty unfamiliar with display PostScript and what that would mean / how that would be incorporated in Rebol... or is this the idea it doesn't need to be incorporporated "in" if Rebol talks a message protocol to a backend ala X Windows?
(atm I was just having fun looking if there was any low hanging fruit type of solutions I might be able to help implement which is why the emscripten/html5 canvas stuff has captured my interest - I guess it's also a question of who the audience is right - in my case I'm doing web apps myself these days and am gravitating towards the browser and trying to appeal to web developers if Rebol can produce browser UIs with less lines of code required)
I should mention, for what it is worth, that Nick Antonaccio has repeatedly said that he wants to see a Rebol GUI in the browser...and would be willing to contribute funds of some amount to seeing this happen:
I'd still be willing to finance an Emscripten build with View based on HTML Canvas (or WebGL, etc.). I have seen the Emscripten build of Core - Isn't there any interest in being able to create full fledged GUI web apps purely with Rebol?
http://rebolforum.com/index.cgi?f=printtopic&topicnumber=22&archiveflag=new
I don't know exactly what he has in mind, but he has written quite a number of tutorials and apps. I imagine seeing those run in the browser, without having to make radical changes to the code, is probably what he's looking for.
That's interesting. #I don't know why post must be a minimum of characters so here's more characters for nothing.
I don't think that's exactly what he wants. I think he wants Rebol completely translated into javascript so it runs in a browser. Not just the GUI elements but the whole language.
Ok here's one last try at a library for Rebol # GUI. Here's my assumptions:
Here's we go. Cairo
"Cairo is a 2D graphics library with support for multiple output devices. Currently supported output targets include the X Window System (via both Xlib and XCB), Quartz, Win32, image buffers, PostScript, PDF, and SVG file output. Experimental backends include OpenGL, BeOS, OS/2, and DirectFB.
Cairo is designed to produce consistent output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension).
The cairo API provides operations similar to the drawing operators of PostScript and PDF. Operations in cairo including stroking and filling cubic Bézier splines, transforming and compositing translucent images, and antialiased text rendering. All drawing operations can be transformed by any affine transformation (scale, rotation, shear, etc.)
Cairo is implemented as a library written in the C programming language, but bindings are available for several different programming languages.
Cairo is free software and is available to be redistributed and/or modified under the terms of either the GNU Lesser General Public License (LGPL) version 2.1 or the Mozilla Public License (MPL) version 1.1 at your option."
GTK+ 2.8 and newer depends on Cairo so it should be around for a while.
Some of the complications are Cairo depends on Pango. It lines up text.
Which in turn uses HarfBuzz to make the actual text or glyphs to be ordered by Pango.
If these are used then in most BSD and Linux systems the files will already be there and they can be used in Windows and Mac also.
Untangling this mess of libraries would be difficult but it would produce a long lasting, quality output for R3.
I'll reiterate that there are two GUI-based Rebol-y things that are reasonably going to happen in a near term time frame:
R3/View - will be based on OpenGL, and the GUI dialect will probably not be too different from the one in Atronix R3/View that is available today. The main difference will be that it will be implemented as an extension; hence able to share the core interpreter code with other Ren-C systems. It will likely not be retrofitted to be compatible with Red's VID, and what is implemented will basically be through Atronix's agenda for their app. They'd accept third party changes which improve it or bugfix it, but likely nothing that would slow them down.
Ren Garden - currently focused as a smart console with debugging, but due to using Qt would be an ideal baseline for adding some VID-like thing into the same build. There are two possibilities for what that thing would be: one is a copy of Red's VID, leveraging their documentation but being on more platforms, including 64-bit, and trading off the need to take responsibility for writing and maintaining tons of platform independent code for a larger executable. The other possibility is to decide Red's VID is not a winner compared to leveraging QML's popularity and dialect QML instead...which may be easier.
Since we are already invested in these native solutions, the direction is not likely to change. That said, I seem to remember when I looked at OpenGL R3/View, that it seemed to have a bunch of dependencies, and Cairo might have been one of them. You can ask @szeng about this; what the dependencies are and what they're used for.
If I were to endorse any new idea in this space, it would be regarding what @darrencruse is speaking of, with an emscripten'd Rebol in the browser, and wiring it up to something that lets people develop "GUI" apps. The priority of getting a tidy emscripten build and turnkey build process is very high, and we are advancing on that as we can.