World: r3wp

Even if we get a stable R3GUI in the next year, people won't stop 
overnight using R2

It's even worse than that, the true "cut-over" for many won't occur 
until we have a stable R3 SDK! ;)


Having 2 versions of RebGUI (b117 and b218) that are each 95% done, 
but each with their own bugs and quirks is not an ideal situation 
... so I'm [again] looking to complete the 2.x series and finally 
obsolete b117 ... but R3, as always, is so close ...

I think R3GUi is not really relevant to the development of RebGUi 
...

Although not vapourware,  R3 has had a deleterious effect on R2 3rd 
party support

re: button colors. A QAD fix for b117 follows:


Edit rebgui.r and make the following changes to the button widget 
starting on line 1260:

	- Add a new attribute ... old-color: none
	- Add the following to the init function ... old-color: color

 - Change color references ... replace "colors/theme-dark" with "face/old-color" 
 (leave the "color = colors/theme-dark" ref though)

has had a deleterious effect on R2 3rd party support

 ... agree, no-one wants to invest time into something that could 
 be obsolete at any time. If I 100% knew that we wouldn't have a stable 
 R3 SDK (for Mac, WIndows and Linux) for n months then I could make 
 a rational investment of time ...

My question is: where is the font problem in RebGUi on Linux?

And my answer is it's not a RebGUI problem. Try the following code 
on 2.7.7.3.1 (Windows):

	view center-face make face [effect: [draw [text "xxx"]]]


You should see 3 black x's in the top left corner of a new window. 
Now try this on 2.7.7.2.5 (Mac) ... a blank window appears. I suspect 
the same thing happens on Linux. This is not a dialect problem (VID 
or RebGUI) but an issue with REBOL/View AGG font support on non-windows 
platforms.

Also note that while the following works on Windows:


 view center-face make face compose/deep [effect: [draw [font (make 
 face/font [name: "Verdana" size: 18]) text "xxx"]]]


path-qualifying the font name on Mac (and I suspect Linux) still 
does not work:


 view center-face make face compose/deep [effect: [draw [font (make 
 face/font [name: "/Library/Fonts/Verdana" size: 18]) text "xxx"]]]

don't you need to give a file! type for path qualification?

(I can't test it)

string! only ... http://www.rebol.com/docs/view-face-content.html#section-3

did you try adding the file extension to the path qualification on 
osx/linux?

(maybe it doesn't have one and I'm just being annoying  ;-)

Yep, tried that (the 2nd example above should read "/Library/Fonts/Verdana.ttf").

Hmm... I don't recall having font issues with draw on Linux

MaxV, does this work for you ?  http://www.compkarori.com/vanilla/display/AGG

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