AltME groups: search

GUI, nice would be a clean cross plattform ANSI C lib, handling the 
basic window & eventmanagement

and providing access via a simplified meta-api (VID-DSL). this way 
nearly all script languages could 
use this lib as a native GUI generator.

For people wondering what I was working on these last couple of month, 
here's a screenshot of the customer app I'm finishing now: http://sidl.fr/tmp/generator01.png


It's a visual editor for trading strategies that emits MQL4 code 
for Metatrader-based solutions (FOREX trading). The tree is editable 
and redraws itself automatically (no need to drag all the nodes around 
manually). This app also relies on an intermediary DSL for serializing 
the strategy on disk or before compiling it to MQL4. Here's an extract 
from the corresponding dialect representation of the tree from screenshot: 

start on 1 
if 1 buy 5 take 10 stop 10 on-profit [
    buy 6 take 10 stop 10 on-profit [
        buy 10 take 10 stop 10 loop
    ]
] on-loss [
    sell 7 take 10 stop 10 on-profit [
        buy 4 take 10 stop 10 loop
    ]
] 


All is done in REBOL/View 2.7.6 (to avoid CALL bug in 2.7.8) and 
all the source code is 47KB (25KB for the custom styles and VID events 
callbacks).


I'm at 99% completion of that app, so I've resume the work on Red 
since a couple of days.

Certainly! But I must admit that I have hesitated in the beginning 
between HTML5 and VID for the GUI.

I chosed VID only because I knew I could do it faster than messing 
around with HTML/JS libs and intricacies. I was just a bit concerned 
about hitting some performance walls or native bugs I couldn't workaround. 
Fortunately, all went well.

Janko: it's not difficult, maybe the VID docs are just lacking some 
simple HOW-TO for that?

I don't know. Please don't be bogged down by things like gui in Red 
too fast! You first have to make a langauge / a platform that others 
(we) can use and build upon and add libs when we need them. And for 
all the love to VID and like, my oppinion is still that usability 
matters the most and it's hard to beat usability (all the little 
conventions) with non-native GUI-s. Or big delevoloped libraries 
that emaulate them well enough (Qt, GTK, ...)

Vid frees you from the browser and its limitations. If REBOL only 
had a HTML interface I would have dropped the language without further 
hesitation.

No VID support at this moment, but there is growing interest in it.

It's important to distinguish between View and VID, and I assume 
that any kind of graphics engine can be implemented. I would personally 
like a View/VID like clone without the design flaws, but there is 
probably no hindrance in using GTK+ or whatever.

R2/R3: probable, for the GUI code, it depends how close our VID version 
will be (R3 VID seems to be a good model that we could push further).

Thanks Kaj ! I have My "Hello Red/system GTK+Hello World !"  :) I 
have to reed some docs and wait for Red 1.0 .. does it come whit 
some hight level VID or RedGUI ?

Pekr, Actually I only use gobs for the rendering part in R3, I completly 
rewriten myu own event handler and VID.

I don't use the VID layer furnished by saphirion

I mean - never mind you did not use VID ...

Pekr, I resolved the issue by stacking one gob per dialect (draw, 
rich-text, shape) inside one gob container.

I always use the same model and my VID engine manage itself the creation 
of the sub-gobs.

Doc, what are your current expectations about timing for a Red GUI? 
 Do you want to make it VID-like?  (my vote is for yes).  GUI was 
the "hook" for R2, and I think a GUI as simple to use as VID, even 
if not encompassing as many features, would increase RED's appeal 
dramatically.

VID-like: definitely. Not only because it is a simple and efficient 
way to build GUI, but also because it nicely shows the power of dialecting, 
applied rightly, so it "validates" the whole concept behind REBOL 
and Red. 

I was planning two approaches:


- prototype a VID dialect for cross-platforma native GUI once we 
have the right interfaces between Red and Red/System. (That part 
will include also mobile platforms, if possible, else, they will 
have rely on a mobile-oriented GUI dialect). I will probably start 
to play with it around Christmas, and try to reach an alpha/beta 
in Q2 2013.


- prototype a VID dialect for HTML frontend, having GUI frameworks 
as backend targets (Sensha, jqueryUI,...). The hard part here is 
abstracting the client-side coding, Topaz would be great for that, 
if Gabriele can find time to continue working on it. Else, I will 
need to work on my own Red to JS compilateur.


