World: r3wp

Petr, just don't care about it. Suggest a good name :-)

We can go along with Group and Panel, as Pekr suggests, no problem 
either

If we will not find better use-case for a Panel style, then let's 
stay with panel. If not, use Board instead ...

Panel is a good name. All of these are pretty arbitrary when applied 
to a GUI system. Pick something traditional like Group and Panel, 
that sounds nice.

Not Board though, it focuses too much on the flatness and not any 
more on the layout.

Bolek got hurt in an accident, which is why he was not so active. 
He should be back in business in a couple of days.

uh, hope he is OK!

Must be okay if he's back in a couple of days?

Broken clavicle.

You guys didn't make him lift too many heavy widgets??

Is Carl still in the R3GUI scrum ??

yes, although he's focusing on host kit right now.

on callbacks? or IPC ?

callbacks

Good to hear

How about WRAP-PANEL  (or ARRANGER or "CONSECUTOR") ?

Remember, whatever name we choose will be written out a lot. The 
two main layout styles will show up a lot in user layouts. So short 
is good.

Won't we have styles to allow us to choose our own names?

Yes, you can make your own styles. But most code sill be just layouts 
and behavior, which are separate from style creation. You don't do 
derived styles in the layout itself.

I agree.
But I have some ideas for making a very general layout mechanism.

It looks to me that the layouts above can be expressed by two nested 
levels of arrangement.

Remember, the goal is to be able to write layouts with as little 
style information as possible, just the style names, data and options. 
Keep the need to specify sizes to a minimum, colors never. The layout 
dialect is for app programmers, not graphic designers.

To give you an example, I would be the target market of the layout 
dialect. I am not a graphic designer, nor should I have to be. And 
you don't want me picking colors.

(It seems dubious to me that a graphic designer wouldn't be interested 
in layout, but I can understand the merit of separating the specifications 
for colours and the specifications for layout.)

Here's the notes I tried to post before when you were discussing 
LAYOUT-MODE:

HTML refers to this as "inline" (and the line may wrap).
I used 
grid-face/LAYOUT-DIRECTION: 1x1  and  
grid-face/MOVE-FIRST: 'horizontal
in my old GRID style.
	do http://anton.wildit.net.au/rebol/gui/demo-grid.r

But the parameters needs to be clarified some more.

Academic papers published as PDFs often have two columns of text.

That means a single line of text wraps horizontally, vertically, 
and horizontally again.

Eg. The line of text first wraps (horizontal) when the right hand 
edge of the first column is reached,

then, after many rows are similarly wrapped, when the bottom of the 
first column is reached (vertical wrap).

All of that occurs again for the second column (and perhaps more 
columns) until there is no more room on the page,
so the final level of wrapping is horizontal. 

So I would have 
	face/WRAP: [horiz vert horiz]

which specifies three levels of wrapping, horizontal for chars, vertical 
for lines of text, horizontal again for columns (so that the next 
page is underneath the first one).

To put pages horizontally, you would just have 
	face/WRAP: [horiz vert vert]


Or you could specify an extra level of wrapping, eg. so that you 
could have groups of two pages shown horizontally
	face/WRAP: [horiz vert vert horiz]


The direction for each level of layout should be specified to correspond, 
eg.
	face/LAYOUT-DIRECTION: [1 1 1 1]
which would give left-to-right and top-to-bottom.
(Use -1 for right-to-left  and bottom-to-top directions.)

If we see styles like 'red-button, we've failed in our design of 
the R3 GUI system.

I don't agree about RED-BUTTON.

I think it should be possible to make a style like that, if you really 
want it. (Most of the time, you don't want it, but when you do, you 
do.)

As long as there is nothing to imply that the red-button style would 
actually be red at runtime, sure. Colors are for theme designers.

Most of the time when a programmer thinks that they want to specify 
colors, they are wrong.

No, I specifically disagree about that. If I want a style to be forced 
red, then I want it forced red.

I agree, most of the time the programmer doesn't want to think about 
it, and it's best to get the colour from a theme. BUT, WHEN YOU WANT 
A BUTTON ALWAYS RED, YOU WANT IT ALWAYS RED!!!!

(Sorry, that should be "when *I* want ...")

You are a graphic designer then. We are assuming that the "programmer" 
and the "graphic designer" and the "style designer" could be the 
same person in practice, but the roles need to be kept distinct even 
when the same person is doing them.

(Gee, sorry I shouted.)

That means that styles get functional names, not graphical names. 
Layouts should make sense if the user is color-blind. It is up to 
the theme designer (which may also be you, in a different role, or 
it may be someone on a theming site) to decide colors.

Keep in mind that is the layout dialect that shouldn't have colors. 
Styles are specified with a different dialect, and they can have 
colors in their draw blocks.

Yes, I agree this is the best way 99.9% of the time. And this separation 
of specification has all been discussed before.

Anton, you are free to do that, but it will break the philosophy 
of how styles work together. I think this point is not properly understood, 
but it will move the GUI to the next level, where you spend zero 
time thinking about colors or theme, can properly divide UI design 
between a graphical designer and one producing programs.

I just jumped (somewhat pedantically) on BrianH for making an absolute 
statement. (I've also just turned down the heater in my room, I didn't 
realise I was heating up.)

So I apologise. I'd prefer to get back to the layout discussion above.

For the other 0.1% you can write your own styles, or your own themes. 
Of course, when you are doing that you are being a style developer 
or a theme designer, not an app developer. The app developer (possibly 
you) will use the style developer's styles.

Yes, yes yes, I *understand*...

You jumped on me for making a statement you misinterpreted completely, 
so I take no offence :)

I had actually wanted it to be even more strict, that styles should 
not be possible to set appearances for in layout at all. But I can 
see that colors have snuck in, anyway.

Really? That should be fixed.

That was Carl. He likes to allow this, so I doubt it will go away.

If it is in the layout dialect, I mean.

that is determined by each style through the argument parser, not 
the dialect.

Carl (who has many other fine qualities) sucks at color choice (sorry). 
So I have him (and me) in mind with the layout dialect not specifying 
colors :)