World: r3wp

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.

So, both http://rebol.hmkdesign.dk/files/r3/gui/214.pngand http://rebol.hmkdesign.dk/files/r3/gui/225.png
are examples of the Group style now.

The style uses a LAYOUT-MODE attribute, which determines the preferred 
orientation.

The http://rebol.hmkdesign.dk/files/r3/gui/214.pnghas LAYOUT-MODE 
set to columns, while the http://rebol.hmkdesign.dk/files/r3/gui/225.png
has LAYOUT-MODE set to rows.

Neither of the pictures represents the Panel style now. The Panel 
style would have "regular" rows as well as "regular" columns at the 
same time.

Is it possible to define the number of columns or rows?

(depending on LAYOUT-MODE)

The columns or rows are "internally" implemented as lines, and if 
you switch the LAYOUT-MODE you just tell the resizing algo to handle 
the lines as rows or as columns

well, why not to use LAY-X, LAY-XY or something like that?

No, it is just one style, not two

It may sound a bit cryptic, but LAY simply exactly states that we 
are going to somehow layout the elements

Ladislav - I thought about unifying the naming, so replacing GROUP 
by specific LAY-XY

in group the objects are organized into either rows or columns (internally 
lines all the time), i.e. XY is misleading

Summary: in a group, objects are arranged into lines, that are handled 
depending on the LAYOUT-MODE as either rows or columns

LAY-ANY, LAY-COLUMNS, LAY-ROWS :-)

Pekr, we do not need three names, it is just one style

btw - why "panel" is not fitting anymore? I can see no problem in 
using a panel name for what you described ...

(currently called a "group")