It would be also nice to have a wrapper over R3/View or a Red/System 
port of it, but it would need contributors to take it in charge. 
There are also more possible GUI options.

Now after observing development of several GUI systems, there are 
always some particular things I find wrong with them: They were designed 
with small details in mind rather than the big picture. This means 
that when a developer uses a GUI system, he'll find that some things 
are easy, while others are very hard. For example, none of our GUI 
systems are particularly designer friendly, meaning that building 
a skin requires a programmer with artistic skills. There are not 
many of those around and that's a real problem. Saphirion's R3 GUI 
was derived from Carl's work in a way, where several parts were rewritten, 
because they didn't scale enough for real-world GUIs. The rest of 
the work has been about beefing up the R3 GUI to handle what is needed.


Development often seems to go in isolated sections: Building styles, 
building a layout engine, event handling, skin system, animation 
or whatever, without a properly coherent view on the whole thing. 
We talk about how we have a really nice feature, but that feature 
may not mean much, if it's not functioning in a coherent way with 
the rest.


If I were to restart VID Ext Kit as a new GUI system, I would rewrite 
it top down: Start with an application with the simplest, purest 
GUI description and write the GUI system down from there. I would 
recommend that a GUI system for Red needs to be written like that, 
starting as early as possible and let it grow downwards instead of 
upwards with a real application in mind rather than some neat demos.

VID gets a lot of things right. Let's not forget that.

So, you want something like VID/View, that looks great, and works 
on mobile platforms. Is that correct Petr?

Gregg - no, I want ALSO View/VID, which is being kind of dismissed 
here both by Doc and Kaj :-)

Doc starts with a kind of dialect - some midd level. Kind of what 
Henrik called top-down, but with good thinking ahead. you mostly 
write VID-like dialect, which would get (not necessarily 100% automatically) 
compiled to target platforms. So on Android, it looks like andorid, 
etc., but also - for small embedded - either html5, or View ...

I want ALSO View/VID, which is being kind of dismissed here both 
by Doc and Kaj :-)

 Absolutly not, I'm just saying that I will build a native GUI solution 
 first, a View-like solution is not my priority but it is welcome. 
 If nobody makes a View-like engine, nor wraps R3/GUI engine, I will 
 consider making one myself when I will have more time.

As far as the wish for a View/VID native solution goes, I wish that 
as well. Maybe it will be possible when the JIT compiler becomes 
reality to easily adapt Rebol's VID. 

It does not have to be complete like VID, a basic set of widgets 
will get you a long way.  

Other solutions are a really good thing too, but looking at GTK and 
myself I find it hard to find out how to get GTK on my mac. It is 
not a standard dmg file I can download and install and it works. 
Other GUI solutions require integration of their package or having 
the end user of your programs to find out how to get it running on 
their machine. That kind of thing can be a real showstopper to global 
acceptance.


I know Doc is working hard and has already stated he intends to come 
up with a VID like native solution. So we can let him focus and be 
silent ,or we can comment and discuss letting him know we do care.

Regarding the Red's VID discussion - I think it's still too early 
to ask something like this. First there must be I/O implemented in 
Red. You cannot start bulding a house from the roof. I'm pretty sure 
that once Red will be mature enough, there will be people trying 
to make own VID clones. I have also no problem with native VID. It 
should be transparen imho. And tt should be clever enough to support 
different screen resolutions. Not like old R2's one. I don't remember 
if the R3's version was better in that.

If you need to know how the roof will be before starting on the floor, 
we can do it like REBOL 3 and not release Red until we have VID

Very good vid even without a fitting musical distraction! 

Today I watched a tutorial for the AVR Dragon, a kind of arduino 
thing, when I heard in that video the programming environment was 
a download of about 500MB and needed the .NET framework I stopped 
it and realised that would be about 5000 times bigger than the programmable 
memory of that board. That is why the world needs Red :)

Not sure how it works in PDF, but I wrote a VID/Postscript converter, 
using the layout engine of VID to "typeset" in postscript. Maybe 
this is the way to go for a PDF typesetter.

Nice! It's amazing how fast you came up with a VID-like dialect for 
Red.

