View doesn't currently run under Ren-c though @szeng has an unpublished branch where he is working to get this going again. Even then, r3gui won't run due to delect being removed.
Once view can run again we will discuss the options of how to get a GUI dialect up again.
@rgchris No, but I don't see any particularly good reason why it needed to be a native. Then again I didn't really understand what DELECT was for, exactly. When I found out Atronix wasn't using it and it hadn't been tested, I mothballed it. If it needed to come back, it could be part of the GUI extension and still be written in C.
@darrencruse I encourage those who want to use a GUI to contribute to the Red efforts in developing and documenting theirs...and giving feedback on whether it is good or bad.
If they prove a market for it, and define it well, the Ren-C approach would be just to pick some cross-platform GUI framework like Qt/QML or Juce and copy it:
I'd personally be more compelled to see a generalization of Atronix's ZUI so all apps were zoomable with varying levels of detail, rather than worry too much about the "80's cash register" UIs...
my thoughts fwiw (and I admit you guys are light years beyond me I may be completely wrong) was that the approach Red is taking of using native widgets is trying to raise the bar on quality but at the expense of it being a lot more work and time to achieve their goals.
i.e. I did ask them about a browser based solution and they said they are far away from that not only on the GUI side but on the side of generating WebAssembly from the Red/System core.
So I'm probably naive but that's where I thought Ren/C built through emscripten along with a working r3-gui was going to be more doable with less effort(?)
e.g. I thought r3-gui was literally pure rebol using the underlying draw commands sitting atop OpenGL. That's why I thought maybe it wouldn't be terrible to get things working. e.g. I notice a lot of games have been the first things to port and demo with emscripten so I feel like there's a lot of examples to reference on that....
Otherwise I agree the look of the r3-gui widgets is bad, but there too I thought maybe a makeover of their "look" might help and might not be too terribly hard (mostly I was just thinking a simpler flat Bookstrap/material-ui type look would help so possibly even simpler than the current widget drawing code in some ways, I also thought of looking at JavaFX widget code for reference as they too are drawing their own widgets not using native widgets).
Anyway hope I'm not annoying it sounds like possibly I'm naive about the difficulty of some of this (e.g. more native code and less pure Rebol code than I realize?)
Rebol uses the AGG open source library. Unfortunately the author died a few years ago.
Atronix wish to move to I think OpenGL and @hostilefork has stated that he thinks Qt could be used with similar effort. But the initial work I believe is to get AGG working again and then take it from there.
Thanks @gchiu I hadn't realized it was AGG being used.
I was just googling about it and I see reference to Cyphre doing some work to make it easier to get the codebase more agnostic to which graphics library is used?
e.g. Do you by chance know if the use of AGG is well separated in the R3 codebase to a few files versus it being spread throughout the code?
Also I saw a suggestion that the apk file for R3 that does run on Android might already be converted to use OpenGL? Is that not true?
Re @hostilefork mentioning using Qt that seems like a reasonable idea too. e.g. I see Qt demos running in the browser via Emscripten. Also I wonder if the Red guys ever considered using Qt to get to true cross platform UI support quicker? I'm guessing they didn't choose it because it's heavy file size and Rebol has always embraced keeping things small?
It is the case that historically, Rebol has gone for the idea of getting a cross-platform bitmap buffer abstraction, and draw onto it. It was based on AGG:
I'm fairly sure this is how Rebol2 worked, as well as the GUI efforts of R3-Alpha, which Saphirion started out making and Atronix took over. Atronix then began work on using a similar approach with OpenGL. I will note that there have been success stories with this approach...e.g. in Blender w/Ghost:
But even given the idea of "give us a screen buffer, we'll draw in it how we want", the layer was not "just draw commands". It was C code that implemented Graphic Objects, or GOB!s, and then the interface was built out of them. So there was a sort of abstraction underneath the Rebol code that implemented the interface for organizing the visual hierarchy and doing event handling.
We know Rebol influenced JSON, and Rebol/View and Tcl/Tk influenced things like QML:
But my own priority is to figure out a solution for what Rebol is as a "genre" of programming. If we understand what makes the language unique we can apply that to these very widely studied domains. But if we don't know the limits or execution of the language, I think there's a very limited education gotten by stumbling in a widely studied domain with the weakness of a half-baked language.
I'm not sure I see it too far removed from Carl's idea of a 'Messaging Language'. Whether that message is that which is now typically packaged in JSON or indeed one that includes a GUI, a dialect, a script or whatever. It lives within a distributed space that we just currently muddle through with blunt, overbearing and not particularly savvy tools.
JSON only ever understood one part of the equation. It's simply too constrained to carry anything other than data. Folks have tried to make XML do more—I think its cousin HTML does an okayish job of marking up text—but as a mechanism for delivering a UI (HTML, XUL, WAP, etc.) it's way too verbose, complex and has to delegate any hint of scripting. Even successful 'dialects' such as SVG rely non-XML sublanguages (CSS, path coordinates): XML parsing is only ever the first step.
So to scripting—it's fair to say that Javascript is the most commonly shared scripting format out there. Indeed, a script sent to me by our hosts here is currently regulating my input as I type right now. However, despite its dynamism, it's steeped in a conventional, rigid syntactical straightjacket that is adequate for data (not really a data format beyond JSON), not good for dialects and even for coding is obtuse and opaque.
There are more appealing scripting languages, but none really cover all these bases like Rebol. However you feel about the '80's cash register' style, there's really not much structural difference between: <textarea>Type your message here</textarea><button type="submit"> and view [area "Type your message here" button [submit]] —just implementation. One is ubiquitous and successful, the other hampered by an underdeveloped UI framework.
As an implementation, VID has flaws, no doubting that. Though it tried, it didn't really address security concerns—not nearly to the degree that today's browser sandbox does. The spartan UI elements were never going to appease the control freaks or those that wanted to camouflage within the host OS's native schemes. It was a shot for the stars that barely broke the atmosphere.
As a language, I'd like to think Rebol can hold its own—I think what we lack (for now) in ecosystem, we make up for in how well Rebol can bind disparate systems together with just the core components—parse, ports, series and values. The capability is there...
Save to say, I continue to see the revolution in Ten Steps and the Desktop concept*, so close, so tangible and so elusive.
Zoe looks really cool, and I think is well served by our language and such ambitious use should ever be catered for. However I still think Rebol's niche is in doing what so many apps and webpages do, only as lightweight, versatile and concise constructions threaded by rich dialects and a robust core. Really opening up forms of expression heretofore the preserve of the masochistically perseverant.
*again I can only imagine if phone os APIs had started with that as its base—would have thoroughly democratised mobile app development
The Android version that we have doesn't have GUI. I don't know what Cyphre's version used as the source was never released.
The one I was playing with that "Demo" that shows the R3 Gui widgets on my Android phone was the saphirion one I'd gotten the link from here
But I'm guessing your Cyphre comment applies here too since I only see one branch here and the README says:
Currently only Windows port of Saphir is published in the repository and guaranteed to compile under MSYS. Other various systems/platforms will be added in the future repository updates.
I also found Cyphre's android arm branch here but from a quick glance at the files there I don't think I'm seeing Android gui (opengl or whatever) changes there.
@hostilefork it occurred maybe I was slow to understand something - your Ren-C repo is titled a "Library for embedding a Rebol interpreter into C codebases".
Was the idea that Ren-C is intentionally devoid of graphics and just providing the core interpreter on the idea that the embedding program would be making the choice of pulling in Qt, or something else, or no graphics/gui at all if it doesn't need it.
Where you said you're not keen on the "80 cash register look" anyway so maybe this was setting things up for a separation between the GUI dialect and what's used behind it right. i.e. This was your rationale for removing some of the host-draw.c etc. files I see in the other Rebol 3 source repos?
That doesn't seem unreasonable I was possibly slow to pick up on the big picture if that's how you're thinking.
e.g. I could imagine your Ren-C core married with the R3 GUI dialect with Qt widgets behind it (like you said), as well as the emscripten compiled Ren-C married to html5 widgets and/or canvas drawing behind it.
atm for me where I'm unclear surrounds making the connection between the GUI dialect and what's sitting behind it doing the widgets and/or the drawing. In a perfect world I could imagine some kind of documented "driver" "interface" thingie to help people wanting to implement the GUI dialect using some widget library/drawing library of their choosing.
Connecting your thoughts above with this discussion here about Ren-C not included the drawing/gui support code.
I've played some with facebook's react-native library for creating mobile apps using javascript as your language even though native widget sets are being used to draw the UI.
And the way they've architected it involves almost like a client/server type of architecture where the javascript engine is running separately from the native code drawing the widgets with the two "processes" (or what feels like two processes) communicating json messages between them across what it calls the "bridge".
It strikes me this could be a very Rebol-appropriate architecture for what we're talking about here. So the devoid-of-gui Ren-C core "client" would be running only the Rebol code but sending dialect messages to different drawing/widget "server" processes depending on the platform.
So the same ideas as above but where the focus is less on embedded code and function calling but more on message passing leveraging Rebol's strength as a messaging centric language.
(the react-native architecture is one model for this approach, another is the X Windows protocol)
I've put "process" in quotes above because to me the ideal is that these wouldn't have to truly be actual "processes" the point is more that it feels in the programming like sending async messages to something running concurrently. e.g. a react-native app doesn't literally require two physical processes it uses threads, otoh the X Windows prototocol does use two processes which allows the cool ability to display the UI on a different machine than the program is running on. I see that Rebol has the "port" abstraction for sending messages right but I've not seen it provides concurrency abstractions i.e. threads, coroutines, etc. It would be neat to me if the separation discussed here could be in process or separate processes...
I'm also new enough to Rebol I'm not clear if literally the R3 "gui dialect" would be the thing passed - I assume not I assume something lower level whether the "draw dialect" or something new more like a "widget dialect". And going the other way the native/browser/whatever side might be sending messages back embodying the user input events.
I think it's an interesting thought that might set things up nicely, once there was some docs surrounding the message protocols and a reference implementation or two hopefully it might encourage people to contribute new "platforms" based around e.g. Qt, the browser, javafx, etc.
This has kind of been what's been happening with react-native btw. There's a number of different projects targeting different platforms now but all using the same react/javascript/widgets-as-tags-in-xml foundation.
But as you've said - it's nowhere near as concise or as easy as these Rebol GUI dialects!
I agree. But I think it's still true. Mobile phone OSs aren't going away soon. And if we can get to the point of developing apps with just Rebol and some GUI library, then we'd have the world beating their way to our repository. Red was part way along that path when they suddenly stopped, and went back to Windows development
I wonder if it's feasible to write a dialect that generates JSX instead of JS directly?
Me I got excited when you guys pointed me at @rgchris working Rebol 3 repl-in-the-browser "Try Ren/C"...
(though if you saw my final message in that other emscripten thread - I'm disappointed I've tried a bunch but I can't seem to build my own version that works the same and I can't figure out why)
Prior to that I was thinking of something more like Topaz or a WebAssembly backend for Red/System was going to be needed but Topaz doesn't seem complete or Rebol compatible and the Red approach seems like a big undertaking to me I wouldn't hardly know where to begin.
If I could understand how to properly build Ren/C with emscripten with it working like Try Ren/C I could see that as the foundation for some interesting stuff (I do react on my day job and have played with react-native so I'm pretty familiar with the browser javascript world).
The Clojurescript Om library marries the React backend with Clourescript language that transpiles to javascript so kind of similar.
On a somewhat related note I was going over more Rebol basics here and I notice the tag type example with attributes e.g.
markup: <font size="2" color="blue">
But I don't see any reference to getting at attribute values e.g. the "size" or "color" from the above?
I played with it in the repl thinking maybe it would be like e.g. markup/size but no go.
googling I found this from (you guys are awesome btw!) the very @rgchris above:
So the parsing done above would be very similar to what JSX transpile would do.
But the missing things compared to JSX would be the ability to escape out to e.g. have variable values inserted as attribute values and stuff like that. Or to jump between tags that contain code as their "child" e.g. with a for loop that goes back to outputting tags.
I probably don't know dialects well enough to understand whether/how they support such jumping back and forth, esp. when you add the wrinkle of using the emscripten approach for running the Rebol code.
(it's all a bit fuzzy to me right now how exactly the pieces would fit together - this was partly what led to the thought I wrote about above of whether the Rebol and the javascript could be running concurrently and only communicating via messages - that seems perhaps to simplify some problems and complicate others?)
We're in the middle of a major change to how building is done. One of the goals is to stay pretty much completely in the Rebol universe and not depend on CMake or GNU make.
A big motivation of this is to get more control over the build process programmatically. High on the agenda is to make it easier to pick and choose extensions and configurations. We'd like the emscripten build to be as light as possible.
I agree that having the engine running in the browser should be a high priority. One unfortunate thing about emscripten is indeed that if you are deep in running a function and you try something like getting user input or doing some output, you can't get the browser to update unless you return out to the top level. So what we've had so far was where INPUT is done with a modal pop up, and output only shows up when the code is done running.
There are ways of working around this, such as by actually running a JavaScript emulator in JavaScript. :-/ Then it can suspend the state of that emulator while you acquire your input or whatever, and once that's done your web loop can resume it so that your emulated state (which is actually a C stack) can be reentered. A poor man's (mad man's?) continuation. Sounds pretty nuts, but people have apparently added the feature to emscripten somehow.
We'll try and get a solid build story to you for emscripten so you can experiment...
I'm going babble a little but bear with me there's a point. I really like Gabriele Santilli 's ideas about the R3 GUI and I have some ideas too. I think one of the most important attributes needed for a R3 GUI is for it to be easily cross platform, most of the GUI work should be done in Rebol(RED,R3), the only low level libraries should be doing low level stuff like the AGG library and there should be a program that could change the look and feel(widgets, requestors, etc.) based on the idea of a paint program. So you could go to a tool menu and drop down this tool and select any element of the GUI in the program and modify it. This could be a cut and paste Rebol script placed in all programs or used to set the look and feel then deleted. Also be able to save the configuration. In this way someone not a C++ programmers could create infinite styles , gadgets, requestors, whatever. All this doesn't need to be done all at once but picking the right library and following steps so that R3 doesn't get stuck with old libraries is important.
I think that using QT for the GUI library is a mistake. The reason is it's a high level library that works at a much higher level than AGG. It does have better interface because the work for building widgets is done in the library. I presume that's the reason that Rebol look and feel did not change much because it's difficult to change the widget look and feel and only much more experienced programmers can do so. If you pick it you will be mostly stuck with what QT gives you.
OpenGl is sort of the same. Lower level I believe a lot of the widgets would have to be built at a low level.
So what are the alternatives. AGG worked. If someone agreed to pick it up and maintain it. The question is does it need maintaining at all. Isn't it done or close enough?
Here's another alternative. X-Windows. X-Windows has all the low level primitives to build anything. All the GUI libraries for Linux, BSD, etc. are built on X-Windows primitives. I think OpenGl is too, at least on the Unixes. It's a difficult library to work with. Very confusing but it's on most Unix platforms and available for most anything you would need. Look at
More on X-Org which the same
X-Windows runs most everywhere. Windows, Unix, Browsers, etc.
Another alternative I really like would be Display PDF or Postscript. The lower level display part(we're talking lines, circles, curves, low level) would be PDF but all the upper level coding would all be R3 or RED. This would provide an infinite variability to the tweeker while also providing quality output This is what Next and Apple OSX use for display. This could be complicated but if you didn't try to do everything at once then it becomes less daunting. Gabriele Santilli has some PDF output code written in Rebol. Maybe it could be used. Later by tying the code to OpenGL libraries (could be in X-Windows) you could get hardware acceleration in most OS's while keeping the same R3 or RED code at the base. The key would be to only use very primitive calls in any graphics library that called the OS and build the complexity only in R3 or RED.
I think Docs method of using the OS library for the GUI is a mistake. Not because it won't look good or be fast but because of social reasons. One day Doc and his team will be so burnt out on RED and others on R3 they won't even want to look at it. Isn't that what happened Rebol? As all the various OS GUI's are moving targets then you will need a highly skilled super smart programmer to keep these running. These are hard to find. So eventually the whole thing will break up like Rebol did.
If you only use simple drawing commands in your libraries or PDF type libraries then the low level stuff will be more defined and easier to maintain. At the upper level look and feel of the OS could be copied by less skilled with PDF drawing programs that import the graphics.
QT , GTK or some other higher level library would probably be the quick way to get a nice looking GUI but you would quickly become stuck without a large amount of maintenance. AGG would actually work fine especially if you used the vector graphics for all the GUI elements or at least the outlines then fill with bitmap. I think the best would be PDF display as it;s not going away probably for ever and ever but...complexity to get going. After it was done with a tool kit written in R3 it could be maintained much more easily.
Here's a nice PDF library for reference. There's quite a few of them.
So what are the alternatives. AGG worked. If someone agreed to pick it up and maintain it. The question is does it need maintaining at all. Isn't it done or close enough?
I thought the reliance on AGG was the main reason we don't already have Rebol on android and iOS since the creator of AGG passed away and it's not been kept up with the newer platforms.
And re:
Here's another alternative. X-Windows. X-Windows has all the low level primitives to build anything. All the GUI libraries for Linux, BSD, etc. are built on X-Windows primitives. I think OpenGl is too, at least on the Unixes. It's a difficult library to work with. Very confusing but it's on most Unix platforms and available for most anything you would need.
I did X Windows application development years ago and though I know there's X Window servers for Mac and Windows I've always (possibly wrongly) thought of it as mostly a unixy thing... esp. are you saying you'd see this as even the answer for iOS and android? The client/server aspect of it seems a mismatch if the goal is app store installable standalone apps. But I'm not an X Windows guru and it's certainly an interesting thought. I think you're saying you'd get a lot of "bang for the buck" putting the Draw dialect stuff on top of it right I do see that point.
(e.g. I'd seen the X Windows in the browser thing you referred to - pretty amazing)
I'm even less familiar with Display PDF/Display Postscript ideas for interactive apps... Though fwiw I did just stumble on a PDF capability with the Skia graphics library (which otherwise supports a lot of platforms - I wonder if this could do what you were thinking?)
