AltME groups: search

Jerry: symbol! datatype is not reachable for Red users, it's an internal 
feature. I might also add series! and context! datatypes, it will 
be for internal use only too. You can see the types hierarchy at 
page 22 of this presentation: 

http://static.red-lang.org/Red-SFD2011-45mn.pdf

(the types in italic are internal types, not accessible for Red programming).

I have extended the Red/System null driver for the Windows kernel 
into a null mini-filter driver. It now registers itself as a mini-filter 
and imports functions not only from the kernel, but also from the 
FilterManager driver, so it is now in a hierarchy of drivers. It 
now responds to a stop command, so you can stop running the driver 
like this:

sc stop hello-Red


I will set up a new repository later to publish the Windows kernel 
and FilterManager bindings and examples.

Arnold, if you underline headers with === oder --- in headers that's 
sufficient. No need to match the header. I don't like the hash syntax 
either, but when I hear talk about h6: "remember that Feynman covered 
all of physics [..] with only two levels of document hierarchy".

It'd be interesting and highly revolutionary if more cities adopted 
York's highway use hierarchy:
http://www.york.gov.uk/roads/excellence/strategy.html

(My city claims to have done -- they hired the guy who did York.....But 
the planners just don't get it, so progress is painfully sow)/

MASLOW'S MOTIVATION THEORY

The eminent psychologist Abraham Maslow postulated that people are 
animals who continually want.  No matter how many needs they have 
satisfied at any one time, they constantly struggle upwards to reach 
higher levels.  He classified these needs in a sequence of five levels 
the he referred to as "the hierarchy of human needs".


The FIRST LEVEL is the lowest and most powerful.  Maslow describes 
first level needs as the physiological needs, which include hunger, 
thirst, sex, air and rest.

SECOND LEVEL: Safety and Security - Shelter, clothing, protection 
from enemies.

THIRD LEVEL: Love and Belonging - Acceptance, friendship, lovers, 
family.

FOURTH LEVEL: Esteem - Recognition, respect, achievement, prestige, 
independance, importance, attention and appreciation.

FIFTH LEVEL (Highest): Self-actualizatoin - To develop or achieve 
one's full potential.

A hidden legacy filesystem hierarchy with a user-friendly one overlaid 
on top. And the sensible one to use depends on what you want to do, 
but command line tools (like REBOL) can quite easily access both, 
if you know what you're doing.

I realised when mimicking the behaviour of DO EVENT, that the reason 
the target face is not given is because its impossible to know at 
the time DETECT is called. Events travel down through the face hierarchy 
through the DETECT functions, the evaluation of which could have 
an effect on the result. The DETECT function can block events or 
allow them through, depending on the result they return, which is 
programmable and therefore dynamic. So a DETECT function higher up 
in the face hierarchy which is evaluated before a DETECT lower in 
the face hierarchy cannot know which is the target-face, because 
the result of the lower DETECT may change the target-face.

I should say, it is context that allows sub-contexts.  It's more 
of a hierarchy...

I don't think there is a hierarchy of contexts.

In Jaime's example there is a hierarchy of blocks (nested). As evaluation 
proceeds, the words in those blocks get "painted" different colours. 
That's why my code using bind ends up with the same binding of words 
even though I didn't have the same hierarchy of blocks  - I simulated 
the same order of binding.

Brett I aggre that there is hierarchy of blocks. I guess what I was 
getting at is that rebol implements context  internally using some 
sort OO technique to keep track of the assignments. In this case 
the OO technique is  lookup chain.

I'm not sure a hierarchy would work here - there are too many dimensions. 
Platform (Core, View, ...), platform (Windows, Linux, ...), version, 
test version, etc. Plus a test version would have applicable platforms, 
expiry both for bugs in the test and for changes in expectations, 
and cached results. I'm thinking of more of a formal test suite here 
than an arbitrary test server farm.

Today I was thinking about REBOL paths and namespaces navigation 
"problem". I would like some clever persons 

here, to educate me a bit in that area. So far I think, that REBOL 
breaks on some path rules, of course it 

depends, upon what "philosophy" you provide as an explanation. So, 
I was thinking about 

namespaces/paths/context, as of a tree .... So, all words are defined 
in top (global) context = root, right? 

(excuse simplification). Then comes first question - how can be following 
valid?:

a: 5
b: context [print a]


My objection is, that from the point of  'b "node", there is no 'a. 
So, my explanation is:

1) in the case of directory, we would use ../a
2) or we should go via root reference - b: context [print /a]

