World: r3wp

it's probably possible to show a webkit renderer or something through 
some kind of a view-port.

WebKit would be perfect :)

might make for a good initial demo

the question is, how complex the webkit api is to wrap. IIRC, it 
was kind of difficult to get Mozilla's kernel wrapped (maybe this 
why everybody seems to use Webkit for such purposes nowadays :-)

I studied KHTML back when I thought we were going to build a new 
AWeb around it. it was incredibly much simpler than Gecko at the 
time. Don't know about webkit, though.

Isn't Webkit just a descendant of KHTML?

yes, but it has developed quite a bit since the fork

Once the graphics code has been moved into the host, it would in 
theory be possible to make a new gob! type that embeds webkit. At 
least that is the kind of thing that the gob! system is supposed 
to be designed for. We'll see :)

I tried to look at webkit and its pretty daunting.  the api also 
isn't documented at all...

I wanted to sarcastically write that it's probably documented in 
small tidbits on one of the commiters' blogs but then I checked and 
that's really where some of the docs are.

With recent alphas, Is there a way to run GUI scripts with no console 
window open? I guess not ...

it could probably be worked out with a small patch to the host-kit. 
 but we might be asking for crashes if any call to print is done.

python has a non console mode binary and it crashes if any stray 
print is performed...

Is the REBOL2 behaviour a possibility, delaying opening of the console 
window until the first print is performed?

(Something like that seems to be what R2 does. Probably just not 
implemented yet.)


Would have nicely reduced window clutter in a client app, these console 
windows scare users to no end ...

in R2, the console is a window that is controled by the application. 
 in R3, for now, the console is controled by the OS.


Windows does not allow an application to be either a windows app 
or a console app.

a future version of R3 will probably manage its own console like 
in R2.

Ah, yes, that's the reason. So, no way around that for now, no big 
deal.

its a stupid windows limitation which goes back to windows 1.0, if 
you can imagine that!

Not sure we can make a discussion out of it, so I'm posting here: 
How closely related would AGG/Draw be with HTML5 canvas?

dunno about HTML5 Canvas, but browsers contain SVG, and there were 
some attempts to do REBOL-2-SVG converters. There was some incompatibility 
in how gradients are specified, but that could be added to our kernel. 
I am sure Cyphre has more to say here ...

R3 is alpha, so the console window !

Any news from our fellow GUI team? :-)

I'm having a cup of coffee. :-)

I prefer tea :) Also right now I'm investigating password style and 
then will move to tabs.

:-)

I have a coffee too, although I prefer the tea ... well, quite an 
oxymoron :-)

... we need ... screenshots :-)

Henrik - is there any resolution to resizing system? I know that 
we both objected to max-size element for e.g., and IIRC there were 
some proposals of how to either fix current model, or replace it 
with different one. Have you made any decisions in that regard yet?

no, no resolution yet.

didec windows console is boring and ugly now that i show agg could 
deal  pretty stuffs with text in color why don't we HTMLize our console 
and bring some new way to experience console direct code flow coding 
cause that was the strong point of R2 and that's the actual weak 
point of r3

if you look at the ruby console it's already mixed with an help  
browser

we could do something with our rebol consol gathering all the pasr 
years accululatedexperiences

accumulated sorry

a console with color syntaxe to locate the kind of state the console 
is in or the kind of field we are calling the rebol words , this 
console could be merged or embeded with dynamic a

help or a way to start step by step evaluation or stop it   and a 
way to look at your data stacks or organisation like in anamonitor 
.. this advanced  console then  could be done in view dialect and 
be a show room to the view dialect capabilities

i'm for modular tweakable devtools

all those years i sharpen my own way  to code in rebol in a more 
professional way ... and that was done basing my self  on the few 
spare tools the rebolers bring  but it would be nice to have this 
effort through years continuated to show that the rought aspect of 
rebol evolved alot ans that now all you really need to do rebol is 
rebol and i think we all shown that in rebol light weight wasn't 
synonimous of  poor ideas oe small capabilities*

one of my dream regarding the developement of applications in rebol 
was to have a way to select a bunch of your code in your text editor 
and hit run by step  to see a step by step excution of that bunch 
of code  in  order to underfstand what rebol is doing closely when 
he clone data  h

or when he manage pointers

personaly one of the hardest part in rebol is the memory management 
and maybe that's part of the reason i don't understand the way parse 
works

Pekr about you gui library 2 comments yes it has all the widgets 
i expect and so much blue are you sure ?

gram for tab panels they shopuld be able to stick together in line 
when needed and show one content at a time  and able to be extracted 
from the line to exists in their own lonely window like it's done 
in most of webbrowser now inh days

Shadwold - I don't understand what are you asking, but if you are 
asking if I like mild bleu gui, then I have to say - yes. I am bored 
by old Amiga and NeXTStep grey look - Fedora, Vista, Windows 7, FaceBook 
login-page, all got it right ...

From rm-asset.com website - "# R3-GUI Library: Our internal extended 
and enhanced VID. We add a persistent layer so that GUI elements 
can be stored into a database backend. Further we added element-tree 
traversal code to simplify accessing GUI elements. Beside this we 
develop a bunch of GUI styles like TABLE, DROP-LIST, DROP-TREE etc." 


What's persistent state for GUI good for? And also - why the element 
traversal code, if we can use path in gobs and their "panes"?

Pekr, you need traversal code to move back and forth relatively in 
the tree.

Otherwise you can't do things like tab navigation.

persistent: If you want to store a form you need to get the relevant 
information from your styles. For example: which ID was selected 
in a drop-down box, sort-order of tables etc.

We want to be able to automaticall store all this run-time state 
information with one call.

isn't it a bit of an overhead for a GUI itself? I mean - those are 
application (higher) level issues, although usefull ...