World: r3wp

and yes it was started with RebGUI, mainly because that was the standard 
GUI system to use at the time.

and yes, it could easily have been written in the vid extension kit.

I recall that Robert forked his own version a while back

yes, that's the one we use.

yeah, it looked a lot like rebgui to me; but who knows, maybe you 
just imitated that style :) thanks for clearing that up!

Dunno if it's just me .. but often I will get RebGui crashes because 
part of the gui being referenced has not yet appeared.

Is instantiation of widgets much faster in the new R3GUI ?

I'd say much faster since there is a specific lightweight datatype 
for them

(but i'm just assuming here)

can you give an example, Graham? that sounds interesting

Not really ... it just happens and I just have to wrap as much code 
as I can with attempts

that sounds very odd. I've never encountered this issue.

I do a lot of dynamically creating layouts .. I suspect it's related 
to that

hmm... yes. I still don't see how you are able to do that. From what 
I can gather, it's not much different from VID in that face names 
are set as they are laid out, and when that's done, you can use the 
face. Talking about the *speed* at which widgets are instantiated 
worries me a bit. :-) That should never be an issue unless you are 
doing some form of multithreading.

All I can say then is that I do see a lot of rebgui errors if I use 
the gui too quickly

ok

If I use the GUI in a sedate mode .. then no errors

if anyone has looked at it, do you think adding function as argument 
for the CLOSE reactor could be considered a security problem?

adding function => "adding function!"

Henrik, I haven't looked at it, but if I guess right, you mean you're 
considering adding a callback ability to the window close function. 
Surely it would be a gui programmer who would be able to use this 
callback, right? You haven't programmed the close button to pop open 
a dialog for the end-user asking for arbitrary rebol code to execute 
with security off, have you? ;-)

What makes you want this callback, anyway? (I'm not implying it's 
bad or good.)

I wanted it for dialogs, and correctly, it's just another option, 
since CLOSE offers the ability to set a value (logic!, block!, word!) 
in the window face, as the window is closed. The SUBMIT reactor allows 
a call-back.

I guess that SUBMIT and CLOSE both offering it won't make a difference, 
security wise.

now that I think of it, I'm not sure how much good it will do to 
add callbacks to CLOSE, since CLOSE for dialogs is meant to give 
a fixed way out of a dialog.

Hmm yes. If ever a dialog's close button does not simply close the 
dialog, I'm probably going to wish that the designer had found a 
better way to program the gui.

as it is now, the dialog system "forces" some specific routes. the 
intent is that dialogs must allow dozens of different standard dialog 
layouts and standard buttons. combined, forms in layouts would automatically 
be validated and the dialog would behave appropriately, i.e. not 
closing if the form and provide warnings is invalid. this works now 
in the prototype, and the end user won't have to do anything to use 
it in the standard dialogs.

You need a close reactor to do the save-your-stuff prompts.

Not all apps are form-based. Some are document-based.

these aren't apps, but dialogs. dialogs have different behavior and 
use a short life cycle. the behavior for application windows is different 
and requires, correctly, management of the close action.

Any news how implementing command wrappers for AGG goes? Or on GUI 
status in gerenal? :-)

- Cyphre is implementing remaining DRAW commands in hostkit.
- Ladislav has been working on resize code for a bit

- I'm studying whether it's possible to replace arguments for reactors, 
an esoteric, but necessary part of dialogs.

- Bolek is working on style code, but I've not seen any activity 
for the past few days.

thanks Henrik - such a short summary is absolutly perfect to keep 
us informed. I will ask in 2 weeks the same question :-)

Resizing news: the latest state is, that there are two "container 
styles", the first one being a group - a layout in which graphic 
objects are arranged into either rows or columns, not necessarily 
into *both rows and columns* at the same time, the second one is 
a panel - a layout in which graphic objects are arranged into both 
rows and columns at the same time.

I guess, that it does not surprise you, that the resizing algorithms 
for group and panel differ...

yes, I've suggested calling PANEL a TABLE instead, since it more 
clearly defines how it lays things out.

Regarding the names: Cyphre thought, that the "table" name should 
be reserved for something even more "specialized"

Table could be mixed with ppl expecting grid widget imo ...

Ladislav, ok, maybe "array" or something?

or "block", "matrix" ... but I am ok with "panel" anyway ...

the problem with PANEL as it works now is that it lies, name wise 
too close to GROUP, which has significantly changed behavior now.

It may be the time to discuss the style name, I just do not know 
what is the best forum for it

(we should let Carl to have his say too, I guess)

we'll take it here for now, then make one conclusion and bring that 
conclusion to Carl.

If it's not clear, the GROUP style produces this flow:

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


If you turn that 90 degrees, you'll see that it's like how newspapers 
arrange columns, so I would want to find a familiar DTP term for 
it.

Henrik, sorry, this is a misunderstanding

ok, backpedalling a bit :-)

Do you have a picture for the other orientation?

it seems 214 is the closest one

OK, thanks.