World: r3wp

I just found Henrik's summary. I think it is the post I had in mind:
---------------------------------------------

Indeed VID3.4 is far from done. You can probably use it for a few 
things, like getting a name from a user in a text field or submit 
a very simple form, but not much more than that. To reiterate the 
state of the UI:

- No unicode yet in graphics (when Cyphre gets around to it).
- Resizing acts like a drunken sailor. (Carl)
- Skin is not published. (Me)
- Style tagging is not implemented. (Carl)
- Reasonable requesters are not yet implemented. (Carl or me)
- Layers are not yet implemented. (Carl)
- Guides are not yet implemented. (Carl)

- Better font rendering. We are not taking advantage of what AGG 
can do. (Cyphre again)
- Event system is from Gabriele's VID3. (Carl)
- Many features are untested, like drag&drop. (Me, I guess)
- Proper material management for skin. (Me).
- Many styles are not implemented, especially lists (Me).
- More elaborate animation engine (Carl or Me).
- Form dialect (Carl talked about this).
- More/better icon artwork (Me).


Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, 
but I don't know if they can be implemented.


The overall design of the GUI engine is very good. Whenever a change 
or addition is made, you alter 3-5 lines of code in one place, and 
it works. I doubt the entire engine will be rewritten.


You won't see GUI bug reports in Curecode for a while. There could 
easily be 2-300 reports, once we get to that point.


My work regarding skins is rather big: I need to work out the basic 
styles first, so we have a reasonable way to build compound styles. 
These are being done using a very simple, but pixel accurate GUI 
using plain colored surfaces. This is easier for testing out, as 
draw blocks are small, but as Pekr likes to complain: They are not 
pretty to look at. Once the real skin goes into place, the draw blocks 
will grow a lot.


I would love to see a low-level GOB management dialect, like Gabriele's 
MakeGOB.

Henrik and BrianH should agree upon what do we mean by "layers", 
as Henrik claims they need to be done, whereas BrianH claims we have 
them already :-)

OK, I was looking for Carl's specs. Those, I didn't find.

And they describe layers in a different way. The layer system may 
already be implemented, but unused.

Can't wait for when we get back to GUI :-) Hopefully Carl is back 
to Host Kit soon, so that View will be adapted to command! interface, 
and its source released, in order for Cyphre to proceed ...

btw - Carl looking for the Viewtop manager - http://www.rebol.com/article/0451.html

I thought he wanted a maintainer of the Viewtop. Oh well.

Did you want to do that?  revise the viewtop sources?

I'm already doing it for the VID Extension Kit.

but only to achieve compatibility, not so much adding new features.

did you get request-file working yet?  :)

No, I'm planning a revamp of requesters, but that lead to working 
on a better implementation of scrollers. I don't like having a whole 
separate context to handle scrolling.

Pekr, sorry, I forgot the name of what you were reqesting that we 
already had. It was frames. Layers are something different - my bad.

yes, frames :-) Btw - how do frames and layers differ? Isn't it identical 
concept, after all?

no, very different concepts. frames were for styles. layers are for 
entire windows.

Pekr, you forgot animated effects on every place of the GUI and 3D 
GUI ;-)

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