REBOL 3.0 GUI Path
Ok, here's an important note...
The graphics system of REBOL 3.0 is more powerful and leaner than prior REBOL versions. It will be fantastic for creating GUI's, presentations, applications, games, and demos. It should be possible to create hundreds of graphics objects, but without the same memory overhead required in prior versions.
Now, in order to make the upper layers of the GUI (e.g. VID) faster and leaner, those layers must be reimplemented using new methods.
Fortunately, there's not a lot of code invovled here, so the process should not take too long. However, it is not a small job either, and the project must begin fairly soon.
We will need to take this opportunity to improve the built-in GUI system. Here are the areas of improvement:
| ||Styles||We need a solid set of standard "widgets" (to use the non-REBOL term that everyone understands). Buttons, lists, fields, areas, and other sytles must be at least as functional as those found in any web browser. E.g. we must support undo in fields and areas.
| ||Look||We will want to modernize the look of the standard styles to make REBOL GUI's look on par or better than apps done in frameworks (e.g. like konfabulator apps look good). I think a lot of this should be possible using the built in DRAW (AGG) functions, eliminating the need to embed images in the binary.
| ||Dialect||The GUI dialect was implemented long ago. Since then, we've developed a number of techniques for better implementing dialects. These methods will be used in the new GUI.
| ||Skins||Some degree of skinning should be supported. (But, we don't want to get too crazy here, as it can inflate the code and delay the release).
| ||Optimize||The GUI needs to be fast and not hog memory. The code should also be small and optimal to not inflate the size of REBOL.
| ||Special||We will want to be sure to support some of the special features found in modern GUIs, such hover-help, etc.
I've not yet decided how the GUI will be created. The most likely path is to rebuild along the lines of something that already exists.
I am not opposed to using a GUI system design that has been done outside of RT (e.g. REBGUI?), as long it can meet the above requirements and the licensing is suitable.
I would like to assemble a small team for this project, probably three or four people in total (including myself). And, it is critical that all of us share the same design goals and optimal coding practices.
The project would begin just as soon as we have the lower layers of the REBOL 3.0 graphics system up and running. (Later in May, I hope!) It is likely that we would begin before the event system is finalized, but that should not slow things down.
Your thoughts and comments are appreciated.