3) we create "philosophical" rule, stating that global (top) context 
words are propagated to subsidiary nodes 
(contexts)


I don't mind case 3), if such rules are well defined, and it will 
come, once we switch to modules.


How did I came to think about above? I have somehow aesthetical issue 
with REBOL, when I look at e.g. scheme 

code in R2. It is full of awfull system/words/word references. I 
don't like it. What I would like to see is to 
have some abbreviations. I know that we can do e.g.:

_print: system/words/print


My question is, if we could have some more abstracted solution? Do 
you remember 'with keyword? I don't 

remember how it worked, but I would like to have some ability to 
"bind" particular word from existing context 
to actual context:

bind system/words node here, so that I don't need to use paths
 (kind of like when you create links in unix 
filesystem hierarchy ....


Of course, here we go - we could easily get some colision, e.g. if 
target context contains the same words. But 

maybe that could be somehow taken care for (I thought e.g. about 
automatic adding of underscores, e.g. _print, 
but that is not good solution).


Well, the thing is, that I am not actually even sure, what am I asking 
for :-) So, I would like to ask, if 

some REBOL gurus thought about such topics, or am I completly unrealistic 
here?

Thanks ...

Petr, there is no such hierarchy in REBOL. there is no "parent" or 
"child" context.

how is that? Even with VID, you can set facets to 'none, if you don't 
need them. And layout is involved only during parse and VID decomposing 
phase, not later, so imo only time it takes is to initially parse 
and build View face level hierarchy, no? Then there is imo no difference 
from RebGUI.

Mmm... maybe I imagined it.... You have to admit it's a simpler face 
hierarchy though.

So the face hierarchy looks like this:

tool-bar
       |
icon-frame
      /  \
    /      \
icon   text


I would suggest blowing away the feels of the icon and text and do 
all your event handling in icon-frame/feel.
Is there any reason you can't do that ?

For those creating documentation involving a face hierarchy, here's 
a function which may help to visualise it:
do http://anton.wildit.net.au/rebol/doc/demo-to-3d-layout-image.r

The user who rips a face out of a face hierarchy will have to be 
sure to also set the parent-face to none.

A style a day keeps the doctor away:

New idea for a style: A "FLATTEN-PANEL" is a PANEL which "explodes" 
its
pane directly into the parent face's pane. eg:

A normal PANEL and resultant face hierarchy:

	layout [
		panel [
			label
			field
			check
		]
	]

	window
		panel
			label
			field
			check
	
A FLATTEN-PANEL and resultant face hierarchy:

	layout [
		flatten-panel [
			label
			field
			check
		]
	]
	
	window
		label
		field
		check

Implementation and test:

	view window: layout [
		style flatten-panel PANEL with [
			append init [
				foreach face pane compose [

     face/offset: face/offset + (do bind [where] first find second :layout 
     [new-face:])
				]

    append get in get first find second :layout [new-face:] 'pane pane
				clear pane
			]
		]
		
		at 500x200
		flatten-panel [
			label "hello"
			field
			check
		]
	]

I think what you have in your situation, with objects built from 
XML, is different than mine. I take advantage of being able to use 
blocks in my structure which allows me to insert my additional associated 
info. With your object hierarchy, it's problematic to add your own 
extra fields for state because the XML, of course, might already 
have those field names as part of its data, so there's possibility 
for collision there.

However, (as I see in my notes,) I was strongly considering for my 
purposes a structure like this:
		file-structure: [
			%OHS/ [
				%adir/ [
				]
				%afile
			]
		]
		associated-file-info: [
			%OHS/ make object! [...]
			%OHS/adir/ make object! [...]
			%OHS/afile make object! [...]
		]

