World: r3wp

and that's why you never see in a word processor a function like: 
"collect all red text for use in TOC". it says: "use headline level 
1 for TOC".

On naming, I think PANEL is too general and doesn't describe the 
layout behavior. I could live with it though. 


I agree that TABLE should be saved as that is the common term for 
the spreadsheet model. GRID was used for that for a long time, and 
still is sometimes, but GRID could also be good when thought of as 
a canonical grid layout. GRID-LAY, CANON-LAY, or TABLET aren't too 
inspiring either.

Gregg, one thing that became clear in discussions of function doc 
strings recently in Curecode is that it is impossible to fully describe 
the behavior of some programming functions and objects using just 
one name, one sentence, whatever. No matter how long you allow the 
description to be, any sufficiently complex thing won't be describable 
in that limit. And you *want* limits because people have to read 
and write these terms, even more so for fundamental stuff that will 
be used a lot. The use of small, preferably non-compound words will 
speed up the process of humans reading and writing layouts. Java 
failed this pop quiz, btw.


This is why we have names for stuff (and people too: Does "Gregg" 
describe you?). A name serves as a placeholder for the knowlege you 
already have about the object in your head (preferably) or in the 
documentation. As long as we have good documentation, any small, 
easily distinguishable name will do. You will never fully describe 
the term, but by reading the documentation, or source, or through 
experience, the programmer will know what is meant.


In this specific case, "panel" is a general term, but many GUIs have 
traditionally used the word "panel" to describe the corresponding 
concept in their systems. That term never fully describes the behavior 
of that object, but it makes a good, easy to remember name for a 
complex concept that the developer is expected to have to learn. 
By using PANEL, at least experienced developers will know that they 
will have to look things up, and inexperienced developers will have 
to look things up no matter what name we choose. You don't get the 
same benefit from the term BOARD, for instance, because while the 
English terms are similar, "board" doesn't have the historical connotations 
that "panel" does in the computing world, so it doesn't gain the 
benefit of them.

Yes, I realize ithe irony in using such a long post to argue for 
short words, but in some ways it illustrates my point :)

LOL. Thanks for the detailed and thoughtful post in any case. As 
I said, I can live with PANEL, which is good since I couldn't come 
up with anything better.

call it jigsaw :)

Mosaic? ;-)

Decoupage ? ;)

Deco ... what? :-)

box, board, mosaic, matrix, sieve, die, wire, netting, tissue ... 
and the winner is - panel :-)

small status update:


Not much happening on the release/testing side. Bolek found a nasty 
bug in MAKE-FACE, causing FACETS to be lost. Cyphre and Ladislav 
continue to work on resizing and Bolek is working on styles. When 
the styles are properly adapted to the new resizng scheme, I can 
test the new dialogs properly.

Of an interesting note, the new Google Images uses exactly the layout 
being discussed above.

And Cyphre is working on the richt-text part to work with the new-hostkit.

I'm going to see, if I can sell an ATTACH reactor to Carl. Maybe 
he has other ideas. :-)

What will ATTACHE do ?

simply attach two fields in two faces, so that when the attacher 
updates that particular field, the attachee updates also.

the R3 GUI does something like that already with a RELAY option, 
but it's cumbersome to use and less flexible.

Ok, that sounds like it could be useful.

view [
	c: color-button
	s: slider attach c 'brightness s 'value
]

or something like that.

Isn't LINK a better word?

And could we LINK to more than on target? That would be nice.

link is already used to fetch "reb content".

I see...

more than one target: you can attach as many as you can. doing it 
in blocks, perhaps can be added.

attach: [

 "Set state of a face to our face's value and performs its main function."
	name [word!] field [word! none!] our-field [word! none!]
] [

 set-face/field get name get-face/field face field our-field ; (none 
 is allowed)
	do-face get name
]

how it looks now.

What is FACE ?

a reference to the face itself

It's not defined in the above function.

Or is it defined at a higher level?

each reactor is converted to a function, where the first argument 
is the face and the remaining arguments are as shown in the argument 
list above

>> source guie/actions/attach
guie/actions/attach: make function! [[face value

    {Set state of a face to our face's value and performs its main function.}
    name [word!] field [word! none!] our-field [word! none!]
    /local
][
    set-face/field get name get-face/field face field our-field
    do-face get name
]]

; also VALUE is in there.

Ok thanks.

I think I would reword the doc string a bit for grammatical consistency.

It looks like it should be either "Set" and "perform", or "Sets" 
and "performs".

yes, sure

Does it actually set the "state" of a face, or is it really the "value" 
of a face ?

I changed the text, as that was inaccurate:


Set a field of a face to a field of this face and perform its main 
function.

Perhaps, to eliminate some ambiguity, it should be:

Set a field of a named face to a field of this face, then perform 
the named face's main function.

(Is "main function" really how it is described elsewhere ? I'm still 
stuck in R2 terminology, but I was expecting something like "action".)

there is no longer a single "action". what you do is state a reactor 
or a set of reactors and it's this set of reactors that would be 
equivalent to R2's action, in that DO-FACE performs that set of reactors 
in sequence.

and by main function, the idea is that faces can be accessed on multiple 
levels, i.e. you can also just run a single reactor in the face.

that is most useful, when working inside actors.

Ok, that makes sense then.

as I said and once again - I doubt that any such solution will be 
sufficient for all ppl, hence I am not sure it belongs to the base 
of theGUI framework ...

for cross-linking GUI elements, it might be sufficient, but for overall 
app logic? There would have to be list of possible update actions 
for each element possible change. The system I used in DOS ere had 
it exactly like that. And it worked even with grid for e.g. You deleted 
an item, and the update action was able to update your stock DB item 
related amount. The mechanism would have to be universal enough, 
because if it will not cover enough cases, it will not be used by 
developers, and will bloat the GUI code, as everybody will replace 
it with own version ..

 There would have to be list of possible update actions for each element 
 possible change.
 Could you give an example? Thanks.

Although I've implement 5 complete GUI frameworks, so far I've stayed 
relatively silent on the R3 GUI front cause I'm building my own framework 
and I don't want to interfere with the R3 system.


but I will pitch in here and say that what Henrik proposes is a good 
idea (I use the same name for a relatively similar feature), though 
it needs one thing if it is to be usable by newbies.


a way for do-face NOT to call attach.  the reason is that if you 
want several cooperating controls, they must not create feedback.

you mean circular references?

for an imperatively driven system like the R3 system, you might want 
to look at how Amiga OS's BOOPSI system managed this.  its relatively 
easy to code and allows for a much more robust data interchange between 
controls.

yes amongst other things.

yes, we could use that. this is one reason Carl didn't like it in 
the first round.