World: r3wp

most flexible option is the preferred for me

Close the topic, Cyphre - your conclusion seems about to be right 
.....

I'm late and give my vote to #2.

Why ? because I think it's the easiest way to assemble components 
containing several gobs acting together.

easiest way meaning: less code

On the contrary of what other believe, I tink the most common case, 
is to propagate events

I take one example:

If I create one button style with only one gob and then I decide 
to add an inner gob to change its aspect.
I don't want to have to change some code just because of that.
Gob's compositing  should be the easiest as possible

If there is design tension between what is easier for the style developer 
versus the style user, my vote is to favor the style user because 
styles are used far more often than they are built.

It's a good point though Steeve.

Any news from RMA guys? Not trying to push for anything, just curious 
about the progress of the GUI implementation. Acutally I do remember 
you stating you are taking longer time before there is next relase. 
So how things go?

Quite good. We did some major re-factoring and are currently getting 
automatic GUI testing done. We need this for several reasons:
1. Automatic style lib testing
2. Applicaiton testing

This is a major step as it will reduce our hours to do these tasks. 
Testability must be designed in right from the start and it will 
save thousands of hours of effort later.

Sounds very encouraging Robert.

As for the "event bubbling", I too agree, that Steeve has some merit 
here, although I voted differently :-(

Robert - interesting. How goes redesign of "vid level" actions/reactions?

This is already done.

Thanks for the report Robert!

A post to keep you informed about what the ELICA LOGO can do relative 
to 3D graphics, animation an GUI (under windows only) - all their 
libraries are open source and I thought you would like to know about 
- see the link in the OPEN GL group. Hope it can be useful in some 
way or another. Regards, Gerard

Thery are also developing a compatibler ELICA LOGO compiler called 
Lhogho. refs are also included.

Has there been any recent releases here?

Still into deep rewrites.

The current overview of all styles:

http://rebol.hmkdesign.dk/files/r3/gui/253.png

Some more images here:

http://rebol.hmkdesign.dk/files/r3/gui/

A bit of status:


- Cyphre has recently fixed a bug in the hostkit with the display 
of some unicode characters. Will see if there can be a release.

- Cyphre has been working on fixing various low level issues in the 
R3 GUI source

- Cyphre is working on testing scheme for GUI and some documentation

- Bolek is working on styles and a TODO test application, called 
"Notation" for Robert

- We still need Carl to fix one particular bug, which is prevents 
creating complex layouts

Thanks a lot for an update, both Robert and Henrik. It is encouraging 
to see some activity. As I personally offered to Rebolek - I can 
make some quick testing/private reporting, so if you can prepare 
some interim release, I am interested. But - I can wait for the official 
one.

btw - what's the bug preventing to create larger layouts?

it's the old assertion failure

actually it doesn't have to be particuarly large, but there are some 
specific triggers, like this one:


view [tab-box ["tab1" [] "tab2" [] "tab3" [] "tab4" [] "tab5" []]]

Thanks for the update Henrik!

how powerfull is a table style? I expect it not being full grid capable, 
as Cyphre did in the past, however what's the basic functionality 
to expect?


- column sorting - two state, or three state? (I don't like when 
I can't get back the original sorting = unsorted), but that's just 
my point-of-view, and not importan feature initially
- column filtering like in MS Excel
- how much data the table handles?

I am referring to: http://rebol.hmkdesign.dk/files/r3/gui/255.png

- hmm, no horizontal scrolling?

column sorting: three state.
column filtering: yes.

how much data: lots of. In normal mode you're limited by memory, 
in DB mode you're limited by your DB system.

horizontal scrolling: not yet, but can be easily implemented (you 
can already select which columns to display).

interesting, thanks ...

btw - do you work with the db/query-obtained data block "as-is", 
just selecting which column to display at what position, or do you 
have to pre-build/modify your data first to be displayed?

It queries db on table refresh for visible rows.

DB mode? That's exciting news. Thanks Rebolek for the update and 
Pekr for asking.

Simple demo of automated testing:

http://rebol.hmkdesign.dk/files/r3/gui/010.mov

Very nice

Most excellent Henrick (and RMA).

That's impressive Henirk

Thanks Henrik. I'm curious if you have found things that didn't work 
using these methods.

Perhaps that's a question for Cyphre?

James, I wrote first round of basic tests for some styles and so 
far this method works well. I haven't tested recording of realtime 
resizing and dragging so far but I'm sure if there are any issues 
they'll be fixed along the way. Otherwise this method doesn't cover 
only recording of user input, but it is possible to insert 'checkpoints' 
with REBOL like code to check specific conditions during the testing 
sequence. Cmobination of both makes this testing subsystem very flexible 
and relatively easy to use.

We are currently discussion an option how to write GUI dialects. 
The thing is how to access face stuff. At the moment you write it 
like this: get-face/field my-table [cell 2x3]

Whereas I like path notation more: my-table/cell/2x3


Using path notaion is not possible but we could enhance the dialect 
in a way that: "get-face my-table/cell/2x3" would be converted internally 
to: get-face/field my-table [cell 2x3]


So, what do you think? I'm not sure if supporting the path notationis 
worth the effort.

I like path notation better, too

How one distinguis obfuscated path notation from the real one? I 
have headache because of path notation usage from VID2, where one 
could cause "unexpected" changes :-)

We found a way to support both without big effort. The non path version 
is better if things are script generated.

And, there won't be any changes. It's just to access stuff in a face.

Thanks Cyphre for the explanation.

Tag field style:

http://rebol.hmkdesign.dk/files/r3/gui/257.png

Is that just CHECK, or does it work differently?

I think the intention is to emulate the MacOSX tag field. You write 
in a "floating" text field and when pressing enter, it becomes a 
tag, which can be deleted or moved around. Deleting or moving doesn't 
work yet.

looks like it removes the widget