World: r3wp

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

Sorry, I mistook the third panel for a VPANEL, but that just simplifies 
the explanation that this is not a bug:


1. The button can vertically resize, as its min/max size is not the 
same. This is correct behavior according to the specs of the style. 
This is not the same as saying that this is esthetically sensible 
behavior in the button style.

2. The panel in which the buttons reside can also resize vertically, 
because the button can resize vertically. This is correct behavior.

3. The parent VPANEL, when resized vertically, can resize its inner 
faces to their limits, like an accordion. The limits are defined 
by min/max size. The second and the third panel, which both display 
squashed buttons do this, because their vertical size define the 
vertical size of the two cells of the parent VPANEL. This is correct 
behavior.


To get rid of the problem the button should have vertical min/max 
size being the same. That's all.

A simpler way to show exactly the same behavior is:

view [vpanel 2 [hpanel [button "1" button "2" button "3"]]]

btw: +1 for not allowing buttons being vertically resized as a default 
:-)

btw - I seem to have problem understanding v/h group/panel wrapping, 
when accompanied with integers:

view [hgroup 2 [button "1" button "2" button "3"]]

... I would expect button 3 to be placed under button 1?

possibly a bug, but I don't know. in the code, I can see that HGROUP 
does not use the BREAK-AFTER integer for anything.

while HPANEL does.

vgroup/hgroup are ignoring the wrapping

yes, correct.