World: r3wp

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?

so, what? you think, that the buttons are too small?

no, just that on the left-top, and bottom-right are OK, but left-down 
and top-right are thinner ...

And botton-left is vpanel, and top-right is hpanel style ... so I 
wonder how it is calculated :-) If you say it is OK, then it is OK, 
it was just an observation ....

unload" window (layout)" - possibly just by setting the window face 
to NONE. Most of the time, you don't want to do that, so I don't 
think any special functions are needed.

Henrik: OK, noted ...

Pekr, thinner buttons: Good catch. I'm not sure why the height would 
be different for VPANEL and HPANEL, but IMHO, they should not be 
different for any reason.

of course there could be different cell heights for VPANEL and HPANEL 
that I did not notice.

Ok, I see now what it means. That looks like correct behavior to 
me, as you are in the child VPANELs adjusting the vertical min/max 
size of the button. The demo inadvertently uses both child VPANELs 
to define the maximum vertical sizes of the parent VPANEL cells. 
This overlaps the resizing behavior of the child VPANELs, so I can't 
tell from this test, what is causing the buttons to be squashed. 
A child HPANEL that takes up the entire vertical size of the parent 
VPANEL should display identical behavior to a child VPANEL.

Just tested it, and it does, so behavior is correct.

On a side-note: Faces like buttons should not have any flexibility 
in the vertical size. That makes the UI less consistent to look at. 
The smaller the elements are in a direction, the less you want them 
to resize. A horizontal SPLITTER face or a horizontal BAR does not 
resize in its vertical direction.

My problem : solved in A96 by doing 'load-gui first !

Just tested it, and it does, so behavior is correct.

 - Henrik, I don't like any cryptic explanations to what apparently 
 looks like buggy behaviour?

If I read your above explanations, I feel completly lost :-)

The parent "vpanel2" contains 2x vpanel, 2x hpanel. And one of vpanels 
and one of hpanels gets the Y size of button stretched ...

Is there any "debugging" mode, which would allow panel cells being 
displayed? (something as chess-board, or grid-lines, to see the boundaries?)