World: r3wp

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.

and that's why you never see in a word processor a function like: 
"collect all red text for use in TOC". it says: "use headline level 
1 for TOC".

On naming, I think PANEL is too general and doesn't describe the 
layout behavior. I could live with it though. 


I agree that TABLE should be saved as that is the common term for 
the spreadsheet model. GRID was used for that for a long time, and 
still is sometimes, but GRID could also be good when thought of as 
a canonical grid layout. GRID-LAY, CANON-LAY, or TABLET aren't too 
inspiring either.

Gregg, one thing that became clear in discussions of function doc 
strings recently in Curecode is that it is impossible to fully describe 
the behavior of some programming functions and objects using just 
one name, one sentence, whatever. No matter how long you allow the 
description to be, any sufficiently complex thing won't be describable 
in that limit. And you *want* limits because people have to read 
and write these terms, even more so for fundamental stuff that will 
be used a lot. The use of small, preferably non-compound words will 
speed up the process of humans reading and writing layouts. Java 
failed this pop quiz, btw.


This is why we have names for stuff (and people too: Does "Gregg" 
describe you?). A name serves as a placeholder for the knowlege you 
already have about the object in your head (preferably) or in the 
documentation. As long as we have good documentation, any small, 
easily distinguishable name will do. You will never fully describe 
the term, but by reading the documentation, or source, or through 
experience, the programmer will know what is meant.


In this specific case, "panel" is a general term, but many GUIs have 
traditionally used the word "panel" to describe the corresponding 
concept in their systems. That term never fully describes the behavior 
of that object, but it makes a good, easy to remember name for a 
complex concept that the developer is expected to have to learn. 
By using PANEL, at least experienced developers will know that they 
will have to look things up, and inexperienced developers will have 
to look things up no matter what name we choose. You don't get the 
same benefit from the term BOARD, for instance, because while the 
English terms are similar, "board" doesn't have the historical connotations 
that "panel" does in the computing world, so it doesn't gain the 
benefit of them.

Yes, I realize ithe irony in using such a long post to argue for 
short words, but in some ways it illustrates my point :)

LOL. Thanks for the detailed and thoughtful post in any case. As 
I said, I can live with PANEL, which is good since I couldn't come 
up with anything better.

call it jigsaw :)

Mosaic? ;-)

Decoupage ? ;)

Deco ... what? :-)

box, board, mosaic, matrix, sieve, die, wire, netting, tissue ... 
and the winner is - panel :-)