(Same reasons many of us were initially attracted to using VID and 
other REBOL features that made it so practical).

NickA - I share your point of view. Ppl mostly nowadays think, that 
the web rules it all. However - it is still complex. I don't care, 
if we generate HTML5 (whatever it is) in the end, as far as we can 
very easily build apps using VID like dialect. I remember those initial 
days, where we had really a small script (1.6KB) to show image from 
4 webcams ...

Dialects implementations do not need PARSE, they can be implemented 
with base functions, as shown by Kaj with its VID-like dialect for 
GTK+.

There is as I read this a different issue. Dock want Red to be as 
complete as posible, Kaj wants it to officially useable. Kaj really 
needs UTF-8 (and or Latin-1) character support, for getting this, 
I guess this has to do with the Syllable operating system amongst 
others.

I would like Red to support time and random functions as natives 
and (Gregg is one of your mezz funcs REJOIN ? I want that too) be 
able to connect to a MySQL database so I can dump PHP for some webdevelopment.

Besdies that we all love to see a VID (like) solution for display 
and creating apps. 

We have to be patient agreed 100% amongst everybody? Where the roadmap 
mentions all things to progress Red, above things are not on that 
list. I want Red to have enough to make it useable in production 
and after that expand, imho that is the way to really attrackt more 
funding/enthousiast programmers and make sure current support does 
not fade/ loose interest.

I will do a prototype wrapping of the Android GUI API in a few days, 
so you'll be able to put your VID-like dialect on top of it. ;-)

WHAT is to find out what stuff is attached under an object. I use 
(d) it a lot with VID, finding out which field was filled with what 
value to see how I could go about dynamically change the properties 
like captions and values and colors.

After the mirror game and the chessboard interface, the Red compiler 
script and various cgi scripts and showing all how radio buttons 
work in VID, I can now introduce to you the application to play checkers 
(10x10 international, in dutch dammen). Not bad for a REBOL newbie 
right? Wait a moment with all of your nominations please, because:

There is a tiny issue left with the moving of the pieces when playing 
against the computer but it is minor compared to all other issues 
I have already fixed ;-)


You can download the zip file with the program here http://arnoldvanhofwegen.com/stuff/damscripts.zip

Program is started with do %damb.r and you can play after setting 
the color the computer has to play with on the panel you get when 
you click the top-left button. You can look under the hood and see 
the values the program gives the legal moves. You can put your own 
positions on the board and continue from that point.
Enjoy!

Rebol3 is dead, long live to Rebol3Bazaar


I've been quiet for a long while, and this blog is not easy for me 
to write.

I'm sitting here with a glass of 2013 Ferrarelle mineral water of 
the glass bottle... hoping to be inspired on how to write this...
No, bad introduction...

You know that Rebol is a fantastic programming language, but its 
development was discontinued and bad supported. A lot of people when 
encounter Rebol falls in love for its simplicity, a blend of theory, 
experimentation, and invention, the language embodies elegant and 
wonderful concepts and properties. It was and is the most productive 
language I've ever used. I hope your experience has been similar.


Unfortunately a lot of bad events are leading Rebol to a no through 
road:

- no direction of the new Rebol3
- no a central site open for discussion
- no updates on Rebol 3 source (well, just one every month)
- to many sites about Rebol and with no updates from years


These and other reasons forced me to create http://rebol.informe.com/portal.html
a public forum, with a public wiki and a blog, where everybody can 
contribute. The result is just 17 users, this means that Rebol is 
dying; the cathedral way of Rebol 3  development is not working.

So I'm forced by my love for Rebol to create a new GitHub repository: 
Rebol 3 Bazaar, it's a Rebol 3 source, with graphic working (VID, 
but just on windows at the moment); I promise you:


- pull requests and issues discussed and merged in 24 hours (or max 
a week)
- open to add people to its organiziation
- always update!
- link:  https://github.com/angerangel/r3bazaar


If you like to contribute write me, use GitHub or Rebol portal; you 
don't need to be a programmer, think about a new logo, contribute 
the wiki.

If you know REBOLers who might be interested in this discussion, 
please let them know about this blog posting. I look forward to hearing 
from you,
-Max

Have you checked the new version yet? Learning a lot of new stuff 
about VID, getting more code out right the first time, etc.

