World: r3wp

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.

In RMA A110, this simple lines gives error too :


boxg: make gob! [offset: 20x20 size: 320x320 draw: [pen red box 10x10 
317x317]]
view boxg

** Script error: expected command! not pen
** Where: show view
** Near: show window if all [
    not opts/no-wait 1 = length? screen...

DideC, try a tuple for the pen.

(but another window is opened, empty !)

tuple! : same thing.

I'am with Pekr here : "view make gob! [blah blah]" must work !

IMHO VIEW should be able to view any datatype, but that is something 
we'll look at when rewriting it.

What I want to do is to make a box with an Image as borer pen. Not 
able to do it with R2 nor R3 (see 'View group).

borer=border

DideC: to progress, please use the solution I outlined: http://www.rebol.com/r3/docs/view/gobs.html#section-13
- as you can see, it was supposed to work under Carl's GUI, but it 
somehow broke with further developments ...

Henrik: I get crashes of R3 when doing following:

>> do %r3-gui.r3

>> do %panels-21.r3 ; close a window, and do the same example again 
- it takes 2-3 runs to crash the R3

Crashes = R3 process disappears?

exactly ...

Win Vista, 32-bit. RMA A110 build, tried with downloaded and also 
on-line r3-gui.r3 populated using load-gui function. Do the script 
once, press some button, close it, do the script the second time, 
press the button - crash ...

stack problem, I suppose.

when I close the window, I expect all objects do exist defined in 
the guie structure? The question is, what does consecutive run of 
the script do to the system then :-)

That is a problem that Ladislav, Cyphre and Bolek are attempting 
to clarify and fix right now.

It seems that the memory can't be recalled back. I just watch task 
list, and I can see that running R3 takes some 2.4 MB, doing an %R3-gui.r3 
goes to some 4.8 MB, doing %panels-21.r3 starts at 7.9, but slowly 
grows to 8.8 MB, pressing some buttons/tabbing/resizing, grows the 
memory consumption to 11.2MB (why? ), closing the window does not 
return the memory back (maybe correct, as the window is just "hidden", 
but still interanlly exists?)


I wonder, if there would be any possibility to "unload" window (layout) 
and/or even to unload the gui?

Is that a resizing bug? I tried to lower the Y size of panels-21.r3 
test window, and got following:

http://xidys.com/rebol/resizing-bug.jpg

Why some buttons got thinner?