World: r3wp

bricolage another french word ... well who cares...

So, if you created a rendering surface or whatever in Cairo, can 
you then ask another Rebol process to access it?

the real true ask is rebol is slow to evolve so does cairo will evolve 
betwin 2 rebol release or does it will go to abandonedwar after 2 
years  ?

graham i fear the context concept is like the flash plugin in your 
page ... you see what i mean

so the memory is protected from access by other processes?

you have a specific area where you have your flash rendering embeded 
more or less into a  visual content rendered using a completly different 
engine and drawing method

end  betwing those 2 engines no coabitation the flash space is for 
flash only

and that's more or less the phylosophy that doesn't feat rebol ...

Doesn't the graphics library access the multi-cored gpu?

was i more clear with that example (taht's the way GTK+ and QT link 
with opengl you have a specific squared area to clip your opengl 
rendering in  but  it's not mixed content

Graham in recent video card the GDI stack is not the most optimised 

they pushed walls to allow new things like the blu ray decoding to 
have a room and that have obviously an impact on the previous guys 
there and DX11 ...MicroSoft tod the whole word that GDI rendering 
was dead and that the only thing that matters was DX 11 rendering 
even for their widgets and desktop everyday rendering (aero)

let imagine you do a button you want to draw something on the background 
with AGG and then have the regular button borders and fonts to be 
applyed over  using AGG it's possible to have that effect  with the 
context phylosophy the VID button is a separated entity from the 
agg entity  you have the QT context the QT widgets display in it 
and the AGG widget is one of the few widgets you have but you can't 
mixe content ...

I imagine we could have multiple graphics libraries loaded at the 
same time ...

So, one could use AGG for somethings like a GUI and then use Cairo 
for display postscript

yeah ... but cairo doesn't seems bad at all

Ultimately it will depend on whoever does these things :)

don't look at me that way ....

Which library best supports rich text in an area field?

i would say  cairo isn't bad

hum cairo glyph api is linked to pango ?

depend the quality speed dans complexity of the rendering you want 
in fact

text is  a pain to handle that's why pango was created to serv the 
gilmp tool kit (GTK)

Function overloading (having a several variants of a function with 
the same name and different arguments) is a language feature available 
in many languages but not in C.

like for example in rebol :)

My status: Currently testing the dialog system prototype. This is 
ported from the VID Extension Kit and should allow for a large number 
of different dialogs. Still some work left to do, but have some basics 
working.

http://rebol.hmkdesign.dk/files/r3/gui/228.png


This odd looking dialog marks a few milestones from two days of work:


- Successfully create and open an email dialog created from a single 
style, which represents the content area.

- Successfully validate the content area from the validation information 
stored in the style.

- Successfully display validation result in the content area (the 
letters to the right of the fields show INVALID)

- Successfully block closing it, when it's not correctly filled, 
when clicking "Send" using a new DISMISS reactor.

- Successfully store the content in a way so that it can be returned 
in an object, when the dialog is finished or store a NONE/FALSE when 
cancelled.


The dialog is called by: REQUEST-EMAIL. It doesn't send any email, 
that comes later. The reason it looks odd is because the new resizing 
scheme requires some changes in how sizes are handled in styles and 
I haven't quite figured out how to change them yet.


We'll probably need some more prototypes, but all in all, this is 
a fairly good method of creating complete-featured dialogs quickly.

Isn't it just simpler to introduce a new type ... fpair for floating 
point par

I thought we were going to be allowed to add our own types eventually

Yes, but none of those types would have literal syntax.

And an fpair type would add a syntax ambiguity if we kept the integer 
pair type.

Is this page deprecated? http://www.rebol.com/r3/docs/gui/reactors.html

My older r3 builds don't recognize 'make-reactor

I get an error message ....

it doesn't exist. the function is called MAKE-FACE-ACTION.

oops, MAKE-FACE-ACTIONS

>> load-gui
Fetching GUI...
GUI Version: 0.2.1
(Developer test GUI theme)
== 0.2.1

>> make-reactor
** Script error: make-reactor has no value

correct

Hmm... tricky when the docs are out of date.   Says March 2010 too

I don't think it's particularly out of date. I think the function 
name never existed. I've never seen that function name before.

Looks like we need to create our alternate set of documentation

I don't think so... just need a few bits to be updated. The rest 
should fit.

besides, there will be a rather large extension to the GUI soon. 
it's not a good idea to work on docs now.

Committed first form validation prototype and docs for it. That should 
be enough for today. :-)

What's the current completion status?

Or has the new hostkit caused work to restart on the primitives again?

we are basically working from both ends. my work and Boleks, regarding 
styles are not affected by the host kit.

there are many new systems to add so we are not near completion yet.

G, H: MAKE-FACE-ACTION is supposed to be renamed accordingly to MAKE-REACTOR.

That is, the doc is a spec, which hasn't been reflected in code yet.

The lower-level graphics changes from host-kit and pair decimals 
will disrupt only the compositing layer of the GUI. The rest is as 
Henrik noted, unchanged.

Just a quick question to further my understanding: is the Saphirion 
NLPP/Cost Analysis stuff already R3-based, or what GUI framwork is 
used for the Saphirion apps? (Henrik? Robert?)