There a a lot of function undocumented. For example about VID a lot 
of documentation is missing, but VID is one the most important feature 
of Rebol. Similar for parse... and so on. Do you know that you can 
use "of" for radio buttons?

Others can chime in about the VID, but there are some pretty good 
tutorials about the parse dialect. Plus, you might look into the 
parse enhancement project page, which ended up with a lot of discussion 
of the semantic model, and in many cases the behavior of existing 
operations.

MaxV, this document is for the VID Extension Kit, but it covers parts 
of how VID works as well:


http://hmkdesign.dk/project.rsp?id=vid-ext-kit&page=docs&section=developer&name=vid-extension-kit-internals.txt

Max, yes, docs for VID (beyond the basics) have always been lacking. 
It took me a long time to find OF for grouping as well. Part of the 
issue is the design of VID itself, where you need to know internals, 
and there isn't a documented public interface for styles.

MaxV: radiobuttons are best used with true and false in stead of 
on and of like in some documentation mentioned. The true and false 
I just tried out of frustration and I discovered it worked. Undocumented. 
Same with the block after a text or label to make the label clickable 
like a button. 
VID has an effect and a draw that could be better documented.

Oh it is now in VID section, "alert" function.

I said you, too many nameless faces. It's something related to RebGUI. 
Rebol can't understand if a face block is new or the same already 
used. If VID had tab panel, I' would use only VID.

And it still relies on R2 combined with VID. That is logical though 
R3 and Red are the new preferred platforms for future development?

Well, at leat now you have VID source working on GitHub... :-)

