World: r3wp

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 :)

he pragmatic, and I suppose he sees it as pragmatic when he wants 
to use colors to decide button emphasis. if you are doing something 
quick and dirty that works, but when you are building very large 
apps, that's a no-no.

hmm... "he pragmatic, me Tarzan, ugh."

I remember that the solution we came up with during the initial design 
phase was to have colors in the layout dialect be specified functionally, 
like window-background and such. This was not implemented at the 
time (we never got around to it). Was it forgotten?

Yes, named colours are good.

I find that highly desireable.

that's not yet implemented. colors in Carl's version are hard coded. 
notice also that a lot of values are hardcoded in his styles, and 
he told me this was for speed.

That way a theme designer can come up with a well-balanced color 
scheme that could be used by many applications, as long as the corresponding 
concepts had assigned colors in the theme.

I expect there will be a lot of abstractions between the hard values 
and the styles. The material system will also help with that.

You could bake the colour in at style init time, and then you will 
have the same render speed.

that's what usually happens now.

With a meterials system you could bake a whole theme in at app init 
time, then have the styles bake the applicable colors into the styles 
at style init time.

baking
, I like this term :-)

Sorry for the typing errors, I need to rest and can't sleep. It's 
still Sunday for me.

the materials system borrows many terms from 3D modeling. "baking" 
is another one and a good one for providing an explanation of what 
should occur during style init.

You might also use "imprint".

One of the other original motivations for strong theming support 
was to get the theming sites around the internet involved. Challenge 
them to come up with good themes. Their efforts would market REBOL 
as well. But disabilities, other form factors and other situations 
are a factor as well.

This would deal with Shadwolf's complaint about R2's VID appearance.

That means declarative themes though, no procedural code involved. 
The themes should be able to be made by non-programmer artists working 
with graphical tools (likely also written in REBOL).