World: r3wp

nickA didn't provided a font information in his draw block plus he 
didn't gived a different color... plus R2 VID sux with fonts and 
specially under linux.

I tried Nick code, but I obtain 
** Script Error: style has no value

All my code is:
Rebol []
do %rebgui.r
fnt1: make face/font [ 
		name: "/usr/share/fonts/truetype/freefont/FreeSans.ttf"
		size: 12
		]
example: ['text "Hello word!"]
insert example ( reduce ['font fnt1 ])
display "Example" [
	aaa_stats: box 50x50 effect [  draw example ]
	]
do-events

REBOL/View 2.7.7.4.3 5-Jan-2010


Linux ubuntu 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 
UTC 2010 i686 GNU/Linux

I haven't tried loading fonts in draw on Linux, but the rest of this 
works (the color is changed by the draw command "pen red"):

Rebol []
do %rebgui.r
font1: make face/font [
    ; name: "/usr/share/fonts/truetype/freefont/FreeSans.ttf"
    size: 11
    style: [italic bold]
]
example: compose [
    font (font1)
    pen red
    text "Hello World!"
]
display "Example" [
    style 20x20 data [
        box snow 100x100 effect [
            draw example
        ] 
    ]
]
do-events

** Script Error: style has no value
** Where: layout
** Near: style 20x20 data [
    box snow 100x100 effect [
        draw example
    ]
]

MaxV,  this works perfectly for me on Ubuntu 10.04.1, using your 
rebol.deb installer - I ran Ubuntu directly from the CD created using 
the most recent Ubuntu download, installed REBOL using your Ubuntu 
package, and ran this script.  Perhaps your version of RebGUI is 
different than mine?  This version loads rebgui.r from an http:// 
link:

rebol []
do http://re-bol.com/rebgui.r
font1: make face/font [
    name: "/usr/share/fonts/truetype/freefont/FreeSans.ttf"
    size: 11
    style: [italic bold]
]
example: compose [
    font (font1)
    pen red
    text "Hello World!"
]
display "Example" [
    style 20x20 data [
        box snow 100x100 effect [
            draw example
        ] 
    ]
]
do-events
quit

YES! It's the Rebgui version that is different.

I use Version 218

You use version 117

117 is the latest stable version

Well, 117 has some bugs that 218 hasn't. For example colored buttons 
turn grey after passing over them.

and don't change back?

NO! :-(

note that some view faces support the face/colorS which is a block 
with two colors.


if you only set the face/color, when ever a feel looks up the colors 
block, it will effectively overwrite the color... try it for your 
specific case (I don't use rebgui, so I can't test)

same for face/texts, face/fonts, face/images

That's all VID-specific, NA for RebGUI.

Ashley, given that the last code changes to RebGUi were a year ago 
.. waiting for R3GUI to appear, do you still feel that there is no 
point in improving/fixing RebGUI?

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.