Could someone please clarify the GUI libraries used for Rebol3 and Red for me?
What GUI library does Rebol3,Saphir R3 and Red use? Here's what I think I understand.
Rebol2 VID (a dialect) was built on "View graphics system"
http://www.rebol.com/docs/view-system.html
RebGUI (a dialect) was built on "View graphics system"
R3 Graphical User Interface (GUI) built on "View System"
http://www.rebol.com/r3/docs/view/windows.html
Both "View graphics system" and "View System" are low level graphics librarys. The upper level is VID(older) and R3 GUI newer. The GUI dialect is a series of commands(not sure of the terminology here) to the underlying graphic liberaries.
Questions:
Is R3 Graphical User Interface (GUI) the nomenclature for the new VID?
Does the R3 Graphical User Interface (GUI) provide the same functionality as the older "View graphics system" from R2?
Is Saphir R3 Graphical User Interface (GUI) built on "View System" from R3?
Is Saphir R3 Graphical User Interface (GUI) the same dialect (I actually mean the wording or commands) as R3 GUI?
Is the Saphir R3 coding to the underlying "View System" is a little different to give it a look Saphir likes better?
Is RED going to use the "View System" from R3? I notice they have bindings to GTK+. GTK+ is (gtk+-3.8.0.tar.xz 2013-03-25 23:32 13Mb). That's huge, compared to "View System".
"View System" has a lot of low level commands like vector graphics. Isn't it good enough assuming someone does some work on the translation from the dialect to the "View System" library? Not that it's not good enough now but people always want different. :)
Here's a winger. Can Rebol3 or RED be compiled to run on a 32 bit machine with a 32 bit DOS and still have the graphics GUI? The idea being a newer machine such as a thin client running DOS for stability. Home security being the focus.
I know this is a lot of questions. My apologies. I've looked around for weeks before asking but there doesn't seem to be an answer to my questions in the blunt kind of way I've asked them. Thanks for looking even if you don't answer.
P.S. I have looked at
http://www.rebolforum.com/index.cgi?f=printtopic&topicnumber=49&archiveflag=new
and a great resource it is but didn't find exactly what I'm asking.What GUI library does Rebol3,Saphir R3 and Red use? Here's what I think I understand.
Rebol2 VID (a dialect) was built on "View graphics system"
http://www.rebol.com/docs/view-system.html
RebGUI (a dialect) was built on "View graphics system"
R3 Graphical User Interface (GUI) built on "View System"
http://www.rebol.com/r3/docs/view/windows.html
Both "View graphics system" and "View System" are low level graphics librarys. The upper level is VID(older) and R3 GUI newer. The GUI dialect is a series of commands(not sure of the terminology here) to the underlying graphic liberaries.
Questions:
Is R3 Graphical User Interface (GUI) the nomenclature for the new VID?
Does the R3 Graphical User Interface (GUI) provide the same functionality as the older "View graphics system" from R2?
Is Saphir R3 Graphical User Interface (GUI) built on "View System" from R3?
Is Saphir R3 Graphical User Interface (GUI) the same dialect (I actually mean the wording or commands) as R3 GUI?
Is the Saphir R3 coding to the underlying "View System" is a little different to give it a look Saphir likes better?
Is RED going to use the "View System" from R3? I notice they have bindings to GTK+. GTK+ is (gtk+-3.8.0.tar.xz 2013-03-25 23:32 13Mb). That's huge, compared to "View System".
"View System" has a lot of low level commands like vector graphics. Isn't it good enough assuming someone does some work on the translation from the dialect to the "View System" library? Not that it's not good enough now but people always want different. :)
Here's a winger. Can Rebol3 or RED be compiled to run on a 32 bit machine with a 32 bit DOS and still have the graphics GUI? The idea being a newer machine such as a thin client running DOS for stability. Home security being the focus.
I know this is a lot of questions. My apologies. I've looked around for weeks before asking but there doesn't seem to be an answer to my questions in the blunt kind of way I've asked them. Thanks for looking even if you don't answer.
P.S. I have looked at
http://www.rebolforum.com/index.cgi?f=printtopic&topicnumber=49&archiveflag=new
and a great resource it is but diidn't find exactly what I'm asking.
posted by: Sam 28-Jan-2014/2:10:58-8:00
Hi Sam,
The basic gist of your questions about differences between VID, R3-GUI, RebGUI, and View was answered here:
http://rebolforum.com/index.cgi?f=printtopic&permalink=Patick21-Nov-2013/17:51:10-8:00&archiveflag=new
Basically, View is the low level graphic compositing engine in Rebol.
VID is the high level GUI dialect built into R2. In it, the 'layout function is used to parse simple dialect code for buttons, fields, and other widget 'styles', into more complex low level code which is displayed by the View engine. Features of the VID dialect are covered throughout the tutorial at http://business-programming.com
You can skin VID easily using 'stylize. In the early years, there was a complete Windows 98 skin which made it look just like native Windows. Most Rebolers don't seem to care too much about doing that these days, but it's relatively simple to build a modern looking design, even with R2 VID, if anyone wanted to put in the effort.
RebGUI is a third party GUI dialect for R2 by Ashley Truter, similar to VID dialect, but with some additional features (undo/redo, spell check, table widget, resizing and other layout options, etc.). RebGUI covered in some depth at http://business-programming.com/business_programming.html#section-17.22 Saphirion created a port of RebGUI (also for R2) which they've edited to include features, fixes, and stylistic design improvements which they've decided are important: http://development.saphirion.com/rebol/rebgui/ . Anyone could make their own improvements to RebGUI - like VID, it's just a pure Rebol dialect which is converted to low level View code.
R3 (version 3 of Rebol) was released as an open source project. R3-GUI is essentially a new version of VID for R3. Carl Sassenrath (the creator of Rebol) was working on performance improvements in R3, R3 View, and R3-GUI, but abandoned those projects before they were mature, then opened sourced the project so others could continue working with it. Saphirion, a group made up some of the old Rebol gurus, continued work on the R3, R3 View, and R3-GUI projects, and has released their own versions for the main OS platforms, including a port for Android. Some of the basic differences between R2 VID and R3-GUI dialect are described at http://business-programming.com/business_programming.html#section-18 and in more depth at htt[://learnrebol.com (after that you can continue with the links at http://www.rebolforum.com/index.cgi?f=printtopic&topicnumber=49&archiveflag=new to learn more in depth about R3-GUI). Whether or not you know R2 VID, you should be able to create basic GUI layouts with R3-GUI in a day - the differences, on the dialect surface, are trivial. The underlying engines, however, has been improved.
So, to answer your questions directly,
- Is R3 Graphical User Interface (GUI) the nomenclature for the new VID?
Yes "R3-GUI" is the new "VID" for R3, mostly being developed by Saphirion now.
- Does the R3 Graphical User Interface (GUI) provide the same functionality as the older "View graphics system" from R2?
Not exactly. There's still a separate View engine, with a GUI dialect built on top. The R3 rendering engine is redesigned with "Gob"s, and Saphirion chose to eliminate the requirement for a separate GUI 'layout function, so the 'view function determines if it's rendering a Gob or if it needs to parse GUI layout dialect code. Things are also organized a bit differently, with code found in different objects, but the high level GUI dialect is still very similar, and build on a lower level compositing engine.
- Is Saphir R3 Graphical User Interface (GUI) built on "View System" from R3?
Yes
- Is Saphir R3 Graphical User Interface (GUI) the same dialect (I actually mean the wording or commands) as R3 GUI?
Saphir R3 GUI is just a completion of the R3-GUI which Carl created. Saphirion changed some things (removed 'reactors'), but most of the docs on rebol.com, about R3-GUI are still basically valid. When in doubt, study Saphirion's docs (or the code and built-in help in Saphirion R3), when dealing with Saphirion R3.
- Is the Saphir R3 coding to the underlying "View System" is a little different to give it a look Saphir likes better?
'look' is based on the whatever is done with code used to display graphical element. So, the differences in the look of R3-GUI are mostly due to changes in R3-GUI code. You could skin your own version of R3-GUI to look however you want, or create something like RebGUI for R3 to look entirely differently, based on your design preferences. Because Rebol is really designed for productivity, I think many developers just take what they get as far a looks, and focus on building applications which work, however they look. The Rebol community could sure use a few good new graphic designers...
- Is RED going to use the "View System" from R3? I notice they have bindings to GTK+. GTK+ is (gtk+-3.8.0.tar.xz 2013-03-25 23:32 13Mb). That's huge, compared to "View System".
Kaj has created lots of bindings to Red/system already, mostly to provide immediate solutions for his own work, but the goal for Doc Nenad) is to create a fully self contained system with no external dependencies. He's stated that he intends for the first GUI dialects to be based on native GUI APIs, so that they look native on each OS. The dialect will stay the same across platforms. Later, he expects that he'll create an engine similar to VID, which builds GUI elements from low level graphic components (as is done in VID and R3-GUI), so that it can be easily ported to new platforms, without any native GUI API requirements. Again, the same high level GUI dialect would be used by Red developers to create GUI layouts, whatever low level design is used to implements buttons, fields, etc.,
- "View System" has a lot of low level commands like vector graphics. Isn't it good enough assuming someone does some work on the translation from the dialect to the "View System" library? Not that it's not good enough now but people always want different. :)
Some of the main improvements in R3 had to do with performance, to help improve 'programming in the large' capabilities. Thousands of graphic objects can be manipulated quickly in R3, with greater speed, less use of memory, etc.
- Can Rebol3 or RED be compiled to run on a 32 bit machine with a 32 bit DOS and still have the graphics GUI?
There are no Rebol releases currently compiled for DOS, but you can find old releases for some uncommon platforms at http://rebol.com/platforms-core.html and http://rebol.com/platforms-view.html . One of the really cool things about Rebol is that it's been compiled for 40+ platforms, and appears to be relatively easy to port. I'd talk with the guys at Saphirion, expecially Cyphre and perhaps Robert, if you're interested in a port to a specific platform. So far, they seem to respond well with productive work if you're willing to pay them to complete specific tasks. You can reach those guys directly with private messages on AltMe.
Right now, I still suggest learning Rebol with R2 because it's more mature - there's a lot of code available (rebol.org, tutorials, etc.), the tooling is much more complete, and all the main desktop OSs are supported.
If you need or want to participate in the open source project, or if you want support for Android and other potential new platforms, explore R3. I cover some of the current R3 'ecosystem' limitations in the tutorial at http://learnrebol.com . Saphirion and Atronix have working on versions for 64 bit Linux and Mac (not yet released), and they're considering building a port which will run entirely in Javascript, via Emscripten - i.e., so that you'll be able to run complete R3 programs, includeing GUI code, directly in any browser (including mobile), without a plugin, etc. I'm really hoping to see that get completed :)
Red is a totally separate project by Nenad Rakocevic. He is building a 'full-stack' language which can be interpreted like Rebol, but which as meant to be compiled directly to machine code, so it will perform FAST - iin the same ballpark as C. The idea is to provide a high level language based nearly exactly on Rebol semantics, so that it is ridiculously productive like Rebol, at the app development level, but also with all the low level capabilities needed to create device drivers and other pieces of 'close to the metal' software which require performance and low level control - all without any C or any of the traditional insanely messy and complex tool chain used to build modern software.
Nenad has just announced a short teaser demonstrating that the first Android GUI engine for Red is being built, with code that looks a lot like R2 VID, but that hasn't been released yet (alpha is expected in the next release of Red). Nenad plans to support every platform, including low level, high level OS features, web development, etc. He is brilliant, and working reliably on Red. Expect Red to hit prime time some time this year.
posted by: Nick 28-Jan-2014/9:40:48-8:00
WOW, Nick that was a very detailed statement. TY I enjoyed reading it....sounds like "Red" is going to be a very productive and full featured language. Just one questions, do you think we will be able to run rebol code in red, somewhere down the line?
posted by: ron 28-Jan-2014/11:29:05-8:00
Thank you very much Nick. I swear I read all the forum posts but somehow missed, ( or even worse read it and forgot), the one you quoted at first. (Hangs head in shame) I appreciate your forbearance. Your answers to my questions was not only complete but gallant. You even intuited questions I would have asked had I known better. You're very patient. I appreciate it and will try not to abuse your patience.
I also would like to thank you for your tutorials. A lot of work went into these and they are a treasure.
posted by: Sam 28-Jan-2014/16:53:44-8:00
A further refinement of info on R3 graphics. It took me a long time to find this. I finally found it searching "render" and "Gob" together. The R3 graphics are; from:
http://www.rebol.net/wiki/Custom_Gobs
"...A quick note about the R3 rendering pipeline
The R3 view has basically 3 levels of graphic management, only one which is directly accessible from within the interpreter.
Gob! - The purely Rebol Hi-level interface which is like a handle to the internals.
Compositor - Although not a clear-cut layer in and of itself, it really does act as middle layer in the view system. It reads the gob information tree and manages what is rendered and how to layer them, eventually forking off to lower-level AGG routines.
AGG - Anti Grain Geometry engine - is the low-level view processing workhorse. Its a relatively fast and flexible CPU-based 2D vectorial rendering engine..."
Why was I looking at this? I wondered why RED wasn't using the same graphics as Rebol. Then I found that Rebol used the AGG library. The AGG library is really amazing. I could see how turning this immense contortionist library into an interface could be reeaaalllyyy tricky. If you haven't download the library. It has little example programs that run each section of its library. So the answer is, there is no reason RED can't use R3 graphics. I'm not sure why he's not. I wonder if building bindings to these massive libraries on Windows, Apple, Linux would not be more trouble than finding how to tweak the AGG library to display the same interface as the different operating systems. Not to mention they're a moving target and even worse if you have to program them you have to use their programming interface. To program them to use a VID type dialect would be monumental. The only advantages I can see are people are used to doing things this way and the graphics for the operating system are likely to be accelerated in the video card.
Here's an obscene idea. Use the R3, AGG and gobs but re-write it such that it has a binding to OpenGL if that command is available. OpenGL is accelerated on I believe all graphics cards. Don't use OpenGL just the commands as a kind of fast processor.
posted by: Sam 3-Feb-2014/4:53:59-8:00
I read,
http://www.rebol.net/wiki/Custom_Gobs
and didn't quite grasp what he was saying but actually he's saying something similar to what I was saying. He says,"...Custom Gobs
This is a proposal based on tests and a prototype in development which allows external graphic rendering engines to integrate directly within R3 view system..."
OpenGL could be one of the graphics engines used. It would be helpful because of the ubiquitous support of most graphic cards,or at least I believe they support it. It would be wonderful to have AGG - Anti Grain Geometry engine at all times but if possible speed it up with calls to OpenGL. Have to think some more about this.
posted by: Sam 3-Feb-2014/5:22:51-8:00
Doc has said that there will eventually be a number of different graphics and GUI engines implemented in Red, and Cyphre has suggested this plan to port R3 to Javascript:
1. compile r3/saphir core to JS (Andreas did some experiments but this needs to be completed enough so we can proceed with gfx porting)
2. Develop new graphics compositor module based on WebGL. (This part will handle the gob! objects on screen etc.)
3. Port DRAW dialect.(to be able render 2d graphics) Two options are here:
3a. Start with current AGG rendering backend. If that is possible we can reduce developement time with this approach)
3b. Write new graphics DRAW backend module based on HTML5 Canvas (more work in the beginning but possible higher performance than AGG renderer converted to JS)
4. fine tune the graphics port to be able run R3GUI without any big issues
As you can see the browser specific parts would need some prototyping/experiments so I can give you only my personal rough estimate which is around 2-3 months to the point R3GUI will run in the browser.
So, I think there are many options available. Right now there are just a few people involved in doing that sort of work for either R3 or Red (Doc and Cyphre). Hopefully with some initial success by Doc releasing useful Red tools this year, and some more platform releases of R3 by Cyphre (browser based R3GUI especially), I think the community may grow a bit to see more people involved. I do my best to try to help people who are interested, but like everyone else, my time is limited :(
posted by: Nick 3-Feb-2014/8:17:54-8:00
Thanks for your help. I don't expect an answer but I may post a few ideas here. I don't want to wear out my welcome. I do look around a lot before asking questions but sometimes I miss things.
WebGL sounds nice but it,"...It uses the HTML5 canvas element and is accessed using Document Object Model interfaces...". Canvas does some miraculous things. I saw a demo,
http://net.tutsplus.com/articles/web-roundups/21-ridiculously-impressive-html5-canvas-experiments/
Some of the interface elements look good. Also people are going to use it for games. I'm not interested in games though. Document Object Model interfaces. No thanks. More bindings for huge libraries. Canvas does have problems. If the page changes you have to redraw all of it. There's another standard on most browsers and also phones and other android type devices called Scalable Vector Graphics (SVG) Tiny.
http://www.w3.org/TR/SVGTiny12/single-page.html#intro-defining
It might be good as a small "fit anywhere" type target for browsers. It's an older standard. I've been trying to figure out how to attach to XMLHttpRequest which seems to be the way that Ajax is carried out. I know people do similar things on Rebol but haven't found the key yet. Where I'm stuck is how does the Rebol interpreter "find" the address of XMLHttpRequest? How would it read and write to it? It's amazing that most people who want to do this have to download some huge framework to do so. I know you can make a server then use it on your machine to talk to your browser but that seems a little complicated. The basic idea being send xml to XMLHttpRequest. The xml would have TinySVG in it. TinySVG would be the interface displayed in your page. TinySVG also has a call back mechanism for button presses. In canvas if you move anything you have to keep up with where the buttons are. You only get a X,Y bitmap location. Be tough to keep up with and would cause a lot of bugs I think.
Anyways the subject interest me.
posted by: Sam 4-Feb-2014/0:34:55-8:00
I've been looking around some more. Here's , so far, what seems to be the smallest most convenient library to tie the graphics of R3 and Red to the platform AND have accelerated graphics thru using OpenGL.
"...SDL
Simple DirectMedia Layer is a cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D...SDL officially supports Windows, Mac OS X, Linux, iOS, and Android. Support for other platforms may be found in the source code..."
I looked at the size and it's about 880KB for the Windows binary dll which is not too big.
One reason I don't like WebGL is you're going to have to activate javascript on your browser to use it or I believe so. I use something called noscript to shut off scripts on my Firefox browser and I can't get any online WebGL pages to display unless I allow that page. I'm assuming, and yes I know what this means, that WebGL works thru XMLHttpRequest. Also you're going, to the best of my knowledge (small though it be), to have to make a server on your on computer to talk to the browser to display your program. That may be fine but it seems perverse to me.
AGG is a killer library but it doesn't have hardware acceleration. Anyways I just found this by looking at hoards of web pages and maybe it will help others more knowledgeable save a little time.
posted by: Sam 20-Feb-2014/4:02:09-8:00
Sam,
I think up until this point, since there's already a lot of existing code tied up with AGG, it's been the obvious choice, but Cyphre said on Monday: "I plan to test other backends(and others are welcome to do it as well) as it is now much easier to switch between them."
With the release of Atronix's versions for 32 and 64 bit Linux and Windows, it's clear that Shixin is also deep into working on graphics ports. With the release of more R3 ports, and also GUI and graphics in Red, I hope more guys like that will join (and perhaps re-join) the community.
There have been a number of discussions about using something other than AGG, and it's encouraging to hear that Cyphre is not only considering other back ends, but only considers that the work up until this point is making that goal easier to achieve.
The intent of working with WebGL is not to build desktop apps, but web applications, including graphics and GUI, using pure Rebol, which run directly in the browser. To me, this is one of the most exciting possibilities for the near future. This would allow us to build complete web software, including not only server (as we can now with CGI, and frameworks like QuarterMaster), but also client front ends, using basically nothing but Rebol, GUI dialects and all (no Javascript, no CSS (!!!), etc.). Since web is currently winning as the default cross platform choice which runs on every modern device (in a browser), it would be incredibly helpful for the popularity of Rebol if we could play in that arena. It would be a real, modern draw for others to become involved with improving Rebol, not to mention, I would love to be able to build web pages directly with R3-GUI :)
posted by: Nick 20-Feb-2014/13:51:56-8:00
Thanks for your reply. I think maybe Kaj de Vos has already done what I was asking. He has bindings for SDL here, :)
http://red.esperconsultancy.nl/Red-SDL/artifact/c794f67660c943c24a13fc7fe2a79051812a64f3
I didn't see this earlier. You have to look at the bindings files to see it. I found it poking around in them.
I'm assuming that's how he's getting OpenGL to work. Thru SDL which seems an excellent idea to me. SDL covers all major platforms.
"...Since web is currently winning as the default cross platform choice which runs on every modern device (in a browser), it would be incredibly helpful for the popularity of Rebol..."
I think you're exactly correct. If I understand correctly someone would have to interpret Rebol GUI commands to XML/WebGL commands that the browser would display. That would be difficult/time consuming. But most any system will have a web browser these days and will probably use a limited amount of processors in the future. What I mean by limited amount of processors is any one computer company that strays too far from present processors will probably be less likely to have any software to run on it. I believe they will consolidate. Anything new can be covered with red and as long as it has a browser you can write to it.
If Rebel ever gets this all together it's going to put an axe to the heads of all these huge framework companies. It seems to me they are just making it a little easier to write WebGL and other browser built in graphics functions using AJAX. They are still a huge contortion to use. One thing I really like about Rebol is you can start with a very basic GUI to get things started then add elements as you go. A natural way to do anything not just programming.
Having AGG as a back up might be nice. In comparison to most software today it takes up zero room.
posted by: Sam 21-Feb-2014/1:23:40-8:00
|