World: r3wp

Animated effects..  How about nice helper ... Like dog or perhaps 
a friendly Paperlip? :)

I realize the GUI is still a WIP ... but is the underlying [native] 
gob! system settled? (i.e. is it likely that the details of http://www.rebol.net/wiki/GOB
will change?).

not sure there will be many changes to it, only bug fixes.

Good. That means the building blocks are in place for those who want 
to experiment with Gob-based GUI's ;)

Ah, Ashley and RebGUI 3.0 :-)

gob system might change, but only as an experiment by Max. He wants 
some class-like  based system, where gob will have fields upon the 
class. Not hard-coded for text, color, draw, etc.

The way I see it, there are at least four ways to build an R3 GUI 
[based on gobs]:


1) Heirarchical, where gobs are grouped into faces, which are in 
turn grouped into windows

2) Flat, where a DOM-like object maps all gobs (i.e. removes the 
need for intermediate faces/windows)

3) Draw-based, where each window consists of a single gob with the 
entire window rendered in a draw block

4) Image-based, similar, but the draw block is pre-rendered into 
an image.

5) Depending on exactly how rich rich-text is, a window could also 
consist of one Gob with all elements rendered in rich text (think 
HTML page/elements)

we shouldn't forget MakeGOB, even if it may not be useful for complex 
GUIs, it can be used for managing GOBs easier.

I can post what Max said about his problem with gobs and draw in 
the past ...

I digged following from Max in the past:
---------------------------------

My pet peeve about R3 view is that we still don't have access to 
the actual AGG elements directly within rebol.

We still have to go through a clumsy interface called draw dialect.

The dialect is fine (great actually) for initialisation, but after 
that, its not adapted to actual manipulation of what is going on 
inside, you have to go trough a rebol -> agg convertion stage at 
each refresh.

It's not the speed, it's the fact that it's complicated cause you 
have to create "virtual" draw components and then assemble them on 
the fly reducing blocks and stuff.
I'd love to be able to do:

a: draw [circle 30x30 15]
a/radius: 30
a/offset: 100x100
show a


If graphic elements where first class datatypes, we could completely 
ignore the gobs, and build real canvases, uber fast.

Another example, more appropriate:

; this draws a box...
draw [s: polygon 10x10  30x10 30x-30 10x-30]

; make it a house outline
insert at s/vertices 4 20x-40

; raise the "roof" 
s/vertices/4/y: -50


The problem is that to edit draw blocks, you have to create a slew 
of things before creating the draw block, then you have to store 
references to all of those things somewhere, everytime you want to 
add a "dynamic" attribute its pretty tedious.

The first-class gel datatype would allow AGG to edit its internals 
directly using binary C code through its accessors.  no need to go 
through rebol funcs and reducing blocks, etc.

The use of  "show a" above could intrinsincally know that it only 
needs to refresh the region that this element affects, just like 
all graphic cards do when evaluating the graphic pipe rendering.

So many things like flash games which become soooo heavy in AGG would 
be real-time and use much less CPU resouces.  in most games only 
a small part of the canvas really changes interactively.

That's for the smarts to consider ... I don't properly understand, 
if he is right, or not ...

If Max is right, we should trash gobs :-)

no, that doesn't have anything to do with GOBs. those are problems 
with DRAW. GOBs are about as small and lightweight as they can be. 
How they are used by the system is a different matter.

He's right. While:

	g: make gob! [draw: [pen red line 10x10 20x20]]
	g/draw/pen: blue
	view g


is fine for small draw blocks, it's a pain for example setting the 
2nd pen to a different color ... or moving a logical group of draw 
operations around. In reality you are quite often forced to dynamically 
regenerate draw blocks each time ... which forces you to split big 
draw blocks up into discrete gobs (e.g. one gob to draw a blue circle, 
another a red box, etc). This is an issue with draw not gobs (which 
have been very well designed IMHO).

Max continuead a bit:
----------------------

part of what I want to attempt for my host code work is to implement 
liquid and globs natively in R3.  with access to AGG I could build 
the single most powerfull canvas engine in any language...


 we'd have absolutely nothing to envy to ANY other language, not even 
 Apple's engine... as long as the AGG can render a few more things 
 and add filters to AGG strokes.


globs use AGG and allow events to be sent to individual AGG strokes. 
 so you can "slide" a single line by clicking on it. the cool thing 
is that the input mask and display are separate... and you can implement 
any number of layers per display element that you want.

The nice thing is, that all View code is going to be part of Host 
Kit, once View moves over to command! interfacing. So anyone experienced 
can experiment ...

I agree with Max on this. Hopefully he'll get to start on those changes 
soon along with Cyphre.

Yes, we want REBOL being an ultimate media engine :-) Do you remember 
Carl stating Multimedia is his second name? One point at the time 
we were even teased with REBOL/Media :-)

lava !

Getting a window plus event handler up and running only using View 
(no load-gui) is pretty simple. The code, for those interested, is:

	system/view/event-port: open [scheme: 'event]

 system/view/event-port/awake: make function! [[event][print event/type]]
	f: make system/standard/font [size: 36]

 d: make gob! [text: "Title" offset: 50x50 size: 300x200 flags: [resize]]
	append d make gob! [text: [font f "Text"]]
	append system/view/screen-gob d
	show system/view/screen-gob
	wait system/view/event-port

here is another version (more abstracted):

win: make gob! [
	size: 300x300
    draw: [
        fill-pen blue
        box 5x5 90x90
    ]
]

init-view-system

view/options win [
	title: "test"
	offset: 'center
	handler: [
		name: 'my-handler
		priority: 100
		handler: func [event] [
			if event/type = 'close [

    unhandle-events self ; Remove this handler from the global list.
				unview event/window
				quit
			]
			none
		]
	]
]

What sort of widgets do we actually have so far in the GUI ?

Is there a list somewhere?

cool... .. type "demo"

Is the way the panels are redrawn visibly a special effect ? Or something 
else?

The alerts don't focus on the "OK" so that you can use the space 
bar to dismiss them.

graham, if you have an account to the r3-gui world, there is a list 
in there

But... the list is likely to change. I hope some of my ideas will 
be added.

Henrik ... I don't

I'd like to start writing some test scripts .. but need a table widget/face/whatever 
...

Also a tabbed panel ...

there's only a single column list available at this time.

no tabbed panels either

R3 gui is supposed to be easier to code for than VID isn't it ?

yes it is, but you can of course not do so much, when there is only 
a small set of styles available.

I don't know anything about the intricasies of GUI programming ....

Does the text-list use a fixed font style?

No, it uses a standard arial font.

Then I won't need a table yet if the font is fixed pitch

and are face iterators used for text-lists ?

Some things are the same as in R2: You still create layouts with 
a dialect and you still create styles, but style writing is more 
important now, since face hacking like in VID isn't possible anymore.

VID3.4 has no face iterators. Too heavy and unnecessary for GOBs.

Has anyone written any demos apart from "demo" ?

Graham - I think it is preliminary to use VID3.4 productively or 
to extend it. There are planned some design changes to happen ...

I have noticed some instability.  If you halt from a GUI script and 
then try and close it ... r3alpha crashes

Graham, no other demos, but I have a lot of private ones, that only 
work with my styles. You have seen all the screenshots.

How do you see the source for a style?

The resizing and aligning issues makes VID3.4 difficult to use for 
creating decent aligned faces. I would probably wait until that is 
at least fixed.

Graham, all available through R3 chat.