Aha, I know what's probably happening. The scroll-panel contains 
a number of subfaces in a face hierarchy. You are probably not clicking 
on the scroll-panel face, but on one of its subfaces (which are laid 
on top of it, event-wise). If you look at scroll-panel.r, near the 
bottom of the rebol header, you will see the face hierarchy, with 
the two scrollers, the CROP-BOX and the SUBFACE inside the crop-box. 
The SUBFACE covers most of the area of the scroll-panel, and the 
two scrollers take some from the sides.

You can test this idea by giving the scroll-panel an edge, then alt-clicking 
on the edge. You should get a positive identification then. But of 
course, this is probably not very useful to you. What (I assume) 
you will need to do is, given a face, find out if it is inside a 
scroll-panel (or inside a particular scroll-panel of yours). This 
is a little bit complicated, but I have done most of that coding 
already for  mouse roll-wheel scrolling. (See scroll-wheel-handler.r, 
and demo-scroll-wheel-handler.r for how to use it.)

re: comments in 'core' on the plague of MI ...

multiple inheritance works rather nicely in Curl since you are required 
to provide 'secondary'  constructors - I prefer prototype-based with 
an option for class hierarchies, personally ( try experimenting with 
Logtalk if you can find time ).  I am watching Io, the language, 
evolve as Rebol3 emerges: what is interesting to me is that I ask 
'But is that Oz ?' in Oz. ( which is multi-paradigm )  I used to 
hear a lot of 'getting it' about Prolog and Smalltalk.  After almost 
2 decades in both, I think many of them "didn't get it" ( class hierarchy 
obsessed, as ST purists are/were ).  Ruby is so much like Smalltalk 
that I am quite enjoying watching Groovy play catch-up with Ruby 

Most issues in Rebol have a parallel in Javascript; where ( for the 
neophyte) experiments with 
	typeof

in a console is about the only way for the average developer  to 
'get  it' given
	d1 = Date  // now you use d1 as a function d1()
	d2 = Date()   // d2 is a string that looks like a number   

 d3 = new Date() // d3 is an object but it is UTC but it is presented 
 local time but it is compared UTC .... 
or
	s1 = "string"
	s2 = String("string")
	s3 = new String('string')

 s3[1] = 6   // s3 is an object, as typeof of reveals; String 'equality' 
 in JavaScript even with === is no end of grief  and  for what convenience 
 ?
	s3["size"] = 6
or
	a1 = Array(42)
	a2 = new Array(42)

I think the latter 2 show just how rushed LiveScript was pushed/forced 
out to market as "LavaScript" before the Sun "StrongTalk" folks had 
much influence on the Netscape folks ....  Rebol3 is in better hands 
than 'ActionScrtpt'  as it drifts into classes - because it is being 
kept 'in hand''

The changes in Groovy as it complied with the JSR for Java scripting 
are interesting ( Groovy is almost neat as Rebol would be if it were 
confined to, say, living on  top of VisualBasic ;-)  Now to avoid 
'Rebol on Rails' ...

I think some people who adopted Spring to cope with Java would appreciate 
Rebol ( there, too, you have to 'get it ' )

 MySubClassObject.prototype = new MyParentClassObject()   // now go 
 mess with THAT object before it is useful ...
	// ...

 MySubClassObject.prototype.superclass = MyParentClass  // to fake 
 having a superclass other than Object
cannot be much easier to "get" than anything about Rebol
	use    ; now mostly use /local
and

 bind   ; modifies the block it is passed; use COPY refinement to 
 preclude this side-effect

Smalltalk80 was like "Rebol4" as compared to the first passes at 
an O-O language ...  someone who actually understands Smalltalk contexts/blocks 
and JavaScript should 'get it' with Rebol ( some of those people 
are using Seaside with Squeak, Dolphin and/or VisualWorks ST )

  my 2 cents:  a1 should have been an array of fixed size and only 
  a2 should be a Vector object

Make it a page hierarchy for PARSE and you've sold me. You're good 
at wikis, why don't you go for it?

I have been inspired by the make-doc line.  Robert's rendition is 
fantastic.  Love the whole site in one file thing.  Keeping the CSS 
out of the rendered html is good, using classes.


MDP-Browser sounds really cool.   a makedoc/spec browser for makedoc 
formatted scripts.


I have been playing with a document format that I call nulldoc, which 
is mostly a set of generaly rules about how plain text documents 
have been formatted traditionally, or how plain text copied from 
a web browser can look, and I started developing a set of broad regular 
expressions to markup plaintext.


