Comments on: Simple, Clean VID Requirements

Carl Sassenrath, CTO
REBOL Technologies
6-May-2008 16:48 GMT

Article #0132
Main page || Index || Prior Article [0131] || Next Article [0133] || 30 Comments || Send feedback

Over the years, I've written a lot about VID, the REBOL Visual Interface Dialect. VID is important because it is how we create GUI's in REBOL.

We are now ready to complete VID3 for R3.

We want to be sure we get it right. How do we measure "right"? Well, we each have different requirements, but in general, we should all be happy with it. And, I need to be happy with it too, which is critical.

My VID requirements can be boiled down to just a few lines, not even one page. Of course, we want all the normal features like speed and reliability, but here are the requirements I think are essential:



Easy to build a "page"

We know how HTML pages are built. Simple ones are fairly easy. I want VID to be even easier, and it can be. It is not difficult, and only in this way can we get a lot of people, even non-programmers to build VID pages.

All the basic GUI elements

We need all the basic GUI elements as a standard part of VID. What elements do I mean? Well, we need at least the HTML basic widgets/gadgets. I want to be able to create a selection text list or a table with just a few words - and, nothing complicated about it. (Of course, we will add a lot more than just the basic HTML widgets, since most apps need more than that.)

Smart defaults and options

We want VID to make smart choices for the common patterns. We know what these patterns are. VID2 taught us that. So has the web. If we are forced to specify the same argument or attribute multiple times, then we have failed this requirement. I would also include the need for smart options. If I want to limit a text field to just numeric entry, it should only require a special option word, not code. We can build a lot of GUI's quickly this way.

Not difficult to extend

We do not want VID to be difficult to modify or add new styles, new looks, and new behaviors. Any user should be able to change the look of something just as easily (and maybe easier) than they would change a CSS (style sheet) in HTML. If an "average scripter" cannot understand how to do this, then we failed our design.

Easy application interface

The GUI is just the front end of an application. It must be attached to application code that does something useful (what is often called the "model"). This "attachment" needs to be fairly simple and clear in VID. There are different methods depending on the type of application. In a quick script, I may want to place code in the GUI itself. For larger apps, I may want to keep the GUI well-isolated from any app code.

So those are the requirements that we will use to evaluate our VID 3 design. If I've missed any critical ones (we know there are many less critical ones), please let me know, and if I agree, I will add it to the above list.

Detailed discussion of this topic is in the R3-Alpha AltME world. Or, post your comments here.



Brian Tiffin
6-May-2008 13:05
Menu. R2 VID really missed out on the M of WIMP. Lack of a menu bar (imho) makes REBOL 2 gui apps look and feel far less professional than they deserve.
6-May-2008 13:12:22
I think a nice options would be to float a plane similiar in fashion as to how CSS uses 'float. This could be useful for such things as resizing GUI windows. I say this not knowing anything really about the new VID.
6-May-2008 15:10:24
I'm voting for grid, a lot of usefull applications makes its output in some form of matrix, floating columns/areas would be an eye catching feature
7-May-2008 4:49
Some comments : 1) VID3 has to offer more than just HTML widgets. HTML widgets are not sufficient for some kind of data manipulation and that's why many technologies (Javascript, AJAX, Flash/Flex,...) propose more widgets. Some proposals:
  • Numeric stepper
  • date chooser
  • color chooser
  • hierarchical menu
  • list with key-label pairs
  • drop down list with key-label pairs
  • tree
  • grid (like the enhanced list of Henrik)
  • vertical slider
  • hidden field
  • tab bar
  • rich text editor. Just font size, colors, bold, italic, underlined is enough for 70% of cases. Image, tables, ... are not so important.
  • pop-up menu (linked to the right click)

2) The accessors method must be different following the widget type. 'set-face is too general. I want to be able to select a item in a list, to add an item in a list or in a tree,... I want to increment/decrement a numeric stepper. A clear documentation with widgets inheritance and inherited methods could be great (a simple drawing in one page)

3) Styling/skinning is mandatory to build applications that integrate with different OS/interfaces. Why not use a syntax close to current CSS. It's well known by developers and good for learning curve.

4) A big problem with VID2 is that the widget parameters are simply related to datatype. I propose to make something closer to flex MXML:

myTree: tree [data: get-tree-data root-showed?: false expanded?: true]
myTextField: field [data: "hello" validation: [ ... ]]

