World: r3wp

I just wish one thing - things to not add layers of complexity. The 
initial VID work was imo really nice, and I hope it will not complicate 
much ...

Depending on what will be worked on next, we might delve into testing 
schemes. We want the R3 GUI to be easily testable: Fire random events 
at a GUI window and collect errors and crashes and also generally 
record and playback UI events to tell what a user did.

Maybe my fear is preliminary, but it is based upon the doc you created 
... looks like too many things to implement :-)

I volunteer to test, even preliminary versions. It helps me to understand 
gui, to study sources, etc.

btw - is grid system done by Cyphre? He did his own grid, as well 
as RebGUI grid. Hope the design has virtual columns/rows, to stop 
the need to reshape original data source ;-)

we're getting many ideas from the app I'm building now. Automated 
GUI testing is badly needed.

yes, done by him.

And what about menu? How is this being done? I mean - pop-ups? Carl 
still have not expressed, what he had in mind for layers, or did 
he?

OK, so when can we expect "something"? In a month? Later?

That someone is me and in this exact minute I just finished auto-completition 
for the text-list. Yea! :)

cool :-)

Pekr, we're not that far on menus yet. it's just what's planned to 
be done.

I've got basic pop-up working for the drop-down, but it's not finished 
yet.

Complexity: As far as possible, we want to add things in a way so 
you can simply omit them for inclusion when building the GUI. It 
won't be possible for everything, like tags, but testing framework 
would work that way.

welcome Rebolek! :-) You should be put onto Sound, not GUI, no? :-)

later ;)

but if you look at pm-101, I think I can do some GUI work too :)

what is pm-101?

http://www.rebol.org/view-script.r?script=pm-101.r

We are currently checking out how far we can get and what stumbling-blocks 
we might hit to collect some experience.

Goal is to create all internal tools with R3 now (we call them Level-2 
= L2 tools) and build the Level-3 (libs, frameworks, extensions, 
...) in parallel.

Overall we start with the basic concepts we want to have in a GUI 
framework, as we think these needs to be taken into account very 
early. Building up a broad widget-set on a good base shouldn't be 
that hard than.

Is it by any chance planned to add HTML rendering to R3, maybe as 
an extension? (probably not but I'm going to ask anyhow because I'm 
horribly rude) There are some cool apps that mix native GUI widgets 
with HTML content, gitx for example. Would be neat to do this with 
Rebol too. And I'm sure, often enough an app you write is going to 
offer export as HTML, being able to show a preview of the output 
while you are editing the data adds a nice touch to an app.

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 :-)