based more on what I wanted than what I actually had, the rules I 
came up with go something like:

two blank lines begin a new nulldoc document (segment)
spaces/numbers/letters/symbols represent lists.

tabs/spaces at the beginning of the line denotes code/hierarchy. 
 

tabs that are trapped by non-space on both sides means tabular data.


I differentiate between code and hierarchy indentation by short-circuiting 
code switch with #:


	code section

#	numbered section


I wrote a web page that reads the KJV aloud using an MS Agent character. 
  Used a control from MS for a menu   I had it voice-activated, but 
that was a drag so I used "web navigator control"  stupid name for 
a menu.  I think it's still up at http://members.cox.net/rovingcowboy/kjv/
 probably won't speak unless you have sapi 4 voice installed, though.

You mount media from the /dev hierarchy, for example:

well, how is feel tied to gob? Is it automatically done, according 
to gob offset, and even offset? What if there is many gobs under 
the event offset? Hierarchy applies? Can we have event-transparent 
gobs?

The events system would be splitted in two parts :


1) A small part in JS on client-side catching keyboards and mouse-events 
and sending them asynchronously to the server.


2) A server-side part emulating the View event propagation engine 
through the face objects hierarchy.

Ok, those were icons vs. menu. As for tree-view, menu, grid data 
blocks. It is still the same problem, of how to efficiently use rebol 
structure (block of blocks) to represent tree (=in the meaning of 
hierarchy here). If we think twice, we can see that similar discussion 
is being held in XML group. We parse XML, and want to store it somehow 
efficiently, being able to navigate to some path(node), to read some 
item, but also to change it etc ...

Uploaded build#107 with new tree widget:

USAGE:
	tree data ["Pets" ["Cat" "Dog"] "Numbers" [1 2 3]]

DESCRIPTION:
	Values arranged in a collapsible hierarchy.

OPTIONS:
	'expand starts with all nodes expanded


It's very basic, can only handle a couple hundred entries, and still 
has some UI quirks ... but it works and is only 3Kb.

Exactly.  There is also the concept of having widgets remember from 
session to session.  We are working on this for tabs in Qtask (we 
already do some of it).  

Each person wants something different, so we focus on it first doing 
what you expect it to do.


I have an idea for something that could be really cool, or really 
suck.  The good news is it is completely passive, so it won't annoy 
anyone.  The concept is this:


A magic mode you can jump into on any application or service (ASP).


In this mode, everything does NOT behave as expected, but rather 
become more abstract and detached.  So if you click on a button, 
for example the [Send] button here in AltME, a menu pops up:

---------------
Send
What is this?
Options
Rename
Translate
Shortcut key(s)
---------------

For each of these