5) Another difficulty in VID2 is the control of layout. The designers usually think with "nested containers". Containers, component that display noting but are just used to organize widgets, can help a lot the vid script composing. It is more clear the 'across keyword.

myPanel: vbox [ size: 400x200 ] [
  hbox [width: 200 ] [
    list [ 
      data: get-user-list 
      change: [ "method to populate right panel" ] 
  hbox [width: 200 ] [
    text [data: "Last name"]
    lastNameField: field []
    text [data: "First name"]
    firstNameField: field []
    button [data: "Save" clicked: ["method to save data" ] ]

6) Why not allowing to declare non visual components inside a vid script. Things that are not displayed but directly related to the GUI.

  • To declare a rebservice which is a data provider for a list or a tree.
  • To declare a variable that is used in more than one widget :
      myUserList: var [1 "Joe" 2 "Jack" 3 "William" 4 "Averell"]
      toField: dropdown [ data: myUserList]
      ccField: dropdown [ data: myUserList]
      cciField: dropdown [ data: myUserList]

7-May-2008 4:59:03
Will OpenGL be a GUI option or an add-on?



7-May-2008 5:02:14
Forgot to mention:

It's not directly 'GUI' related, although it does provide for feedback, what audio will be implemented on the 'front end'? Something a little more complex than the current option would be good, full audio control.



7-May-2008 7:42:11
Please look at

for a list of widgets we need in Rebol



7-May-2008 9:56:42
I'd like to see a slightly more data driven approach. I've toyed with this a little in VID2.

view [
    myform: panel [
        field 150 name 'first 
        field 150 name 'last
        date name 'dob between 1-1-1932 1-1-1999
        button "Submit" [probe get-face myform]

'get-face returns:

[first "" last "" dob 1-1-1999]

You can combine this with a data validation dialect, e.g. my import function, to get a lot of control for a little language.

Carl Sassenrath
7-May-2008 13:12:01
Note that in general, a lot of these things have been done, but I want to make sure we remember the top level objectives. We must not forget ease-of use objectives. If only a guru can add a new style, then that would be a problem. So we want to avoid that.

On widgets: yes, a lot more than HTML. But, IMO in VID2, we did not even have a good drop down list. So, we must do the basics well first, then we can add to it. Many of those things listed above are easy to add (and many are already implemented.)

On OpenGL: This topic is for VID, the GUI. Your question is about the graphics engine, which rests far below the VID GUI. We use AGG right now, which is very good. But, it may be possible to enable both.

On audio: Good comment.

On data-driven: We have something like that in mind for fields and a good form description method (dialect).

7-May-2008 14:45:40
I think that VID3 must focus not about how creating components from scratch. But on the way to change and combine standard components.

Even if some widgets are a bit complicated to build from scratch for a "average scripter", I think that customizing an existing widget must be easy.

I'm starting to develop with Adobe Flex and I like the way to build a custom component. I always start from an existing component and I write a few code to add What I need.

Example: There is a tree widget and a combobox widget (dropdown list) but no dropdown tree. I simply create a new component based on the combo and I overwrite the display methods to display a tree.

Another example (related to VID2) is the list. The way how VID3 displays a line must be easily changed to display another thing than a text line (standard behaviour) If I change the rendering methods to display a box that contains some fields then I have created an editable datagrid !

PS: Sorry for my poor english.

7-May-2008 18:34:54
nice ideas karim, very intuitive concept of layout control.
easy to 'visualize' the layout in one view.
8-May-2008 5:47:46
'Will OpenGL be a GUI option or an add-on?'

I can see I needed to be clearer: When it comes to utilising the GUI I envisioned that no changes would need to be made to the VID commands to call the same in OpenGL (esentially mapping the widgets/menus to OpenGL) without having to 'write OpenGL'. So you'd 'enable' OpenGL for the display of VID elements or leave it disabled and use AGG.

My concern with having it as an add-on would be that this would make it highly unlikely.

Some small devices now have embedded OpenGL chipsets, so offloading the GUI to the gfx chip would not penalise performance as much as directly rendering the display. For recent small devices that have this see: Open Pandora, iPhone.

I think this would make the programming easier, no need to learn OpenGL, unless you wanted to.

So for me this means that regardless of the engine, the VID elements would be consistent. Essentially making the VID elements/widgets/whatever transparent to the rendering engine. A button is a button is a button.

Does this make sense to anyone?



8-May-2008 6:45:44

now I can see, that we did little job explaining VID3 in detail. The thing is, that we have third prototype, and right now is the time, when Carl wants to make sure, we did not forget anything important.

VID3 i much more from what you even tried to outline here. It has auto-resizing and it is layered, so at the bottom, there is a "style", which holds raw event maintanance, and calls to upper layer, the "look", which sets actions for various behaviours. Yes, even your own named actions. And the most upper layer is the "skin", kind of .css aproach, albeit a bit different.

The thing is, that the design is very flexible, and by changing "look" layer, you can make all styles behaving differently, e.g. add some animation effects to each one, or anything.

Our UI is also vector based, so we are able to scale it. We can even scale various groups of widgets differently! Our resizing model is similar to TeX one.

Although not fully accurate (related to proto2 IIRC), Henrik did very good introductory job to VID3 here:

VID3 design process

Then there is R3 wiki too as well as public alpha to download and try.

But beware - things are not polished and docs are a bit dated ....

... or you can wait for the group to review your ideas and wait for next prototype.

8-May-2008 6:48:43
Luis, yes transparrent OpenGL mapping is planned for later releases. IIRC Cyphre already did some experimenting in that regard. But - there are some problems too - AGG is pixel precise, OpenGL is not - it is like with browser, there might be differences how various OpenGL implementations are done or so I heard ...
Rod Gaither
8-May-2008 7:46:48
I think the requirements list is good as primary goals and the comments have all been good as implementation notes. It is especially good to see the easy application interface item in the list! For me I tend to worry less about how hard it is to manage a layout than how hard it is to wire it up to the data and application behaviors.
9-May-2008 18:43:03
How will a VID client be authenticated to any data sources / web services?

With Windows Domains commonplace this support needs to be in the client and prompt for credentials when needed.

10-May-2008 17:02:38
I would second the ExtJS visit suggestion with a visit to If it can be done in JS then the choice ssems to be to play well with JS or be able to do the same.
10-May-2008 17:10:27
In industrial work in Curl, the language, I find that Grid is essential; a lot of j2ee/JS web projects end up buying such widgetry from third-party. I like to remind that VisiCalc may have created the PC market in business applications ( pirated away by 123 and then Excel ) A good grid knows how to export itself as XLS and as native data-structures (for reporting: in business app's the key is always reporting, reporting) and to print itself cleanly even if scrollable beyond the viewport.
13-May-2008 4:47:23
Totaly agree with RobertS. In business applications Grid is very useful.

I love how Adobe Flex manage the datagrid syntax because the developer can customize behavior in a very simple way. For each column, he can define a replacement renderer (which display the data) and a replacement editor (which allow editing datas of the cell. Without customization, a datagrid just display text which is sometimes enough.

13-May-2008 5:01:04
(at) -pekr- Thanks for clearing up the transparency question.

I'm still very concerned over the audio aspect, I've used many a RAD that treats audio as if it were a simple 'play beep', and you have to be happy with that. Ok, it's an exaggeration, but you get the idea.

On another 'transparency' note: How well will this map onto printing? I've seen the note on cleanly printing beyond the viewport, but what about the rendered display? I'm thinking of Display PostScript (although that needn't be the implementation). This is especially pertinent to business apps that require printed reports, as well as decent looking email attachments (properly placed and formated graphs/layouts).



15-May-2008 2:36:35
I like the VID2 the way it is because it's flexible with some basic consepts we have been able to do rebGui wich is great in my opinion.

VID3 should continue to enhance the strongs concepts (simplicity of use, flexibility, cheap memory cost) and reworks completly some consepts like the way to deal with the user's interreactions.

Do i really need to be able to do round wndows with VID ? hum no

Do i really need to not spend 10 month to discover how to insert a text into a field a the text cursor position?


I think AGG is a powerfull addition too. REbol is all about language processing and I see in the trio VID, AGG, SVG lot off possibilities to do intuitive interface as flash can do them.

RebGUI shows too you don't need to have widgets with 300 subfields to get them working and flexible.

Last poing is OpenGL is bad for 2D things ... It's like taking a nuke bomb to kill a fly. dangerous and useless.

15-May-2008 3:54:44
Whilst I understand the point 'OpenGL is bad for 2D things ... It's like taking a nuke bomb to kill a fly. dangerous and useless', at least it is more pervasive than AGG, especially now that smaller devices have/are getting OpenGL on chip.

True, the source is available for AGG, so it can be re-deployed, but when it comes to smaller devices I'd rather have the OpenGL mappings to relieve the cpu. If the hardware's there, best to take advantage of it, or at least have the option to (whether for 2D or 3D).



17-May-2008 12:24:36
Parts for editors: a good cursor, a tag, a paired tag, an assignable highlighted text region, a menu, and support for big text files. Please.

RebGui is a very good example of a sustained effort to show how Rebol could be usefull for custom Guis. Good foundations for an editor would allow for many great applications. R2 was somewhat good for fields and areas, but it proved to be unmanagable for text, the cursor and highlighting being very critical. That should be in the priorities. Give us good building blocks of editors. Editing is the most virally spreading need, see wikipaedia and blogs, for instance. Ideally, allow us to show a dialect of tags decorating text, so users may define with simplicity a sandbox. I would like bloggers adopting rebol as the language of their sandbokes. This is a natural complement to rebservices.

18-May-2008 20:52:21
*Please* make VID work like "jquery"

It's brilliant, REBOL-like javascript library removes the hideous grunt from typical javascript DOM-CSS hackery. Chainable functions, lovely one-liner power. Lucid code [good to read and write]. Happy users. Fast growing community.

18-May-2008 20:59:54
jquery as inspiration for VID.. nice docs and tutorials including 'live' examples such as these:

Tutorials:Live Examples of jQuery

check out the concise source sode and its effects on the page

Steve, the eFishAnt
23-May-2008 9:17:41
A few major requirements, which we simply assume REBOL delivers in its dialects but are found sorely lacking in other technologies:

1. Extremely minuscule size for graphics code, both source and runtime operation.

2. Dynamic, reflective, extensible graphical layout dialect which is easy for the artist to remember when creating graphics.

3. Composited graphics, with broadcast quality without the artist needing to know what that is.

4. Simple, one-liner console prototyping, like: view layout [box "Hello World!" green]

...I guess I could go on forever...

Carl Read
24-May-2008 6:32:57
It should be very easy to include a layout within another layout. If someone's made a nice standalone calendar (for instance), it should be easy for them to insert it where they want it in any of their other layouts.

I know panel was for this in VID2, but it was either poorly documented or non-intuitive - and most likely both. Anything more complicated than 'panel layout-name' as the default method is bad and wrong and shouldn't be allowed.

James Hague
28-May-2008 18:19:01
The major thing I'd like out of VID is to be able to build a user interface out of arbitrarily nestable smaller sections...and to have this be dead simple. For example, I'd create a "box" full of controls, then have that whole box be treated as one element. Then I could make a paint program interface by placing that box next to a canvas. So each UI element is either a primitive or a box full of other UI elements.
Supra shoes for girls
7-Jul-2012 22:12:51
The Supra shoes for girls Asia this training camp lineup,More than 50 players from China, Hong Kong, China, Chinese Taipei, Japan, Korea, Australia and other countries and regions,Players in the Supra shoes for girls list, we are familiar with the noble, Supra shoes for girls and consultant in the lineup, not only have Yi Jianlian, Gay and DeRozan and the other two NBA players, as well as the former coach of the United Arab O'Connor, and Chinese star Du Feng and so on.
Louis Vuitton bags outle
9-Jul-2012 22:24:57
Visit buyIf want to know where you want to buy Louis Vuitton bags outlet sale, you can use online resources Designer Louis Vuitton bags outlet sale visit descriptions of the Louis Vuitton bags and the big guy for the different costs and other accessories. You can find the online destination and Overstock Handbagcrew reduced price handbags and designer handbags. Check out other great creators of these pages that have the same quality and you will be able to see, how much to save - prices really have to pay a department store shopping at this site is much more normal. Have fun while you shop Louis Vuitton bags outlet sale!

Post a Comment:

You can post a comment here. Keep it on-topic.


Blog id:



 Note: HTML tags allowed for: b i u li ol ul font span div a p br pre tt blockquote

This is a technical blog related to the above topic. We reserve the right to remove comments that are off-topic, irrelevant links, advertisements, spams, personal attacks, politics, religion, etc.

Updated 25-Mar-2017 - Edit - Copyright REBOL Technologies -