In my humble opinion there is an immense wall between users and developers, 
that is not the open source way. Altme is inaccessible to most user, 
nobody know it and the procedure to register is hidden somewhere 
and too complicated; here we have no more than 50 readers. Rebol.com 
site seems a dead site. Curecode seems a secret society (it's impossible 
to reach if don't know the correct link, who is  working on it?). 
 Stack overflow is the only way at the moment users have to discover 
somenthing about Rebol, but it's not the appropriate site. We cold 
multiply 1000 times users with a good support.  Rebol must be more 
partecipative, but I don't see around anything about it.  Everytime 
I write a post about Rebol, I feel like an archaeologist with a dead 
language. Searching information about Rebol is a huge quest.
What did you do for Rebol? What can you do now for Rebol?

Do you want to build an open working infrastructure or you want remain 
sat on your chair looking Rebol going in ruin?

We have finally Rebol and Rebol VID source working, now we have to 
attract developers from all around the world.

I''m not starting a new Rebol, just making attractive for normal 
people, the bones and muscles of every good open source project.

Vid question I mean

where I am wrong ?

I have an object called news
news/tittle: "Something"
news/data: 06-may-2012

I want to display these data using VID

view layout [
	h2  news/tittle
	h2  news/date
]

news/tittle is displayed
news/date is not

Where I am wrong ?

Another question from a newcomer to VID:

Isn't in VID a god text viewever with scrollers ? Text List does 
not work here. It show only the first line of text.

Giuseppe, if it is textviewers that you are looking for, you may 
want to see Henrik's Vid Extention Kit.  http://www.hmkdesign.dk/project.rsp?id=vid-ext-kit&page=info
because if you are going to do anything slightly more complex than 
VID "text-list"  you will find data-list much more powerful. BTW, 
what are you supplying as data in your text-list?

nearly 11000 lines, almost replacing VID

A problem with VID is that there is not a true standard way to set 
texts in various styles, so each style may either use /TEXT (which 
is IMHO the wrong way) or SET-FACE (which IMHO is the right way).

The VID Extension Kit mostly solves this by not needing to know the 
quirks of each face. You just use SET-FACE consistently.

Now I have another problem: I have a "description" text field I get 
from internet and it is "untagged".  The field is very long.

When I update the field with an empty string in VID I get strange 
characters.

strange characters

: You need to set /line-list of your VID widget to show it correctly.

it is a internal field to store text in VID widgets (its about word 
wrap I think)

Perhaps it helps to learn about the mechanisms: There are several 
ways to generate a dynamic UI:


The LAYOUT function works by creating an object tree, a tree of faces 
that are simply ordinary objects. When passing this to the VIEW function, 
a layout is displayed. The layout function is part of VID and is 
as such a high level function. VIEW is a low level function to interpret 
the face tree.


The face tree consists of objects that contain other objects through 
the FACE/PANE word. If the FACE/PANE contains an object, that object 
is a single face, that is displayed inside the parent face. If the 
PANE contains a block, that block may contain multiple objects that 
are simply multiple faces. As such, a typical window is a face with 
a FACE/PANE that is a block that contains other objects.


Graphically, the face is represented by a region on the screen that 
has the size and offset, possibly an effect, such as coloring, blur 
or mirroring or a text attached to it, and image or other faces that 
are only visible inside that region.

A window is also a face.


To navigate to the parent face from a face, use the FACE&/PARENT-FACE 
word. Note that FACE/PARENT-FACE is many times not set by VID, which 
is sometimes problematic.


You can manipulate the face tree by adding removing objects dynamically 
and calling the SHOW function. You can also change values in existing 
face objects in the tree, such as for resizing or moving the faces 
and then calling SHOW again. You can also build a face tree entirely 
by hand, and this is usually the starting point for different layout 
engines, such as RebGUI, that simply build face trees in their own 
way.


The prototype face is FACE, which is a minimum requirement face for 
the View engine. The prototype face for a VID face, which contains 
a few more words, is SYSTEM/VIEW/VID/VID-FACE, which is the minimum 
requirement face for VID.


One condition for the face tree is to not use the same object in 
multiple locations. The VIEW or SHOW function will return an error 
if that is the case.


A simpler way is also to generate a new face tree every time you 
want to change the layout. Although this is slightly more computationally 
heavy, it allows you to manipulate the block that was passed to the 
LAYOUT function instead of manipulating the face tree directly. This 
technique is best used, when the face tree changes dramatically by 
each manipulation.


Another important concept is the DRAW engine which is a separate 
entity in REBOL2. It can be called to draw on an image bitmap, using 
the DRAW function or as in effect for a face object, by adding a 
parameter in the VID dialect block or by changing the FACE/EFFECT 
word. DRAW is used by calling a dialect. if you just want to use 
fields, buttons and simple user interface designs, you may not need 
to use DRAW.

You can do this by adding the buttons to a panel and update the contents 
of this panel.


view/new layout [p: panel 500x500 []] ; start with an empty panel. 
note that VID does not support scrolling panels out-of-the-box. For 
this you need the VID Extension Kit.

append p/pane make get-style 'button [] ; you will need to adjust 
for offset here, otherwise the new phase will be placed on top of 
the old one.

do in last p/pane 'init ; you will need to initialize the face, which 
is the FACE/INIT block that resides in the face style definition. 
once the init block has been run, the face will set itself up and 
then you can show it

show p

This is just a simple version of what can be done.

To clear it again:

clear p
show p


If you want to do more than this, I think you need to use the VID 
Extension Kit, because you will be spending a lot of time managing 
scrollbars and panels. It has styles that are meant for this purpose.

You might now begin to experience the VID learning curve turning 
into a wall. Suddenly you need to know a lot about its internals 
to do fairly trivial things.

Is there any other way to make an iterated label or text item in 
VID then the way stated in http://www.rebolforces.com/zine/rzine-1-03/#sect5.
or http://www.rebol.com/docs/view-face-other.htmlbecause this seems 
to me to be too complicated for REBOL. At least for me.

If the number of texts doesn't vary, it might be simpler to make 
the fields manually instead of using an iterated face. The reason 
for this is that you need to write the SUPPLY code yourself, which 
will run every time you run the code and will run on every mouse 
move, if your text has a FEEL object with ENGAGE, OVER or DETECT 
functions, whereas simply making 8 texts once with VID is both faster 
and requires less code.

That is another attribute of VID, which is that many faces share 
the same font object. Update one, updates all font objects. The purpose 
of this is to save memory, but it comes off more as inconvenient, 
when doing things like this.

You can study different styles using GET-STYLE.

For example:

probe get-style 'field


It's a bit misleading, though, as many styles share the same code. 
To really see how styles are built, you need to read the sourcecode 
for VID.

yeah, well, all I can say is that whenever view or more specifically 
VID is frustrating, you should just mold the face which is aggravating 
you, save the code to a file and read it in your favorite syntax 
highlighted editor.


you will learn A LOT about how VID.view works and learn quite a few 
Reboling techniques too.

(Carl wrote VID, so its a good example of his Rebol coding)

the other way is to use get-style.   the advantage here is that is 
preserves the init block, instead of clearing it after VID has done 
its work


a good look at the 'init block is often useful to understand why 
changing some of the face values is ineffective (like changing face/color 
is often useles... since that face is setup to use face/colors). 
 

this block is run after all the facets have been applied. 

note that you can set or append to this block in your own styles.

I have view.txt in my rebol/script folder a copy from system/view, 
it is 80000 lines mostly object definitions and images. quite different 
from the ancient one http://www.rebol.com/view/vid.rthat at least 
makes some sense to me ;-)

