World: r3wp

>> 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?

It might be possible that the GUI will only be used by safe code, 
so it wouldn't need the kind of hardening that the module system 
and mezzanines got. There are other ways to make things safeish, 
in theory. And code injection attacks aren't quite as bad as they 
could be if the security permissions were user-specific. Still, I'm 
in the habit now of looking at code as if I wanted to attack it :)

It would be hard to do a code injection with this code, since SAME? 
takes two arguments so you can't easily inject with a function that 
takes an argument, without causing an error in the call to SAME?. 
The only other way to inject code would need debug permissions. So 
it's not a big deal here.

Another thing to be concerned with is leaking bindings, but that's 
not a problem here (function context).

Help please ! What am I doing wrong ?

boxg: make gob! [offset: 20x20 size: 320x320 Draw: [pen red box 10x10 
317x317]]
win: make gob! [text: "Test" size: 500x500]
append win boxg
view win

Last line give :
** Script error: cannot MAKE/TO map! from: none!
** Where: make view

** Near: make map! reduce/no-set opts if no-wait [opts/no-wait: true]...

If I change the last line, I get this error :

view/options win []

** Script error: cannot access event-port in path system/view/event-port/locals/
handlers
** Where: handle-events unless if view
** Near: handle-events [
    name: 'view-default
    priority: 50
   ...

tried on R3-A96 eand R3-a95

do you get the same in A110?

it seems we are not able to display simple gob anymore?

ah, view/as-is is needed ....

DideC: try to add the following line in front of "view win": 

append system/view/screen-gob win

hehe, what is that? :-)

>> do-events
A mystery GUI event?

A110 : need to dowload it and test...

that happens when no event handler is found, which a bare GOB would 
not have:

; Obtain face or handler object, do event handling:
		either all [
			obj: event/window/data
			obj: select obj 'handler
		][
			;print ["Do-event" event/type "for:" obj/name]
			event: obj/do-event event
		][
			print "A mystery GUI event?"
			halt
		]

Couldn't there be some "default" simply one, for minimal gob based 
display? I mean - it should not be imo problematic to start ahead 
with displaying simple gob. I see no reason, why user should use 
some mysterious view/as-is, or cryptic append system/view/screen-gob 
win, to get basic gob display. I hope 'view and especially very badly 
designed 'unview will be reworked ...

View is scheduled for a rewrite. It doesn't fulfill many other requirements, 
so this is going to change.