World: r3wp

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

actions [
	text-list [
		[ text list 1 ]
		[ text-list 2 ]
	]
]

Perhaps lit-words could be used to indicate that it's a type, eg:

	actions [

  'text-list [ set-face ... ]  ; <-- Action for all text-lists in the 
  window.
	]

this would allow code reuse

(Ugh... the sight of hard-coded numbers make me a bit queasy...)

the numbers aren't there ...

just using the order  in the block

oh

so you meant:
	actions [
		text-list [
			[ ... ] ; <-- action for the first text-list
			[ ... ] ; <-- action for the second text-list
		]
	]

yes

Not bad.

And lit-words ? Another idea might to use them to identify the name-references 
(not the element types). eg

view [
	; Structure
	text-list: text-list  ; <-- Named text-list.
	text-list ; <-- Anonymous text-list.

	actions [
		text-list [
			[ ... ] ; <-- Action for first text-list
			[ ... ] ; <-- Action for second text-list
		]

  'text-list [ ... ] ; <-- Action for the specifically named text-list, 
  'text-list.
	]
]

the big question ... will this make making gui's harder or not?

Well, why are Unobtrusive Javascript people doing it ?

For quick little layouts we can see that the separation, with all 
those extra nested brackets and interpretation requires extra effort. 
But for large, complex layouts, the separation must have some benefit.

(<--- insert benefit here..)

I have lots of complex layouts ... so I think it will help.

Only way to find out is to test it though.

I think it makes things harder, at least for a short while. After 
that I cannot see...

The reason is that there is an extra name reference needed to associate 
the action to its element, because they are now separated. In large 
layouts, the separation of structure and behaviour puts these closely 
related aspects further apart, so it means more scrolling.

Except that the structure is now much smaller without all the behavior 
code mixed in .. so it's less scrolling :)

That's true, if you *just* want to look at structure.

But what makes "structure" an aspect that deserves such attention 
? It's still not clear to me.

http://en.wikipedia.org/wiki/Unobtrusive_Javascript

I think other aspects of a program could be more important, at other 
times, or simply at different places in the code. :-/

The unobtrusive solution is to register the necessary event handlers 
programmatically, rather than inline.