World: r3wp

As for overriding. I am not sure higher level on-click should disable 
lower level on-click. In the OOP I used (CA-Visual Objects), and 
just IIRC (so sorry, if inaccurate), you had such options:

- to execute child method

- in the above you either returned false (maybe I get this one wrong, 
but you get the idea) or the parent method was called right after 
the child's method 

- there was also some override option, but I don't remember it, it 
is 12 years old experience

Cyphre: if we go for #3, will there be the option to "insert-event-func" 
like in R2 ('detect functionality), which would allow us to apply 
some filters? E.g. for dev/demo purposes?

Rebolek, also I'm afraid in case of #1....since you can call any 
actor of any style/face from the style code, we would propbably check 
all such DO-ACTOR calls in the code to make sure they are not called 
on style/face that doesn't have the specific actor defined othervise 
the propagation would be triggered.

Pekr, I don't think 'insert-event-func' has anything to do with this 
decission. Currently R3GUI doesn't have the exact 'insert-event-func' 
mechanism. But you can add your custom handler with specific priority 
into the main event loop and then either filter out or pass the events 
to the system.

(this feature is imo more flexible than the 'insert-event-func' stuff 
in R2)

I never liked insert-event-func very much.

Given Richard's example, where unhandled events bubble:

view [
	hpanel [
		box red on-click [print "red box clicked"]
		box blue on-click none
	] on-click [print "panel clicked"]
]

box blue on-click none

 had hidden meaning. It means "pass thru", not "don't take action". 
 Give his example of how to explicitly propagate events:

on-click: [
	all [
		pf: parent-face? face
		do-actor pf 'on-click arg
	]
]


Would it be possible to define a shortcut, e.g. on-click 'pass-thru, 
in either scenario?

the "it will be complex for event handling of the rest 95% of normal 
cases" is the reason why I prefer #3. As Gregg noted, in case of 
having #3 we can still define some "shortcuts" either by defining 
a simple actor "propagating" some event, or even adjust the layout 
dialect to accept a keyword

(a simple actor "propagating" some event up the parent hierarchy 
can be easily inherited)

Gregg, Ladislav: ye, I agree, so to me it looks the 'conclusion' 
is heading to the #3 case with some possible 'shortcut' support to 
make the event propagation less verbal for the programmer. What do 
you think? Should we wait for more input or close this topic?

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.