World: r3wp

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

BrianH: are you suggesting no more BUTTON RED "OK" code? :-)

yes, you would simply write OK-BUTTON instead.

OR button-RED instead :-)

simply put - it is not that it would not be technically possible 
to pass any such argument to the style during the construction. It 
is about - we don't want to do that for some attributes, color being 
one of them, because it could ruin overall look of the GUI ...

it's not just looks. deep semantics that are used to make the GUI 
function properly relies on functional styles rather than appearance 
of styles. if you have a red button, the GUI won't know of its importance. 
but if you have an OK-BUTTON, you can tell how important it is, when 
it should be focused and what you are allowed to do with it. automating 
this can cut off hundreds of hours of development and testing time, 
because you don't have to pay attention to those details. the UI 
system does that for you.

that is why I utterly hate when a UI system does nothing to offer 
these features and the focus is on how pretty your buttons are or 
if the UI uses hardware acceleration.

I see no difference between OK-BUTTON, and RED-BUTTON. E.g. in some 
embedded apps, RED means STOP. The fact that your OK-BUTTON does 
some other things does not matter, no? I just don't probably understand 
your "automating" argument. Can you give me an example?

sure, have you ever written a very large document in Word and then 
wanted to generate a table of contents using its built in TOC generator?

it can't do that, if you don't specify what exactly the headlines 
are. you can color them as crazy as you want, but it won't understand 
it.

this is _exactly_ the same problem.

I was taught proper document design back at the Lotus AmiPro days 
- much better than Word at that time, and it pushed you to use styles. 
So - I hate inline styling. But - how does it apply to the GUI?

proper usage of styles in the R3 GUI works exactly the same as in 
documents that are properly styled. there is no difference.