Home   Archive   Permalink

The Usefulness of RebGUI

The VID GUI dialect built into Rebol is one of it's most appealing and useful ideas, and perhaps the most immediately obvious example of the power of dialects. But VID was only a quick creation which Carl came up with, as an example of how a GUI dialect may be created. There are several others already implemented for R2. I've used RebGUI, by Ashley Truter, for a number of medium size projects, and for most business apps, I think it tends to be more practical than Rebol's native VID. If you know a little about VID, you should be able to pick up RebGUI in a single sitting. There's an intro to it here:
If you haven't tried it yet, it's worth the time.

posted by:   Nick       8-Mar-2014/10:22:41-8:00

This is what I don't get about dialects. I myself, of limited experience in such matters, would not say that VID is "an example of how a GUI dialect may be created," I would say it is an example of what a GUI dialect might look like. The information about how, exactly, it is created is not clear. One still has to translate those VID keywords into stuff on a screen. Is that done with C? Are there undocumented functions outside of VID to do that? It is a great mystery to me.

posted by:   Steven White       10-Mar-2014/10:13:35-7:00

Take a look at the output returned by the 'layout function:
editor layout [button [print "hello"]]
That produces 12818 lines of readable Rebol code, all contained in an OBJECT structure. In the example above, search for where the 'print "hello" code is found. Now try adjusting the example layout code, and search for the code changes you make. Any changes you make to the VID dialect input to the 'layout function will be clearly represented in the 'layout function object output. The output of the layout function is all Rebol code (an object definition containing word labels set to values, function definitions, data structures, etc.).
Now look at the source of the 'layout function, which generates the 12818 lines of Rebol object code above:
editor mold :layout
That function is 143 lines of pure Rebol code (parse rules, a while loop, etc.). Notice that it's input argument is a block! VID dialect code ("Dialect block of styles, attributes, and layouts").
Now look at the source of the 'view function:
editor mold :view
That function is 33 lines of pure Rebol code. Notice that it takes an OBJECT parameter. So when you evaluate:
view layout [<some VID dialect code>]
The 'layout function parses the VID dialect code and returns an OBJECT. The 'view function accepts that OBJECT as an input argument (and handles some optional refinements). At the end of the view function, the 'show function is evaluated, with the 'scr-face ojbect as it input argument.
Now look at the 'show function source:
show: native [
     "Display a face or block of faces."
     face [object! block!]
That's portable C code which does that drawing on screen. If you want, you can explore the C code in the R3 sources (different from R2).
Does that help clear up the basic process?

posted by:   Nick       11-Mar-2014/22:48:15-7:00

You can trace the way RebGUI works, all the way back from the 'display function. Notice that RebGUI makes use of a new 'ctx-gui object:
editor mold :ctx-rebgui
So, for example, instead of using the widget definitions in system/view/vid/vid-styles , RebGUI makes use of the new definitions in ctx-rebgui/widgets. Notice that there's also a /view* object. You'll see these new object definitions clearly made use of in RebGUI's main 'display function.
So the dialect and object definitions in RebGUI are different than in VID (they're similar, but hopefully improved, for the purposes which RebGUI was designed), but the rendering of the graphics is stilled handled by the underlying C code in the 'show function. That low level code doesn't need to be changed at all, in order for the look and the dialect of RebGUI to be as different as desired, from VID.

posted by:   Nick       11-Mar-2014/23:25:07-7:00

Addition to the Nick's great explanations;
Here is a quick explanation;
VID (dialect) --> LAYOUT (a function to create an object) --> VIEW (function to show the object) --> FACE (REBOL/View Graphic System Reference, handles all the events and low levels) --> AGG (lower level C code)
I advice you to read about FACEs: http://www.rebol.com/docs/view-system.html
And http://www.antigrain.com/ if you like.

posted by:   Endo       12-Mar-2014/8:12:42-7:00

Now THERE'S a script that cries out for annotation (just kidding). Thank you, that cleared things up quite a bit. I'm not going to run out and make a dialect tomorrow, but I do believe I see how I might get started. That Carl is quite the genius. It will take me a little time to digest all this.

posted by:   Steven White       12-Mar-2014/9:17:50-7:00

Steve, you can say that VID consists of a function, LAYOUT, that churns out face trees. Each face is a completely regular object, that when passed to the View engine (C-based) via the VIEW function, is processed and displayed as a graphical object, representing a region in the face.
When you have a tree of them, you can make a sophisticated layout of layered regions. When you assign input events and event handlers to each region, they can work as a functional GUI.
You can do all this manually, build faces, events, etc., but LAYOUT does this automatically and rather quickly.
LAYOUT has its downsides, such as lack of easy resizing, because it doesn't build the necessary event handlers for that.
This is solved with RebGUI. I also made my own VID Extension Kit some time ago, which solves this, available here: http://hmkdesign.dk/project.rsp?id=vid-ext-kit&page=info but, it's no longer maintained.

posted by:   Henrik       15-Mar-2014/6:30:09-7:00

A simple solution for resizing only, which works in pure VID is also available at http://www.rebol.it/romano/resize-vid.zip .
There many other additions to R2 VID, such as Henrik's listview (thank you!), and Cyphre's tab panel and menu modules, which are more powerful than those in RebGUI. RebGUI just provides a simple nice, mature, all-inclusive, production ready set of the most common tools needed to build typical GUIs, powerful enough to handle most 'normal' situations, with lots of practical additional features that can be a hassle to implement manually in VID.

posted by:   Nick       18-Mar-2014/2:25:35-7:00

I have downloaded list-view.r and added it to our small office collection of reusable REBOL code, and used it in one small application. I can't remember where I used it, which is sort of pathetic, but I do remember using it because I remember being so grateful for its existence because it solved a problem for me.

posted by:   Steven White       18-Mar-2014/9:47:01-7:00

Steven, I'm really glad you liked it! :-) I would like to get back to GUI work, if I get time in the future.

posted by:   Henrik       18-Mar-2014/14:46:03-7:00

Hi Nick,
I had the same thing about the creation VID. It was quickly put together by Carl and it returns its source of 12000+ pages. "easy to read" you add. Yes technically easy to read, but still a lot and mostly generated lines (that is how you create a lot of lines quickly) so very little varying info within a lot of similar looking lines. VID is a good example of a dialect but I certainly do not get how the info of the faces is translated to the screen itself, I think that is compiled into the view exe for the platform itself using some kind of GTK or native toolkit. This could also explain why it is so hard for Saphirion and Atronix to get the Windows version of their GUI version from Windows to Linux and beyond to MacOSX (Still not here). Also having a built in VID makes it easier to start adopting Rebol, a feature many other languages lack. Having to download a separate GUI and choosing from more options is always more troublesome, lucky this is Rebol and things tend to stay within one such dependency.

posted by:   Arnold       20-Mar-2014/18:52:52-7:00

Hi Arnold,
The "some kind of GTK or native toolkit" is AGG, which Endo pointed out is at http://www.antigrain.com/ . AGG is the C++ engine that R2, and currently desktop R3 (but NOT Android R3), use to render graphics. In R3, that engine can be replaced with other rendering engines such as Cairo, WebGL, etc. The rendering engine is purely a graphic compositor. It handles things like rotating and scaling pixel images, shading polygons, converting fonts into polygonal figures, applying perspective and bilinear transformations to images, applying transparencies, anti-aliasing lines and curves, etc.
The whole point of dialecting is that you never NEED to get anywhere near that sort of code. Now, if you want to work on developing Rebol itself, then you need to dive into that stuff, and it's necessarily complex. That complexity is not the fault of Rebol. There's a lot going on under the hood which Rebol eases for us. The fact that creating a button requires drawing a square image with beveled edges, by painting pixels onto a monitor device, and interfacing with the event system of the OS to capture mouse click events and respond in some useful way, well that's just an inherently complex undertaking. The fact that VID puts out thousands of lines of View code to handle all the potential necessities of dealing with GUI mechanics - not just the graphic drawing, but also the handling of events, and the higher level scope of development possibilities encompassed by UI design and implementation - that's just a result of that inherent complexity. The fact that Carl was able to conceive not only a language design, but also a fully working technical implementation, which allowed developers to write 'btn "click me" ["hello world"]', is fantastic. And well beyond that, he created an entire environment and toolkit which enables developers to reduce any other potentially inherently complex problems, so that they can be managed by language constructs which are similarly simple. The design of such language constructs, the features they implements, etc., are all choices made be those who create new dialects. RebGUI is one such example of alternate language and design choices, related to GUI implementation. Rebol's design made it possible for Ashley to create such an alternative, without ever having to even touch AGG (in R2, that level was closed source). Now that we have R3, guys like Cyphre and Shixen are able to dive down to that lowest level, and change out things like AGG, which is exactly what Cyphre did in the port to Android. The fact that it's taking a while is a result of the situation that there's only one or two guys actually working on these complex undertakings. The fact that Cyphre got the Android port out in a couple months was absolutely amazing. It's always been my interest to see the community grow (again) in the future, so that there are more people putting out Rebol tools like this for everyone to use.

posted by:   Nick       22-Mar-2014/5:07:29-7:00

It's important to point out, that because Cyphre was able to port R3 to a platform which is foreign from any of the R2 platforms, including switching to a foreign graphics rendering engine, he's made critical advances. My interest right now is convincing him and Robert to apply their limited resources (Cyphre's time) to porting R3 and R3-GUI to Javascript (using Emscripten), and whatever graphics rendering backend is practical in the browser, so that we call develop HTML5 apps entirely with R3 and R3-GUI. That would enable us to build web pages (not just server output but the full rich client experience), entirely using R3. More important, it would allow us to deploy R3 applications to ANY platform which supports HTML5 (HTML5 has become the standard for cross-platform deployment during the past few years). This would not only improve the situation for current users, it would likely draw the interest of a larger community - which again, tends to provide a richer ecosystem of tools which Rebolers can choose from. If someone like Ashley wants to create, for example, a version of RebGUI for R3, then it will run across all the supported platforms and graphic backends, because that level of the design is abstracted away by Rebol's lower level graphic layers. That's the beauty of the whole system.

posted by:   Nick       22-Mar-2014/5:31:14-7:00