World: r3wp

You render all visible faces to a bitmap. Each face has different 
color. The you just read mouse coordinates and do a PICK on the bitmap. 
That way you know exactly where the event should end. That's the 
bitmap mask.

a bitmap mask has the advantage that we can define any shape, even 
counting in anti-aliasing for clickable area.

Thanks for explanation, Bolek, looks easy :-) The only thing I can't 
techically imagine is "you render" .... is it special added operation, 
or you just use already-somewhere-in-memory-rendered area?

hmm, those are low level changes, so Cyphre is doing it his own code 
branch, or does he have code synced with Carl?

sorry for so many questions ... I am just interested :-) I hope more 
guys gets interested too, and even join the testing phase and style 
creation process :-)

btw - what is the situation/plan with fonts? Initial (recent) VID3 
(View) font rendering was not sometimes too pleasant. Was it due 
to not so precise font metrics 'tex-size calculations, or was it 
due to not being able to use more advanced (licensed/patented) techniques? 
Is there any way of how to resolve this issue?

render - well, there are different ways to do it, you must ask Cyphre 
how exactly he's going to it.

Pekr, there are still options in the font rendering engine not exposed 
in DRAW. we need the host kit for that.

What is most important is, that we haven't hit a showstopper yet. 
Even with the current release we can move along. It might not be 
perfect in all aspects but good enough and comparted to R2 base not 
worse. That's enough to do it and get some apps done with R3.

Pekr, re font rendering improvements....have a look at this famous 
article: http://antigrain.com/research/font_rasterization/index.html#FONT_RASTERIZATION

Mcseem describes possible way we could try in R3 version but it would 
need some more expereiments.

that's a very nice summary of various font issues.

(regardless of AGG)

Henrik - any new screenshots to R3 GUI in the pipeline? :-)

Also - with the change to the "box model" and introduction of "material" 
system, will it be any easier to adapt the overall GUI look?

Not yet. Carl has entered the resizing discussion and there is not 
yet an outcome.

Materials system is being reviewed by Bolek. May need some changes.

Resize system has been worked intensely on by Ladislav and Cyphre 
for the past few days.

hmm, it seems like Carl is finally cooperating even in the GUI area? 
:-) So, is he liking new RebGUI like resizing model, or not? :-) 
I remember even some discussions in the past, and Carl had his own 
opinion on that. I hope that max-size need is eliminated ... or still 
it is not? :-)

From my perpsective it is easy - we need resizing system, which just 
works. With RebGUI, I still had some issues even with simple GUIs 
....

I've not read the discussion yet.

I expect your world being private one right? No web-public output 
at least, so that we can at least passively read some discussions, 
and kind of "influence" it from here? :-)

yes, it's private

I consider bitmap mask as the  way how to detect click in non rectangular 
areas. It's probably how Flash does it as well. You cannot use alfa 
channel because in many cases you need transparent buttons.

The missing word in my sentence above is "best" - but how I think 
about it, the alpha channel could be used as well if there was some 
flag which would inform the engine, that it should not render the 
gob, but still use it to receive events.

Using the alpha channel with the visibility flag would save some 
memory in many cases.

using alpha would limit you to only 255 controls.

Bitmask or alpha channal would only be used where non-rectangluar 
areas need to be clickable, so that, Maxim, means they are handled 
on a per GOB or per-Style base, giving 255 controls per GOB or Style, 
not in total, at least that's my understanding.

ah ok, that makes sense, but then you are limited in that each gob 
has to fit within a rectangular area, and do 2 checks.  first on 
the area then on the mask.

Yes, point taken, but I don't expect those double check to be a big 
performance burden. First, it's still fast, and second, it probably 
is reserved for special needs only. Not every button with e.g. rounded 
borders needs to be detectable on a per pixel basis, often a rectangular 
region would suffix in most cases, I guess.

No it won`t be a performance problem for sure.

resizing: no, Carl does not like RebGUI resizing model, nor some 
look-alikes. Neither do I. That is why Cyphre and I had to try two 
distinct prototypes not being fully content with any of them (the 
second one being able to deliver some nice pictures already). Tomorrow, 
it is time to try yet another resizing model, this time adhering 
to Carl's original idea more, than his own implementation, so the 
system is going to be quite advanced (it took a lot of time to fine-tune 
some algorithm details, we almost gave up).

Wow, if you and Cyphre almost gave up...

Will there be a way to swap languages in the GUI?

if you can reference strings from outside the GUI, that shouldn't 
be a problem to do on your own. I don't find it generally to be a 
good idea to provide language support inside a GUI engine.

Gregg, solution was found and we should soon have a prototype.

@Gregg:  when I imagine Ladislav and Cyphre working like that on 
code, I picture a slow motion movie scene with epic music  thumping 
in the background, lots of dramatic cuts between close up face shots, 
etc...

Resizing prototype working well, both Cyphre and I like it.

... and the glorious slow motion victory scene with fists pumping 
in the air  :)

:-)

... and the crowd cheering :)

Yes, it's nice. I would print the demos in 1mx1m and present them 
in gallery. Piet Mondrian would be proud.

Works well and is pixel precise.

screenshots coming soon

Cool, because I did not like RebGUI resizing either, dunno why. Maybe 
because I was not getting what I exptected ...

again 2 weeks :-(

Good, because I've been waiting for the R3 GUI resizing model to 
be finalized before I retrofit the R2 VID resizing patch with its 
algorithm.

Claude - what two weeks?

carl say => With the above renewed effort on the GUI, the priority 
of moving the graphics library to the Host-Kit has jumped up a few 
notches. This is a non-trivial project; however, the next sprint 
is expected to arrive in two weeks

http://www.rebol.com/roadmap.html

perhaps more ;-)