Send - simply does what ever the button is actually meant to do (in 
this case "Send"

What is this? - Jumps to help, and has a bi-directional unique ID.

Options - Things you can set about the behavior of this button, for 
example, with "Send", you might want to know about the multi-line 
feature.
Rename - Rename this button in the current language.

Translate - Change or give this a name in another language (superset 
of Rename)

Shortcut key(s) - Se the shortcut for this, and also see all the 
others so there are no conflicts.  Allows for mode hierarchy of keys.



Would be really cool to make this a framework of its own, so that 
it is automatic.

Ashley, yes exactly. I think users will be much better in remember 
a screen layout instead of where in a menu hierarchy you find an 
entry.

Gabriele is correct. PARENT-FACE is not set by LAYOUT, it is set 
by SHOW. I wrote some code which needed to know the parent-face before 
SHOW was used, so I did something like initialize the PARENT-FACE 
of every face in the face hierarchy myself.
I wanted LAYOUT to do this by default.

Another idea someone proposed in this thread which is very interesting 
if it is possible, is tracing a hierarchy of all the native Rebol 
word. If such a structure really undelies the whole or part of the 
400 word list, then this would be a powerful conceptual tool to aid 
in building learning "environments" for the language.

I'm actually interested only in keypress events...

But I have to limit the rate of events... I know there is the rate 
element in every face, and I did make it work for time event and 
that is ok.
But I couldn't make keypress event occur in timed intervals.

I'm not saying I have to have it. Maybe it just isnt supossed to 
be. But it says in docs:


The focal-face must be set to a valid face object (one that is part 
of a pane in the face hierarchy) and the system/view/caret (explained 
in next section) must also be set in order to:
   1. Receive keyboard 
events ....

So I put this inside engage func:

system/view/focal-face: face
system/view/caret: tail ""


And now it works... I dont even use caret but you have to set it 
to some bogus value!


So in my opinion rate element has no influence on key events (if 
I type like crazy I get 19 key events for 1 second...).

But I can make some sort of counter and simply do keypress response 
only when I want to...

(Less faces in the resulting face hierarchy, so should be more efficient 
to redraw.)

The layout produces a face hierarchy like this:

	window face
		IMAGE face
		BUTTON face


So that's two faces needing buffers refreshed whenever you do SHOW 
window.
It's faster to have just one face (the window face).

	window face

The trouble is that it'd require an abstraction of the key features 
of all menu systems -- another excuse for delaying a new View.  Perhaps 
our representation is a dialect, though it might also be an involved 
object hierarchy, as faces/gobs are.  However, any effort to get 
this right will benefit every View application immeasurably thereafter.

Henrik - who not let it just be a style? Just like tab-view is container 
for other stuff? You could start the hierarchy with - view layout 
[app-window split-window 3 [list-box .......]]

I tried in r3-alpha to make a list of things, to be tested, with 
a hierarchy from a description from Carl. (The r3-status.r script) 
But it didn't happen the way, I had in mind.

Let's see, based on Carl's original testing hierarchy, protocols 
is level 18. No, I won't start testing protocols, when all the levels 
below that has bugs.

Weird - I thought it was a strict hierarchy of increasing equality. 
Never wrote code that would be tripped up by that.

this hierarchy never existed, AFAICT.

the "usual equality" is the coarsest equality we have - so the coarsest 
side of the hierarchy exists

if we want the hierarchy to be linearly ordered by fineness, then 
the equality should compare just spelling of words, the second one 
- finer and non-existent yet, should compare spelling and binding, 
the third one should compare spelling + binding + datatype (can be 
strict-equal?), the fourth one is not that necessary in this case

(it was certainly not a prototype of any specific member of the current 
equality coparison hierarchy)

these index issues - there are simply too many variants of equality 
- the Equal-state? comparison is certainly unrelated to any of the 
currently proposed hierarchy levels

when we don't find a word in a slot, we fail;  my question is COULD 
we tolerate an unset! where a word! is now expected ... the Rebol 
path! type is just too useful to ignore here ...  and our use of 
the character '/' does have "something" to do with our natural interpretaion 
of file and url - files assume valid hierarchy depth at time of tracversal, 
a web server need not ...  at the moment we have no type corresponding 
to what follows an HTTP schema and domain other than string .... 
or am I mistaken?

I am trying to think through this as a "clade" and not a fixed "hierarchy" 
... as in every case of c2.com as a "terminal" tag there is a common 
"phylogenic" ancestor in "smalltalk" or "wiki"      Tagging is usally 
seen as in conflict with hierarchical ontoly and I am trying to get 
my head around this in looking at REBOL versus ICON to parse thses 
cl1p.net paths if I opt to go with them.   Gabriele last looked at 
some of my odd notions here ... they come from working in a PROLOG 
variant ...

For instance, there isn't anything in the HTTP or URL standards that 
say that the path is necessarily a hierarchy, though the (poor) cookie 
standards definitely imply it. Ignoring the cookie standards, you 
could easily look at it as a tag list. However, you would need to 
be writing the server app to do so, since the server is what decides 
what the path means.

I finally started playing around with liquid.r   Having a little 
trouble conceptually with converting code that contains objects into 
the data-flow model.  For example, I was fiddling around with a D&D 
character generator.  I have an ABILITY! object class that I'm trying 
to convert to the model now.  SUM is just a function that adds up 
all the values in a block


ability:  [[1 -5] [2 -4] [3 -4] [4 -3] [5 -3] [6 -2] [7 -2] [8 -1] 
[9 -1] [10 0] [11 0] [12 1] [13 1] [14 2] [15 2] [16 3] [17 3] [18 
4]]
ability!: make object! [
	base: 0
	modifiers: [0 0]
	total: does [base + sum modifiers]
	ability-mod: does [ability/(total)/2]
]


It may be a lot to ask, but would it be possible for someone to convert 
this to liquid, so I can actually see how one creates this kind of 
hierarchy in data flowprogramming.

This is one area QM has sought to resolve.  It's likely it can be 
done with Cheyenne app methods?  Use Hijax -- build an RSP hierarchy:

<template>
  <portion />
</template>


Access %template.rsp when requesting a full page, and %portion.rsp 
when you only want inline content.  Use JS to hijack links to full 
pages and replace them with methods to access and display inline 
content.

If I have a single wish, it would be for all of the mods and handler 
scripts to have a verbose rebol header.  it would help a lot understanding 
the hierarchy and purpose of some of the mods.

Mods hierarchy: there's no such relation between modules, it is more 
an event matrix as described here: http://cheyenne-server.org/blog.rsp?view=25
(slide 5)

This is both against the structure of Unix and modern Windows systems.


UNIX filesystem layout usage are not identical. Here are the Apache 
error log location in just 3 UNIX flavours (among dozens):

* RHEL / Red Hat / CentOS / Fedora Linux Apache error file location 
- /var/log/httpd/error_log

* Debian / Ubuntu Linux Apache error log file location - /var/log/apache2/error.log

* FreeBSD Apache error log file location - /var/log/httpd-error.log

and here are the possible locations of configuration file:
* /usr/local/etc/apache22/httpd.conf
* /etc/apache2/apache2.conf
* /etc/httpd/conf/httpd.conf


Notice how the file name changes too (both for the log and conf files). 
BTW, I personnally prefer the GoboLinux approach ;-).


