World: r3wp

I agree with the headache brought on by the pieces you mentioned, 
but how to get people to transition unless you make it easy for them 
to do so?

I suppose that in an environment like Android, REBOL apps could have 
equal opportunity to HTML5 apps - so the best tech should win.

actually, I find the AS noticeably better.  the steps are pretty 
much invisible even on almost horizontal/vertical lines.

I'm sure the font rendering would be much more stable if this AA 
were used.

Yeah, I find significant difference in the almost vert/horizontal 
lines too, but I guess it's subjective - lots of people tend not 
to notice all kinds of artifacts in graphics, some of which drive 
me crazy.

very thin lines also keep much more of their color , instead of blending, 
which is why I think this AA would make a big difference in font 
rendering.

Maxim: yes the steps aren't visible too much...it looked too blury 
to me but it can be because of the LCD I'm using now.

Subjectivity: yeah, just check some forums about image/gfx filtering..lot 
of flame wars :)

we don't notice detail as much in image drawing, but in graphics 
and slow moving pictures, AA is a killer

in GLASS I had to take AA off in some text sizes for the font I am 
using.   some letters looked bold and some didn't.  On some letters 
with round corders (like S, g, D) the AA changes the width of the 
line so much its annoying to read.

font rendering: this is separate chapter imo..it would be great if 
this algorithm looks as good on text as on the images drawings.

corders=corners

The issue with AGG font rendering is that we are not using the 'clear 
type' like techinque yet. It would look much better even with current 
AA. I believe it will be part of R3 once HostKit is avaliable.

isn't cleartype patented and illegal to use in USA unless we have 
a license from MS?

on the other hand, if the hostkit allows us to use system font rendering 
routines, then all the font issues will be solved.

dunno, but what McSeem did is not exact cleartype clone iirc.

AdrianS: I don't think you can convert the Web people to Rebol easily 
just by replacing the JS in a browser. Better to build some 'cool' 
product based on Rebol with modular interface so people can play 
with it and build own 'gadgets' using dialects etc. I believe there 
are still some 'oportunities' to do it on misc embedded systems but 
first you need HostKit source and fully abstracted Rebol dll versions 
compiled for such systems.

the main feature of REBOL today when comparing to web, today, is 
the  "one language for everything" aspect of it.

people are also impressed when I build a parse dialect in ten lines 
in 5 minutes and show them that its actually spitting new structured 
data out of other data.

Building a new visual dialect from scratch in twenty lines also blows 
them away.

Let me refine what I said earlier - the idea would be to use some 
dialect that would create all the necessary bits using REBOL (JS, 
CSS, DOM elements) to be rendered by the embedded WebKit renderer. 
If, at the same time, people could run 'standard' HTML5 code in this 
same container (with integration to the hosting REBOL runtime), the 
whole would still be perceived as one integrated environment with 
HTML5 possibly being simplified into REBOL over time.

just having a webkit plugin will allow us a lot of new possibilities.

Max, could Liquid/GLASS code be translated to HTML5 without huge 
amounts of pain?

I don't mean the actual framework code, but the code that defines 
the UI and interaction for a specific application.

don't know.  I think it would require me to port liquid to JS in 
the least.

Remark is my solution for web stuff..  its basically what you describe 
above.   One engine to manage all aspects of a web application.  
Using rebol dialects compiled in real-time, you can build any data. 
 but the Dialects can be embeded within any other file, using a twist 
on the html friendly <tag> notation.

I haven't pinned the "web application" portion of it, but all the 
file building & serving aspects can already be used with remark.

building a layout dialect for Remark which is compatible to GLASS/VID 
3 is pretty easy.  its my next main Remark project.

(AFTER I've released all my stuff ;-)

when we'll have a webkit REBOL plugin, then I (and hopefull others) 
will be able to do a real-time web dev software using the remark 
framework.

I wonder what's involved in hosting WebKit - pulling down the source 
now

Looks like it's been discussed over the years, but I don't see that 
anything significant has been done, by googling.

when I went to the webkit site is was severely under-documented.

it might actually be easier to look at the chrome source code and 
starting from there!

yeah - the embedding API docs are not there at all

Adobe Flex 4 ActionScript 3 wraps WebKit, right?

a good list here:

http://trac.webkit.org/wiki/Applicationsusing WebKit

Hosting Webkit wouldn't help here: The whole point to HTML5 etc. 
acceptance is that people don't have to install another program - 
they can just use their existing web browser. Hosting Webkit would 
only help us if we want to display existing web browser code; it 
wouldn't be necessary for generating code to run in Webkit, because 
the copy of Webkit that people would be displaying your GUI in would 
usually be a separate program, often on a separate computer. And 
HTML/JS/CSS is just text - we can generate text already.

plug-in still might be the way to go. Google is introducing native 
extensions too ...

Native Client would be an interesting way to get REBOL into a browser, 
particularly once they get the portable version up and running :)

Brian, my point with the embedded WebKit would be to have an alternative 
gui framework that has the capabilities people are used to from a 
browser. With a non-hosted WebKit (or any old browser), you couldn't 
have very close integration with the REBOL runtime.

in-browser use of REBOL is a different thing - for sure more useful 
in the longer term, but what can be done today?

Embedding REBOL *in* Webkit would work well. The other way around 
wouldn't help as much, because we'd be stuck with the browser GUI 
model when we don't have to be. People don't use the HTML/CSS/JS 
model because it's good (it's not), they use it because it's there 
already.

exactly - it's there right now, as opposed to VID 3.4 which is only 
going to be fully available some time from now (in a more polished 
form)

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.