World: r3wp

For discussion of the R3 GUI (which doesn't have a name yet).

Development status ?

Is the beta release relying on this?

The current non-host-kit builds of R3 can use the current GUI, with 
some bugs. Carl has a new resize model that he hasn't implemented 
yet. The GUI has been put on hold until after the first full R3 release. 
The R3 beta won't support or require a GUI.

non-host-kit builds .. is the standard release?

Yeah, alpha 96 if I recall correctly.

BrianH: there are more changes planned, no? Like adding layers, etc. 
Henrik summed it up somewhere, maybe he can repost. And as far as 
I remember - the changes might influence your code, so I am not sure 
if it is good to do any GUI related work in recent VID state ...

So, it's not at a stage a normal developer can play with ?

normal =  vid user

We have layers now - they're just not called that. The upcoming change 
is the resize model.

I recall you pushing for the inclusion of layers, Pekr, but we already 
had them at the time.

Is there a tutorial on using the ??? gui ?

BrianH: I will not argue, I just don't know ... we need Henrik to 
post conscise list - he has it somewhere. If GUI would be useable, 
Henrik would not stop his work :-)

Top link for R3 Gui is for Syllable!

google link ..

http://www.rebol.net/wiki/R3_GUI

Something will happen here possibly in February to April, but I need 
to finish another project first. Things will be slightly different 
than originally, because I want to take advantage of some techniques 
used in the VID Extension Kit for face navigation, keyboard navigation, 
etc. Not doing work on the GUI has largely been because of announced 
changes not yet implemented, and also having lots of work elsewhere, 
fortunately almost all REBOL related.

Henrik - could you please post those planned features?

Yes... somehow I keep squandering that. Sorry.

hm. I can't find it. Spent the last half hour trying to find it...

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.