Arnold, take a look at the VID Extension Kit. It attempts to make 
VID more complete, although it's no longer directly compatible with 
VID.

One thing to note about VID: It was a demo toolkit that Carl wrote 
about 10 years ago in a couple of weeks. He expected someone to come 
up with something better.

Okay, thanks FOR this analysis. Concluding, where I am using R2 (because 
I 'need' VID) I use the foreach forall. The moment R3 is released 
including VID or replacement I will rewrite this code, promise!

Only thing to add is 1 small function to reduce the moves when the 
king is under attack. I discovered some weird VID behaviour too where 
alert boxes have strange formats they inherited from earlier defines 
fields.

so let's say you have something in a vid defintion

button "Test" [
	use [ f ][
		f: func [] []
	]
]

this is not subject to GC?

You seem to be trying to access datetime outside the VID context, 
where it is not defined

you get that vid error because you are referring to it before the 
layout function has run.

VID question. Is it possible to combine more than 1 fontsize, color 
within the text on a element like a label? I want to emphasize a 
small piece of the text.

just about every time I've had to fix something with VID it was related 
to the fact that redraw is being used.  its a very bad design... 
redraw should never have been put into the feel.   its also a big 
slowdow, since it forces every face to redraw itself when you show 
a pane.

(oops new VIEW/VID group now open for such questions).

Now that I think of it, I used VID with some parts done in Draw.

without this no view or vid stuff will run after being encapped

#include %gfx-colors.r
#include %gfx-funcs.r

#include %view-funcs.r
#include %view-vid.r
#include %view-edit.r
#include %view-feel.r
#include %view-images.r
#include %view-styles.r
#include %view-request.r


;-- Must be done prior to loading anything that requires fonts on 
Linux.

layout [text "imanXwin kludge"] ;-throw this one away soon-- okay?

open-events

Same as yours only with prot-setnet.r added.

#include %gfx-colors.r
#include %gfx-funcs.r

#include %view-funcs.r
#include %view-vid.r
#include %view-edit.r
#include %view-feel.r
#include %view-images.r
#include %view-styles.r
#include %view-request.r

#include %prot-setnet.r


;-- Must be done prior to loading anything that requires fonts on 
Linux.

layout [text "imanXwin kludge"] ;-throw this one away soon-- okay?

open-events

There is a beginner's level View/VID part too.

But other engines you name are far from what View engine in fact 
is - system of gobs, etc. Widgets are VID. I still prefer not so 
much perfect VID, instead of overbloated stuff ...

Kaj - I do remember View 1.0 alpha with CID (predecessor to VID) 
on a Pentium 75, 130 - ran "acceptable". Cell phones have limited 
UI needs imo, I doubt AGG will be slow. Of course some heavy operations 
might drag some juice from the battery, as it is not accelerated. 
We now need to find the ways of how to get Cyphre's idea becoming 
a reality ...

Nice, do you use some GUI for the output, kind of VId I suppose ?

REBOL 2 is no use to me because it would never run on Syllable, and 
REBOL 3 still only has a GUI for Windows and Amiga, so it hasn't 
been useful for me to make a VID frontend

My take is as follows:


- I like REBOL Word Browser - it contains even examples, is then 
easy to produce runnable examples (Easy VID), allows comments

- REBOL reference manual is good enough. I can't see any advantages 
with Clojure etc. - imo no need to copy anyone - just make a structures, 
which allow you to register related functionalities, add comments, 
examples