One the Windows front, it is barely better. The registry database 
is fine for storing parameters (name/value couples), but not a REBOL 
dialect file. A common way is to store files created at runtime in 
%USER%/AppData/Local/<appname>/. Cheyenne stores all his files (including 
config file) either in the local folder or in %ALL_USERS%/Cheyenne/. 
Storing them in %USER% hierarchy should be better.


Taking into account every OS specificities (or oddities) is not always 
a good choice for a cross-platform product. I know that Cheyenne 
needs to be gentle with the OS best practices, so I am willing to 
improve it whenever it is possible, but without sacrificing the default 
behaviour (because that is the way I want it to work for me).


BTW, I am also willing to test the centralized logging approach, 
but it has to be a cross-platform solution. So an abstraction layer 
needs to be built with connectors for UNIX syslog daemon and Windows 
Event Logger (they are two types to support: pre-Vista system and 
new Vista/7 one). Has anyone already worked on such wrappers with 
REBOL?


I personnaly need that the log files be exactly in the same format 
and if possible at the same place across platforms to make my life 
easier, so this will keep being the default anyway. The current -f 
internal Cheyenne command line (Windows specific currently) could 
be extended to work on UNIX too (and no Max, this one cannot go into 
the config file, because it indicates where the config file is located 
;-)).

(http://www.ogre3d.org/docs/api/html/hierarchy.html)  but extremely 
well documented...

In general you never access a word through a module path. If it needs 
to be user-accessible, export it or wrap it in a function that you 
export. System accessible is another matter, and usually involves 
installing something somewhere in the system hierarchy (like system/schemes, 
for instance).

The way that Java does it is unnecessary in R3GUI: For Java, they 
have to maintain an object hierarchy; REBOL doesn't need to do that, 
so even the layout managers are styles. The group and panel styles, 
for instance, are only layout managers and have no inherent appearance 
of their own.

box clipping of gobs is making them harder to use than they should 
for general graphics use when gobs are nested into panes. 

it would be nice to be able to support a clip? parameter.


for example, it would be nice to be able to use 0x0 as the origin 
in which to draw (so that negative offset values be used in the draw 
block), but we can't unless we always add a transform to the draw, 
which has to managed along with the size at any change in size.


go three pane deep, and we have to manage all the hierarchy all the 
time its pretty complicated for nothing.  


pane grouping should allow them to be used, just for transform, not 
only for visibility.

Maybe we need two separate things - style grouping (use gui/widgets 
for that), and style hierarchy - tree or other map of styles, their 
inheritance and dependencies (maybe this is what Rebolek now referst 
to as an object browser?)

btw - when I derive style by 'stylize, is there the 'parent field 
being set, so that the hierarchy can be created?

'stylize hierarchy, not at this time, I think. it would be easy to 
implement if we need it.

CSS is clearly much more flexible in setups. You use tree of definitions, 
which are then applied in particular cases in document hierarchy. 
 If I am not mistaken, right now we don't have no easy way, of how 
to make e.g. first button in a last row of the panel e.g. red, unless 
you first define red button, and use it in the source of the layout 
:-)

