World: r3wp

As for embedding REBOL into WebKit, where would that get us? It's 
not as if other browsers based on WebKit would pick up these changes 
even if we were to submit them to the project.

No, I mean there on users' computers already, in their existing web 
browsers, not in *any* standalone program. Webkit embedded in R3 
would be viewed as a standalone program. R3 embedded in Webkit would 
be viewed as a plugin to a program they already have.

doing REBOL through native client is a different thing though - that's 
worthwhile

WebKit hostted in R# would just be viewed as an additional lib that's 
part of a customized distribution

sorry, r#

jeez, you know what I mean :-)

Don't worry, I wasn't thinking of embedding R3 through anything other 
than browser plugin APIs, or Native Client. There's no point to trying 
to submit it into a particular browser unless it also exists as a 
plugin for other browsers.

sorry but using webkit within REBOL is very usefull.  we can use 
HTML content within our own tools.

hope to have a very rudimentary extension soon

least for Windows

Maxim, I don't doubt that it using Webkit in R3 would be useful. 
But it would be useful for other reasons than providing a GUI for 
R3 (the topic of this group) - more for displaying the GUIs of other 
code within R3, other code (un?)fortunate enough to have been written 
in HTML/CSS/JS.

that's what I mean... but it also means that we could build nice 
web dev tools using R3, which could cross-compile as desktop and 
web apps.

anyhow... I'm still anxious to get next plugin/host.

Small status update:


Working on resizing now, particularly proper pixel accuracy and getting 
rid of all blocks. Ladislav and Cyphre are working on a good algorithm 
here.


This will also create a change in how styles draw gobs: Currently 
a gob defines mostly only the draw area of a face and then spaces 
between gobs are used to create paddings. This is efficient, but 
it makes drawing things outside a button, like blurred shadows very 
difficult. So instead, the gob now constitutes both the drawn button 
and its padding. A side effect is that spacings between gobs are 
now always pixel accurate, because they now rely on the draw block, 
rather than the resizing engine.

A downside is that when you define the style, you also need to define 
a click area, to avoid getting a click registered on a space between 
two buttons. But perhaps this can be automated, don't know yet.


Furthermore, there will be keywords available for DRAW blocks to 
easily locate a corner or a center of the draw block.


Overall, these things will make it much easier to write draw blocks 
for styles.

IT seems god, but in the same time, i'm not sure I like this "clipping 
area" of events thing.

A "silly" idea : could use one gob for the drawing, and another one 
in front of it clipped to the "usable" size for the event tracking 
!?

Cyphre has a good idea on how to do this, and it probably involves 
an extra gob. As a side effect, it might be possible to define a 
bitmap mask to get pixel precision accuracy for click events.

Bitmap mask doesn't require another gob.

ok

globs use several layers, one is for mouse interaction.

globs => you mean in glass ?

yep, the low-level engine over which glass is done.


I was confirming that its a good and simple way to go forward for 
R3 too.

Didier, are you thinking of how QNX Photon worked? I can't remember 
exactly, but that sounds like what it did.

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

Demo of pixel accurate resizing.

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


Same as 210, except border sizes for each individual GOB is randomized.

Randomized to be different, but constant for each rect or to vary 
on the different sides?  It seems to be the latter...

I guess I'm asking if the variance I see on the various sides is 
an artifact of the resizing

the gob size is supposed to be nice like in 210, but the border moves 
in and out randomly per side per gob.

this is what you're working on fixing currently?

Cyphre is working on this, yes.

sorry, I should learn how to read stuff that's been posted already...

A downside is that when you define the style, you also need to define 
a click area, to avoid getting a click registered on a space between 
two buttons.

  ..... I am not sure I can understan, how it is done. Is another gob 
  used to define click-area?. Carl reduced VID to one-style = one-gob, 
  and it was clear it can't work for more complex style, you had to 
  "switch" drawblocks anyway. Now if I understand it correctly, we 
  are back to kind of  "border" aspect of R2? 


I still liked maybe more complex but also more flexible way of Gab's 
VID, where one style was compound of more gobs, if needed ....

you don't need another gob to define click-area. It will be probably 
done using a bitmap mask.

Also you can have more gobs in one style. But you do not need it, 
most of the time.

bitmap mask? Will not it be slow?

Pekr, after working with multiple GOBs for a single face, I think 
it's simply easier to just work with one GOB and a set of draw blocks 
on top of it. Otherwise you get many small parts.

Pekr - why slow?

Well, that might be psychological, but I always hated to work with 
"border" in R2. You have to count it into metrics ..... but maybe 
your model is different, than having border area ... but I can understand, 
that having shadow/glow to UI elements could be troublesome othewise 
...

the box model Cyphre is working on is unlike R2View, it's more similar 
to CSS.

why slow? I don't know. What's the bitmap mask anyway? Some low level 
C function? I thought that putting one transparent gob upon the drawed 
gob could be faster, as event engine simply flows event to particular 
gobs .... (but it would probably cost a memory, because you would 
need two gobs for one style)

re "Box model" ... good to know ...

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.