World: r3wp

but in general I am in favor of expanding the equality, as long as 
it does not have side effects like breaking:  if, any, all

I know many people would like to expand these to include empty strings 
and 0, just like python does... but in such a case, many usefull 
uses of any/all will loose their value.

I have considerably reduced useage of if and either since I have 
truely grasped Carl's elaborate and repeated use of any/all

You have to draw the line somewhere. I think we'd have to discuss 
it on a case-by-case basis, because you can't always substitute one 
value for another, e.g. strings, files, and urls. So, even though 
it seems like two any-string! values could be compared safely, that 
might not work in our favor in real life. We could create a matrix 
and examples for duscussion; I'd be hesitant to change it without 
deeper thought.

yes obviously, and we could also add a new "loose" equality ~= or 
whatever... but in any case... all matching type-pairs should be 
explicitely explained and documented.

Agreed.

and we should decide first and foremost if its the intented value 
of the datatype which is consistent or the actual lexical form which 
is the consistent measure.

in some types this will have a lot of meaning/differentiation  ... 
take the date for example... do we equate the number of seconds, 
or the lexical textual form... or both, depending on other type pair...

I think this would be a very nice session/panel for devcon 2007 with 
Carl and Gurus as panel members and any one able to assist and give 
insight.

Ladislav, yes, equality is an area lacking clear definition in rebol. 
It doesn't seem to slow day-to-day programming down much, because 
most of the day-to-day requirements were implemented first, but when 
it comes to reflective code it makes everything hazy.

WRT the rambo #3518, I think these just expose "not yet implemented" 
equalities.

In practice, a programmer would notice the failed equality, then 
convert to a datatype which supports the equality operation.

eg:
>> (as-string http://www.rebol.com) = "http://www.rebol.com"
== true

Bug: The size of the H1 is different in these two examples:

view layout/offset [h1 "query:"] 770x50
view layout/offset [h1 "query:"] 760x50

Anyone confirm ? I think it is maybe something to do with H1 and 
size-text.

hum I don't seem to see any different.. but how would offseting the 
window change the content?

Do you see "query:" on one line in both cases ?

Ah.. it's a bug in H1 init.

the bug I have is that its vertical... in both examples...

Compare these four examples:

view layout [h1 "Hello!"]
view layout/offset [h1 "Hello!"] 770x50
view layout/offset [h1 "Hello!"] 760x50
view layout/offset [h1 "Hello!"] 1076x50

yep, using the layout offset is screwy !

print mold svv/vid-styles/H1/init

[
	if :action [feel: svvf/hot saved-area: true]

 if all [not flag-face? self as-is string? text] [trim/lines text]
	if none? text [text: copy ""]
	change font/colors font/color
	if none? size [size: -1x-1]
	xy: size
	if any [size/x < 0 size/y < 0] [
		state: max 1x1 pane-size * 9 / 10 - offset
		if size/x < 0 [size/x: state/x]
		if size/y < 0 [size/y: state/y]
		size: (size-text self) + (edge-size? self)

  + (to-pair all [para (to-pair para/margin) + to-pair para/origin])
	]
	if xy/x > 0 [size/x: xy/x]
	if xy/y > 0 [size/y: xy/y]
]

There you can see state is calculated from PANE-SIZE. There must 
be the problem I think.

its possible pane-size is 0x0 which would make the text too small 
to fit horizontally... just thinking out loud here...

I'll have to continue this later - time for some exercise...

its seems to be the same for all text label styles.. like text vtext, 
etc... I guess they are all just styles from the same core face.

You can see the inheritance chain like this:
>> svv/vid-styles/H1/style
== BODY
>> svv/vid-styles/BODY/style
== TEXT
>> svv/vid-styles/TEXT/style
== VTEXT
>> svv/vid-styles/VTEXT/style
== BASE-TEXT
>> svv/vid-styles/BASE-TEXT/style
== FACE
>> svv/vid-styles/FACE/style
== none
Hence FACE -> BASE-TEXT -> VTEXT -> TEXT -> BODY -> H1

Looking in LAYOUT we see this piece of code:
    new-face/size: pane-size: any [
        all [size pane-size] 
        new-face/size 
        system/view/screen-face/size - (2 * new-face/offset)
    ]

There we can see that pane-size shrinks to 0x0 as new-face/offset 
approaches the middle of the screen. It can even go negative.

Anyone know what the purpose of that calculation is ?

It has been around since at least View 1.2.1

I think its just flawed logic.

I'll search each style's molded init that mentions "pane-size".

Obviously, but it was written for a reason. What was that reason.

my guess is that it was supposed to increas a paren't size based 
on children offset and size...

so if you position your face far off, the pane ends up larger... 
but for the top level pane this does not work, since all it does 
is move the window... this is all pretty strange.

(again, just thinking out loud.. I am deep in my head resolving a 
get_username OS call, to get proper logon user on windows) hehe

Most styles have not much to do with pane-size, but there's a whole 
branch hanging off BASE-TEXT which deal with pane-size in exactly 
the same way.

BACKDROP and BACKTILE are in a separate category, they just set their 
size to pane-size at the end of their INIT.

continuing from View: Since you can opt not to install Rebol/View 
in Windows, how about a no-file-pollution option, where REBOL itself 
will never create dirs or files, like the public dir?

I like the way you're thinking.

rambo'ed

I'd like there to be a no install version of rebol view.

a version which doesn't even ask, does not store any registry to 
remember anything and which actually looks in the directory from 
which rebol.exe is launched to find any config files... without actually 
creating them itself...

I guess the SDK versions are like this.. but they should be made 
available at large.

Maxim - that is a lost battle! Just google some of my maillist rants 
- I was faiting for reverse scenario for years, back then, when Holger 
was still with RT. View's dependency on registry, and install process, 
is what I find obtrusive

RT's opinion, and probably valid though, was, that majority of users 
do want system friendly install process ...

yes... but any developper or techie hates this.  especially for a 
development platform where you have to deploy...