World: r3wp

faces?: funct [
    "Get a block of faces in a panel"
    face [object!]
] [
    face: face/gob
    result: make block! length? face
    repeat i length? face [
        sg: face/:i

        if same? sg sg/data/gob [append result sg/data]  ;   <<<< UH !?
    ]
    result

I  only see that a gob and its gob/data/gob must be the same

 - that is what I thought as well. But, aftter causing crashes, I 
 had to rewrite the FACES? function to make up for the "faceless" 
 gobs, as I mentioned.

Ah, You're saying I have not the last version

So, I am asking Carl, whetherthe "faceless" gobs were his idea, or 
not.

No, Steeve, I am saying, that you do not have the simpler version 
you are proposing, since that version *was* causing crashes of the 
GUI.

Ok but, this function does not resolve the issue, it's not checking 
if the inner gobs have a face.
Or I completly lost you point.

I hope, this will help you:

faceless?: func [
    {find out, whether a gob is faceless}
    gob [gob!]
][not same? gob/data/gob gob]

Ladislav - as for docs - will you update rebol.com docs, or RMA's 
own docs? I mean - is this gui endorsed as an official version by 
Carl? I hope so, or the confusion will continu, unless Carl removes 
reference to old docs too ...

To my mind a faceless gob may have its gob/data == none!
And even if it has an object , the gob property may not be here.
the faceless? function is not safe

I mean it will throw an error in my cases

Pekr, I still have to make the doc available for Carl as well as 
for you. (lots of changes made recently).

I just mean if your docs will replace rebol.com wiki ones?

Steeve, the function is as safe as I need it to be. (the "standard" 
GUI needs to work)

Ok ok

Pekr, I guess, that you are one step faster. That will not happen 
before Carl gets the doc.

The? problem? with? painting-a? bike-shed? is? that? everyone? thinks? 
he? knows? the? right? colour?

hello.  I got to run the R3 gui and got some troubles : i use the 
r3-a110-3-1(1).exe and the r3-guihttp://94.145.78.91/files/r3/gui/r3-gui.r3
and run this : do %r3-gui.r3 and got this in return :

>> do %r3-gui.r3

Script: "R3 GUI - load and start" Version: $Id: $ Date: 9-Dec-2010/10:32:04+1:00

** access error: cannot open: shape reason: "module not found"

>> import %r3-gui.r3
** Script error: datatype assertion failed for: spec/version
** Where: assert -apply- make catch case -apply- apply import
** Near: assert/type [
    spec object!
    body block!
    mixins [o...

>>

** access error: cannot open: shape reason: "module not found"

>> import %r3-gui.r3
** Script error: datatype assertion failed for: spec/version
** Where: assert -apply- make catch case -apply- apply import
** Near: assert/type [
    spec object!
    body block!
    mixins [o...

>>

can anybody help me ?

I think you don't have the R3 version with View. You can download 
it here: http://www.rm-asset.com/code/downloads/

You need to use the R3 version with the graphics APIs included - 
recent RT releases have been core only. Try http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip
(which I got from http://www.rm-asset.com/code/downloads/).

question... why do you use:   [ face: face/gob ] and not  [ gob: 
face/gob ]  and  why you need   [ same? gog/data/gob gob ] ?

The last one: Gobs with a face have the face assigned to the gob's 
data field, and the gob assigned to the face's gob field. Yes, this 
is circular, but this is because there are two tree roots. FACELESS? 
checks for that circular reference.

Faces are often made up of many gobs, but only one gob is the root 
gob of the face, so only that gob is assigned to the face's gob field. 
The rest are "faceless".

Cannot be used better naming?

I miss the basics... for example it's not easy to display just a 
GOB in current version.

The term "faceless" is pretty accurate. What I'm worried about is 
that it will fail if the gob doesn't have any face assigned to its 
data field. It would be more robust to do this instead:
faceless?: func [
    {find out, whether a gob is faceless}
    gob [gob!]
][not same? gob select gob/data 'gob]

It would be good to have somethink like GUI/base which could be used 
to make micro guis - as a platform for own guis.

When I was talking about naming, I was thinking how the values are 
named in DATA object.

The 'data field only refers to a face object in this GUI. It doesn't 
have to refer to a face, or even an object at all. It really is a 
generic data field.

What I'm worried about is that it will fail if the gob doesn't have 
any face assigned to its data field.

 - surely, Steeve and Brian, it has to be done, if such a situation 
 is expectable. Is it?

(i.e. can we expect some gobs to not refer to any face?)

Of course, there are other situations the code does not expect, like 
e.g. if the gob/data were an integer value, etc

Throw in enough conditions and it becomes faster to just use an ASSERT/type 
[gob/data/gob object!]. Or just use a get-path :gob/data/gob and 
just accept that errors will be triggered if the function is applied 
to inappropriate gobs.

Sorry, ASSERT/type [gob/data/gob gob!]

I don't want to begin a flamewar, but troubles are poping continously 
out of my mind. 

And I wondering, Wy did they choose to use a face (an objet) as the 
entry point of most of their low level graphic functions instead 
of a gob! (which is more convenient to my minf).

I can not take away the feeling that the faces?  function should 
just be a shortcut for gob/pane.

Maybe I should not expose my impression after having eaten and drunk 
in a good restaurant :-)

The gobs are the low-level entry point. The faces are the high-level 
entry point. There are two entry points.

Most of what makes a face a face is not in the gob; the gob is just 
appearance.

I have nothing to say against it, but was that a controversy ?

IIRC gobs were introduced so that we don't necessarily need faces?

Gobs were introduced so we had something lightweight and low-level 
to implement appearance, without all of the overhead of a full face. 
That is why a face can have many subgobs without necessarily having 
any subfaces.

yeah I see them like that too. But when a gob need to deal with events, 
it has to be connected with a face.

Right, because a face has (among other things) behavior, while a 
gob only has appearance and the pane.

Throw in enough conditions and it becomes faster to...

 - I do not want to throw in any unnecessary conditions. The condition 
 I used was verifiably necessary, but I do not know whether there 
 is any other.

Put the path last in the function, or use a get-path, and there won't 
be any code injection possibilities.

surprisingly, while :word is faster than word (according to my measurements), 
:word1/word2 is slower than word1/word2, interesting

how much ?

not much, but it is surprising anyway (at least for me)

code injection possibilities

 - aha, you think that it might be dangerous if somebody intentionally 
 defined an "unexpected" kind of gob to somehow use that against a 
 security measure?