World: r3wp

My recollection is that it works on Ubuntu .. but may not work on 
other linux variants

Also works on puppylinux

Also, which version of R/view since 2.7.7 is apparently problematic

(Graham's example works for me on Ubuntu 10.04.)

(With REBOL/View 2.7.7.4.3)

Also, I see 3 x's with Ashley's example, but they are halfway shifted 
outside the window at the top.

On the other hand, Linux AltME is completely unusable for me.

(Well, not completely. But the fonts are ugly ...)

is there a way to find the window face of a particular face in RebGUI?

find-window?

doesn't work as RebGUI doesn't keep PARENT-FACE consistently available.

in view (not VID) you need to do a show on a face for its parent-face 
to be updated.  but the face must be actually visible IIRC.

I've never had an issue with find-window... can you give us an example 
of it not working?

actually, I meant to say that you need to do a show on the *parent* 
for the child's parent-face to be refreshed

I've never experienced PARENT-FACE as reliable, so for the VID Extension 
Kit, I made separate functions to set it properly.

so you need to make an accessor for the pane which automatically 
assigns the parent-face.

RebGUI makes extensive use of parent-face (which is managed by View) 
... never had an issue with it.

RebGUI functions such as undisplay depend on it:

undisplay: make function! [
	"Closes parent display of face."
	face [object!]
] [
	while [face/parent-face] [face: face/parent-face]
	remove find screen*/pane face
	show screen*
]

undisplay??

2.x series.

Oh ..

what does that do vs unview/only ?

Give it the widget's face and no matter how deeply embedded the widget 
the "window" it is in will be closed. Avoids having to do unview/only 
face/parent-face/parent-face type operations.

I use this for that

unview-window: func [ face 
][
    unview/only find-window face
]

Henrik, parent-face is managed by the native code, so there's something 
definitely wrong if it does not work for you.

The question is what that would be. But I have noticed way too many 
times that parent-face is NONE for faces that should be set up properly, 
particularly in VID, but apparently also in RebGUI.

parent-face can only be none if the face has never been shown, which 
may happen if you access it during layout and before the face as 
been shown.

ok, that may be it.

I do recall that parent-face doesn't work during INIT in VID.

Gabriele is correct. PARENT-FACE is not set by LAYOUT, it is set 
by SHOW. I wrote some code which needed to know the parent-face before 
SHOW was used, so I did something like initialize the PARENT-FACE 
of every face in the face hierarchy myself.
I wanted LAYOUT to do this by default.

Would it be easy to patch layout to do this?

I've tried, but the problem is that LAYOUT is not necessarily used 
recursively and thus doesn't always have a parent-face to use.

If you have something like this

b: button "text" on-click [ print face/text ]

you can't call the button action like this

b/action/on-click b


because the on-click action refers to 'face, and 'face is not passed 
when called this way.

What's the appropriate workround apart from using named faces ?

eg. on-click [ print b/text ]

Hmm.. perhaps face is passed

How to get the color of a button?


button/color seems to return none always even though it is set with 
set-color ...

button color is controlled via draw block, not face/color.

display "" [ bt: button "Test"  button "Set color" [ set-color/no-show 
bt green probe bt/color ] button "Set Color2" [ set-color bt red 
probe bt/color]] do-events


so we can see that the bt/color is set to the right color, 'show 
is then called and bt/color is then set to none :(

this gets the color


display "" [ bt: button "test" green button "Color?" [ probe pick 
 bt/effect/draw 14  ]] do-events

What's the rationale for preventing windows with duplicate names 
from opening?  It seems to be a cause of a major bug with window 
handling.

Eg. If you have an app, and open a window1, and from that open window2, 
and then close window1, then window2 also closes but can never be 
opened again.  Removing the duplicate window title check seems to 
fix that bug.

Havn't hit that bug before, will try and reproduce. Rationale for 
this behaviour is simple: users click a button multiple times and 
open multiple instances of the same window. Coding this check manually 
is a pain ... but if you want this ability then having unique window 
titles is easy.

I presume that when you close the parent the child is still hanging 
around or something

even though it appears to disappear

It shouldn't. Perhaps it's behind another window?

Nope ..  definitely not.

Following seems to work for me:

display "test" [
	button "W1"  [
		display "w1" [
			button "W2"  [
				display "w2" [text "test"]
			]
		]
	]
]

display "main" [ text "this is some text" button "child" [ display/parent 
"Child" [ text "close this window" button "grandchild" [ display/parent 
"Grandch
ild" [ text "topmost windo"]]]]] do-events

close the window that says "close this window" and then try to open 
all the windows again

The grandchild window will not open again.

http://screencast.com/t/y0PwDD9JBYoshowing this behaviour