Home   Archive   Permalink



Red/View reference documentation

Doc has posted this new reference for Red/View:
    
https://github.com/red/red/wiki/Red-View-Graphic-System

posted by:   Nick       14-Jan-2016/10:17:04-8:00



Is RED's GUI, presently, really Rebol's or is it new? I'm assuming it's Rebols and he's calling the Rebol GUI. If so I really don't all together understand what his plans are for the GUI.
    
At one time it was to use each OSes GUI which I thought was the worst idea ever. I talked to him about various other libraries and just pissed Doc off. I think he misunderstood me. My goal certainly wasn't to annoy him. I just want at least one GUI library that can be modded like the AGG so that there will always be a default GUI that can be used. It could be styled for each OS if necessary. Maybe he's come around to that.

posted by:   Sam       12-Feb-2016/21:37:31-8:00



It's important to separate the idea of the GUI dialect and rendering engine. The same dialect will eventually be supported by a number of different rendering engines, but the first implementation is using native OS graphics and GUI components. This is a bit more work for Doc to implement on each OS, but it's fast and native looking on every platform, which is a very good thing.
    
There is no single GUI/graphics library which supports every platform which Doc wants Red to target, or which provides all the features needed for all of the low level
Draw capabilities, "View" features (event handling, etc.), and high level GUI features. Support for more rendering systems such as AGG, Cairo, etc. can be added later, without changing any of the Red code which users can tweak as needed.
    
Bindings of "GUI libraries" require less work to implement than what Doc is doing. Kaj did that early on with GTK+. He even created a high level VID-like dialect to control it (Kaj's GTK+ binding is available on the contributions page: http://www.red-lang.org/p/contributions.html ). But to use that implementatino, like with any other language binding of GTK+, you need to have users install the entire (large) GTK+ library. Doc's system is much> lighter weight, and will enable many more features in a Red-native system which doesn't require any other dependencies.
    
For the user of the dialects built upon each renderer, it doesn't matter what the back end is. The dialects abstract away everything above the low level rendering, so drawing, styling, managing events, high level GUI widget capabilities, etc. all use the exact same Red code on every platform, regardless of rendering subsystem. Only the people who implement the renderer ever need to touch the code which interacts with that lowest level.

posted by:   Nick       13-Feb-2016/9:43:35-8:00



Thanks.

posted by:   Sam       19-Feb-2016/18:09:02-8:00



"Is RED's GUI, presently, really Rebol's or is it new? I'm assuming it's Rebols and he's calling the Rebol GUI."
    
Why making such assumption? It is a new implementation from scratch, entirely coded in Red (and Red/System for low-level parts). Also, as Nick points out, separation needs to be done between the high-level interfaces (VID and Draw dialects), the rendering engine (View and the face object abstraction), and the backends. Red made a VID, Draw and face implementations which are very close to Rebol2's ones (with some improvements, like reactive programming support), but the low-level parts are totally different (using the OS API only).
    
"At one time it was to use each OSes GUI which I thought was the worst idea ever. I talked to him about various other libraries and just pissed Doc off. I think he misunderstood me."
    
Sorry if I sounded "harsh" on my reply. I understand better your point now, though I still disagree. ;-)
    
"I just want at least one GUI library that can be modded like the AGG so that there will always be a default GUI that can be used."
    
AGG is not a GUI library, but a 2D vector-drawing library. It gives you _no_ GUI components, nor handles any event. The goal in Red, is to use what the OS provides as much as possible, in order to avoid: a) bloated Red binary, b) restrictions caused by third-party GUI library choices (including library not been maintained or upgraded anymore, like AGG is), c) poor integration with OS native features. There are a few interesting GUI cross-platform libraries around, none of them satisfies our current and future needs.
    
Hope this helps understand Red/View better. Though, we'll provide many examples in the next week which will make my points more obvious to everyone. ;-)
--
Nenad

posted by:   DocKimbel       24-Mar-2016/2:07:50-7:00



Actually I understand about the difference between the GUI and the underlying drawing engine, like AGG. My understanding of (View and the face object abstraction)is more limited. I'm just severely retarded in using the correct nomenclature.
    
Sam,"...I'm assuming it's Rebols and he's calling the Rebol GUI."
        
Doc,"...Why making such assumption?..."
    
Because at the time Rebol2 was needed in conjunction with RED to operate and it just seemed easier to me. I never dreamed that you had done so much work, so fast, as to have tied in the OS graphics library with RED already. Incredibly quick work and quite astounding. Like when the there's a puff of smoke and a magician presents an elephant. You just naturally assume it's a trick. Yet in this case it wasn't a trick. Maybe you took this as a critique. Wasn't meant that way and ended up in being my astonishment at your speed in whipping this thing up.
    
    
When I say"..."I just want at least one GUI library that can be modded like the AGG..."
    
I mean one underlying graphics drawing library at the "root". Like AGG. I understand that all the upper levels are built on RED. The AGG or whatever library, I don't care what, could be skinned to replicate whatever OS is used. The only reason I keep saying AGG is it's impressive what AGG does in such a small program. Really the whole idea is a fall back provision. I understand DocKimbel's position to do it right. I agree that he's doing the right thing. It would seem much more difficult and risky. Maybe that's my lesser imagination for grand schemes than Doc. My only only fear is his point, "b) restrictions caused by third-party GUI library choices (including library not been maintained or upgraded anymore, like AGG is..."
    
I'm afraid this will happen to RED but if you have one low level graphics library NOT tied to the OS it could be more easily ported and usable anywhere for all time on any RED compatible platform. AGG is C++ so you know any platform for our lifetimes will probably have a C++ compiler. As mentioned most of the upper levels will be exactly the same.
    
I'll bet in two years time Doc will so sick of RED he will not want to see the thing for a few years. Not anything bad about this. It's not saying anything derogative about Doc. Just human nature. Just the way things are. He's doing some of the greatest work ever in software history but after doing that he's going to get sick of patching little drips from the leaking roof,(GUI changes in the various OS's RED supports), as time goes on. If there's no backup to tying the graphics library to the OS graphics library then bad things could happen. The whole edifice could succumb to bit rot.
    
All in all the real point is I don't have the skills he does, he's doing it his way (as it should be) but it doesn't take anything away from him for me to advance a small idea. Notice I'll shut up about it. I don't wish to beat a dead horse.
    
Thanks to Doc and Nick for all your great work and responding to my very less than knowledgeable brain farts.

posted by:   Sam       16-Apr-2016/0:05:45-7:00