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:
- No one seems to want the AGG library because it's not going to be maintained.
- We need something that's flexible, long lasting and has a lot of support for the future.
- I think we need something that has a lot of potential and can be tweaked to be attractive.
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.
My apologies for belaying the point. I wasn't aware that a replacement had been exactly picked so I was just throwing out ideas. All those ideas sound good.
Who is actually working on the emscripten build right now?
There are several motivations to the factoring of the build into extensions, and one is to be able to make the emscripten build less of a beast by taking basically all the extensions out. Because if the executable is fat as an EXE, it gets super fat when it goes through LLVM to make JavaScript. And there's no use to have PNG encoders for a browser that already has it, or FFI when there's no DLLs you could possibly call, etc.
In the past we've made %r3.js files that worked as experiments, so what we're looking for is something that's more than an experiment, which people might actually want to use.
So we are "working on it", but also working on it in the sense that rebmake has more configs. @szeng already added some LLVM support:
So I suppose we're not too many steps away from having an r3.js on Travis. It will happen when it happens.
1 Like
@SamTheTruck emscripten builds are now downloadable as they are part of the travis builds but currently it is all one way traffic JS calls Rebol, but Rebol can't call JS yet.
So, that's why the demo has a console that evaluates rebol expressions.
Thanks. Much appreciation!