- I agree with Doc, that first Doc which should appear is some guide, 
which leads you via introduction to language, its main ideas and 
concepts, etc.
- word reference shoudl be auto generated imo .....

VID and other similar dialects had the greatest potential.

Pekr: I seem to remember programming that webcam demo.  I could be 
wrong, but I know I programmed *a* webcam demo pre-VID.

Hello everybody,  after some months using R3GUI I still doesn't realize 
the causes of the changing syntax from Rebol 2 VID.

My impression is that all become very complicated.  Now to decide 
every action you have to put "on-action" or something similar before 
the action block, before it wasn't needed; but the worst part that 
all is inside the gob object of the graphical object. This way you 
have to write very long commands to achieve the most simple tasks 
(show mybuttob/gob ... mybutton/gob/size). Is it just my impression?
Is there any simpler dialect?

The generic problem to solve is this: You somehow have to specify 
what should happen for different actions. 


Let's start with the "somehow have to specify what should happen". 
For this you have some options:

1. Write the application logic code in the GUI spec block. For sort 
stuff OK, for long not.

2. Just call a function from the GUI spec block and write the rest 
somewhere elese. That's IMO the best way. I used FSM and just send 
"application logic events".

The next part is the "for different actions". Same here:

1. Name them explicitly on-* and specify the code with one of the 
options above.BTW: IIRC R3-GUI has click and right-click blocks for 
convinience.

2. Define an implicit mappging from block order to event type. 1st 
block = click, 2nd = right click, 3rd = double left, 4th double right, 
etc. IMO that's not a good style.


Overall what I never liked about VID was that is was not explicit 
enough. For big projects that's a must. For small you might skip 
this but if those projects get bigger, you are hit again.

We can always build a "shortcut" dialect like VID on top of R3-GUI, 
for common simple patterns, once R3-GUI is complete.

About excuses - there are imo no excuses. As I said - we are just 
few, and ppl are busy with other things too. As for those really 
needing GUI right now (it's not me for e.g.), I think, that some 
ppl prefer what they know R2 VID, RebGUI, just because of typical 
entry barrier. There is nothing wrong with R3-GUI imo, and from what 
I studied in the past, it is much better system than R2. Sometimes, 
it is difficult to find out real reasons, why ppl react this way, 
or that way, I just dunno ...

NickA: during my private talks to Cyphre, he told me that if he would 
aproach the View engine nowadays, he would abstract it a bit, so 
that it could use various rendering backends - AGG, Cairo, so that 
where platform permits, it could be HW accelerated. But - such project 
would take some time, and Cyphre would have to be sponsored, in order 
to be able to do the work. I think, that it could be even written 
in a way, so that both R3 and Red benefit. But who knows ...


As for Red - no party is willing to port View engine, yet :-) Doc 
wants to aproach it other way - to use something like VID dialect, 
but final toolkit used would be the native platform one. Kaj did 
some example with Red/System + GTK, if I understand it correctly. 
I still think that even for Red, something like small View  engine 
would be benefical, e.g. for embedded work, where non traditional 
graphics is not a problem.


Dunno, how difficult would it be to get View sources adapted to Red/System. 
Red is missing on timers, events, etc., so maybe later, so that it 
can be naturally plugged in to its architecture ...

What do you think is the best roadmap for the graphics engine in 
R3 right now?  Simply port VID to R3 to start, and then in R3v2 change 
out the graphics engine with hardware-based code?

There are plenty of possibilities here. 

Either port VID and have to deal with it's flaws and the history 
with it
or go the path of the RebGUI
or redo VID 

I have read somewhere that Carl expected someone to come up with 
something better than VID. 

I like VID yet it has its oddities, like when positioning elements 
using 'at. It could be improved in some of its behaviours, if you 
import it you may be hindered by this aspect, and it may get harder 
than restarting with a restricted base set of widgets.

I don't think we're really out of topic here as the graphics stuff 
pertains to porting to different platforms, but if you wish, we could 
move this to the View/VID group.


When Carl was developing VID, he clearly expected that VID would 
not become the de-facto standard for Rebol graphics.  The face engine 
was the de-facto standard, and VID was simply one of what he expected 
to be several dialects for the face engine.  There were a few others, 
like GLASS, that came about.