World: r3wp

Correcting my overlooking: FACES? : FACES-OF = 5:9

Not the topic, but this function does a strange control.

what do you mean?

In the code, why does it need to check if the contained gobs have 
a consistent data/face/gob ?

It should be consistent at first, no ?

Anyway, for me, REBOL standard is still SUFFIX?, not SUFFIX-OF, since 
it is documented as the proper style, as well as used in the majority 
of cases, like Andreas noted.

In the code, why does it need to check if the contained gobs have 
a consistent data/face/gob ?

 - because we had problems with text-faces, which contain a face-less 
 gob, i.e. a gob for which gob/data is a face, which does not have 
 face/data = gob. This caused a cycle for faceless gobs.

I do not know who introduced those faceless gobs, does somebody know?

I have two questions about R3 GUI : 
* do you have a demo script ? 

* do you have the same design has shown by Carl in march http://www.rebol.com/r3/docs/gui/guide.html
?

demos are available, just see above (Henrik mentioned how you get 
them)

Ladislav, actually I don't see what you said in this function. I 
 only see that a gob and its gob/data/gob must be the same, which 
is rather curious

The design has been enhanced, the new doc is almost ready, will be 
made available on Tuesday, I think.

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.