World: r3wp

R3 gui is supposed to be easier to code for than VID isn't it ?

yes it is, but you can of course not do so much, when there is only 
a small set of styles available.

I don't know anything about the intricasies of GUI programming ....

Does the text-list use a fixed font style?

No, it uses a standard arial font.

Then I won't need a table yet if the font is fixed pitch

and are face iterators used for text-lists ?

Some things are the same as in R2: You still create layouts with 
a dialect and you still create styles, but style writing is more 
important now, since face hacking like in VID isn't possible anymore.

VID3.4 has no face iterators. Too heavy and unnecessary for GOBs.

Has anyone written any demos apart from "demo" ?

Graham - I think it is preliminary to use VID3.4 productively or 
to extend it. There are planned some design changes to happen ...

I have noticed some instability.  If you halt from a GUI script and 
then try and close it ... r3alpha crashes

Graham, no other demos, but I have a lot of private ones, that only 
work with my styles. You have seen all the screenshots.

How do you see the source for a style?

The resizing and aligning issues makes VID3.4 difficult to use for 
creating decent aligned faces. I would probably wait until that is 
at least fixed.

Graham, all available through R3 chat.

Ok.

so a text-list is now called a "style" ?

#2686 and "get lists.r"

Hmm.. no messages in GUI in R3 chat for this year

they are all styles

How do I download all the files I see with 'ls ?

get *

thnx

So, I guess I need to wait a couple of months ....

yes, probably a good idea

Yes, the result of constant "topic jumping" during the development 
:-)

Sigh ...

I presume I can change the font used to a monospaced font ...

you can, if you can find where the font specification is used in 
the list, but you want to create a new style that uses that font.

noob question ....  how can I define a function that accesses a field 
before the layout is created?

I used to use 

l: layout [ f: field ]

and then write my function access f after the layout was created.

Now we have 

view [ layout block ]
...

My first gui script http://rebol.wik.is/Rebol3/R3_GUI/Sendfax.r


I'd like to have the output from net-log appearing in the area .. 
but I can only get it do that once  and then nothing ...

oh .. and the fax was successfully sent :)

control-C to try and copy text in an error causes the console to 
crash

in an area causes console to crash

I wrote this to try and update the area with network trace

			set 'net-log funct [  txt /c /s][
				data: rejoin [ get-face a1 newline txt ]
				if c [ data: join "c: " data ]
				if s [ data: join "s: " data ]
				set-face a1 data
				set-face/field a1 tail get-face a1 'locate 
				wait .1 ; update gui
				txt
			]

but it doesn't work because get-face is async
so I need some callback instead ...

so my area ends up with a row of 

c: s: c: ....
before any real text appears

Could Open Web Font Format be of any use for us, to solve our font 
problems?

http://hacks.mozilla.org/2009/10/woff/

Do we have font problems in R3?

yes, we can't use some techniques as Hinting, no? I thought that 
some open-source cross-platform aproach might cure the situation 
...

I would assume that would simply be an extension of the rich text 
dialect and exposing more options from the AGG font renderer:

[hint 1 "abc" hint 0.8 "def" hint 2 "ghi"]

We are using hinting. But on platforms where FreeType2 lib is used 
the hinting results can be not nice. This is because it depends how 
FreeType lib is compiled (either with the Apple hinter, or with the 
free non-commercialy licenced alternative)

Henrik, yes HINT x y keyword can be added to the dialect. But IMO 
this can be useful only in case you have own vector glyphs and own 
simple font engine. For example the TrueType hinter is kind of language 
for itself so it can be pretty complex.

Hints should be built-in in font definitions (ie hint table or kerning 
pairs table) what Henrik sugest seems to me like kerning information. 
Hints should be active when rendering to "low" resolutions happens, 
acording to standards I've read long, long ago.

Sorry, I was mistaking kerning with hinting.

Hinting should make all rounding to be the sam at distinct resolution, 
ie it solves recomputation vrom vector information (float) to integer 
screen information, trying to make all significant sizes the sam 
at some distinct resolution.

appologize for writing errors

hinting is also important in general in DRAW