It is possible, I think, Graham that a face can be in more than one 
heirarchy; so PARENT and CHILD alone does not describe which hierarchy.

Other structures that may have child/parent faces: panels within 
panels; Z-axis visibility.

One of the attractions of #1 is that it makes it easy to implement 
"default handlers" at some point higher up the hierarchy. For example 
based upon an  "esc pressed event" (if one were to exist.) and you 
had designed a panel with four buttons. If you wanted to close the 
panel when the user pressed esc, you would simply have a single "handler" 
for the panel which would receive the event.


I'm sure that this isn't  the best example and apologise in advance 
for my ignorance of REBOL3-GUI and its common terms.

(a simple actor "propagating" some event up the parent hierarchy 
can be easily inherited)

It's not refined in my head yet enough but i think 'IN needs of a 
redesign.

Especially this form allowed by the specs but throwing an error currently.
>> in [obj1 obj2 ...] [a b c d]
== Error!

it could be powerfull, allowing to inherit properties from a hierarchy 
of objects (think about nested gobs with their own context)
But it's not enough...
I would like that the returned block discard the unbound words.
It would be consistent with the single form.
>> in context [a: 1] 'b
== none

I don't know if i'm clear...

The same goes for the 'sys boot level argument - it is also imo not 
accurate. Boot level arguments don't directly link its meaning to 
system contexts and hierarchy. They are more like packages of functionality 
to boot. 'sys should be imo definitely replaced by 'base, which we 
are used to for all those years ...

There was a big debate about this before we hammered down the current 
equivalence hierarchy, including the operators. There was even a 
suggestion to have ~= refer to EQUAL?, making = refer to EQUIV?, 
but we finally decided that the paying attention to binding and exact 
IEEE754 equivalence was too advanced for most uses, so = was assigned 
to the most forgiving form of equality. Many other languages with 
an equivalence hierarchy have made a similar choice, so it shouldn't 
be too surprising.

Too bad we don't have a hierarchy of inequalities. Only two levels 
would be needed. Maybe a /case option to the functions that the the 
operators map to? Is it even possible to map an op! to a function 
that can take an option?

We have a ticket for an improved equality comparison hierarchy:
http://www.curecode.org/rebol3/ticket.rsp?id=1834

I think that would nicely fit with a inequality comperison hierarchy 
as well (strict vs non-strict).

Nicely fit with an inequality comparison hierarchy
, of course. Bad typing day, I guess.

The term "relative comparison hierarchy" may be better, since it 
wouldn't include NOT-EQUAL? and such.

Andreas, given that Carl is one of the ones who was tripping over 
the equivalence hierarchy (that he helped decide on) that ticket 
looks pretty promising. The caveat is that Ladislav is the one who 
would likely be doing the work, and he seems to need some convincing. 
Plus, it would require a new R3 release, not just a host kit update.

1. The easiest way for now will probably be a directory hierarchy 
under lib:
lib/1.3/libr3.so
lib/3.1/r3lib.{dll,exp,lib}
lib/4.2/libr3.so

#1830 doesn't actually use STRICT-EQUAL?, so reordering the hierarchy 
won't help. You need to see the new 1830.

If you want I can write up your reshuffled hierarchy as a CC ticket. 
I think Carl would like it, ans the binding issue has bit him in 
the past.

We considered ~= in the last round, but that would be even more approximate 
than =, so the hierarchy doesn't work unless ~= means EQUAL?.

BTW, we could also make the View face/gobs hierarchy a common layer 
on top of all those GUI frameworks, if the overhead is not too high.