World: r3wp

and there's also passing the face correctly to the actions

Well, it should probably be in the reverse order, I suppose. Structure 
is put in place first, then behaviour operates on top of that.

view [
	; STRUCTURE
	my-text-list: text-list data files

	; ACTIONS
	my-text-list/action: [set-face ...]
]

makes it easier for the view layout engine I guess

STRUCTURE
 is actually "NAME-REFERENCE, STRUCTURE, CONTENT"

I'd also like to have it so that we don't have to name objects and 
can point to them based upon order ...

ahh... retract that.

I've spent some time thinking about that in the past, and it's difficult, 
if not impossible.

in case we wish to dynamically insert objects into the display and 
then remove them as they do in Javascript

yes, exactly. Dynamic structure.

Why?  If there's a tab order ... then there must be a serial structure

Which can be messed up all too easily by dynamic structure. Your 
program could reorder tabs for instance.

Or, as you say, a tab could be inserted/removed.

Eg.  I like to create tables first as instant feedback, and then 
fill them with data from an async function.

But I need to overlay a busy graphic which I can then remove ...

in the callback

Ok, so you as the programmer know that your table has a specific, 
static order at the time you need to fill it. No problem.

Did you also mean that you'd like ACTIONS associated with STRUCTURE 
elements anonymously?

view [
	; STRUCTURE
	text-list data files  ; <---- element #1
	code-area  ; <---------- element #2

	; ACTIONS
	[on-click [set-face ...] ] ; <---- actions for element #1
	[on-enter [ ... ] ] ; <---------- actions for element #2
]

well, I don't want to name each element of the structure

but maybe we have to .

We could combine both approaches. In the ACTIONS section, if there's 
a word followed by a block, then the word is the name reference to 
the element (eg. 'my-text-list), but if there is just a block, then 
the next element is taken anonymously.

Any objections to this vid enhancement?

not all structural elements will have an action

view [
	; STRUCTURE
	my-text-list: text-list data files ; <------ element #1
	code-area ; <--------- element #2

	; ACTIONS

 my-text-list [on-click [set-face ...] ] ; <----- actions for my-text-list

 [on-enter [ ... ] ] ; <------- actions for the next anonymous element 
 (in this case code-area).
]

I guess they will ... on-hover, on-tab etc

Yes, that could make some confusion. Specifying empty brackets [ 
] could act as a "ignore this element".

or, [] = don't override the default actions

view [
	; STRUCTURE
	my-text-list: text-list data files ; <-- element #1
	label "on-line"
	code-area

	; ACTIONS

 my-text-list [on-click [set-face ... ] ] ; <--- actions for my-text-list
	[ ]  ; <-- actions for label

 [on-enter [ ... ] ] ; <--- actions for the next anonymous element 
 (code-area)
]

so the layout parser sets the action properties of each gui element

Just thinking, should the actions section be specified in a block 
? eg:

view [
	; Structure
	my-text-list: text-list

	; ACTIONS
	actions [
		my-text-list [ ... ]
	]
]

Now, recursive structures.

Sub-panels.

the actions would have to be specified in the panel defintion

So each panel only specifies the actions of its own top level elements.

So:

view [
	; Structure
	label "hello"
	panel [
		; Structure
		my-text-list: text-list
		actions [
			my-text-list [ set-face ... ]
		]
	]
	actions [
		[ ] ; <--- actions for the LABEL
		[ ] ; <-- actions for the PANEL
	]
]

yes ...

actions: [ skip 1 [ someaction ] ]

Hmm. Using SKIP would be like using GOTO. The trouble it's trying 
to avoid is having lots of dummy empty brackets, of course - a noble 
goal.

It would be better to simply use a name-reference (keeping in mind 
that these are now, in Rebol 3,  local to the window context), for 
jumping across a (possibly varying, during code maintenance) number 
of empty action placeholders.

or, how about 

actions [ label [ ] panel [] ]

so we can assign by type

now we don't have to keep the actions in order unless there are more 
than one of the same type

view [
	; Structure
	label "hello"
	text-area
	my-text-list: text-list
	code-area

	actions [
		my-text-list [ set-face ... ] ; <--- action for my-text-list
		[ ] ; <-- action for code-area
	]
]

So, above, during code maintenance any number of extra fields can 
be inserted before my-text-list and it won't affect the actions assignment.

view [
	; Structure
	label "hello"
	text-area
	my-text-list: text-list
	code-area

	actions [
		text-list [ set-face ... ] ; <--- action for my-text-list
	]
]

there's only one text-list in the window

There can be an overlap in names, so we have to deal with this possible 
ambiguity:
view [
	text-list: text-list  ; <--- TEXT-LIST #1
	text-list  ; <--------- TEXT-LIST #2
]

Where the name-reference is the same as the element type (text-list).

we could just use order ... and not names