World: r3wp

What materials do (apart frome some cute functions to calculate gradients, 
etc.), is that it basically adds block of following objects into 
face/materials:

	base: make object! [
		up: down: over: make object! [
			specular: 'high
			intensity: 1
			diffusion: [1 1]
			opacity: 1
			texture: none
		]
	]

My opinion is, that noone will be ever able to work with materials 
in any gfx tool. So for me the central material storage is a wrong 
decision. The same as it was with Gab's GUI to have central storage 
of skin and look. At some point, it makes sense, yes. But otoh, I 
prefer the source readability, and I think RebGUI was better, keeping 
stuff related to one style together.


What is more - we keep style draw "frames" at the style level too. 
I would like materials to move in the style too. I don't expect having 
tonnes of material skins, to switch between.

Pekr, materials are inspired by 3D modeler tools, which work the 
same way, with centralized resources of materials. They use similar 
parameters to adjust the appearance of a material, which is lifted 
above the direct approach of manipulating colors. Materials are a 
way to have designer friendly methods for adjusting the appearance 
of a style quickly and to provide logical connections between the 
highlight, color and shadow of a style.

I would also like style 'options block handling formalized, moving 
it to the style level too. We have on-* actors there. The more stuff 
we move there, the better. That way it will be easier to build the 
visual IDE tool imo ....

I am talking about the following code, hopefully it is that:

	append panel/facets reduce/no-set switch layout-type [
		panel [
			[
				break-after: any [
					all [
						in panel/facets 'break-after panel/facets/break-after
					]
					0
				]
				pane-align: any [
					all [in panel/facets 'pane-align panel/facets/pane-align]
					'left
				]

If this is not the effect of the implementation, then it's either 
used wrong, or the implementation is wrong.

Henrik - I am not sure I am denying materials. I can understand the 
abstraction, although so far I can't see the PRACTICAL benefit. The 
reason is, that the whole "skinning" is overrated, especially in 
regards to REBOL. Because - can you take R3 GUI style, and open it 
in Photoshop, do some skin/material simulation, and have it being 
saved? If not, the idea of central storage, regarding it being kind 
of collection of hundreds of contributed skins, might not follow 
the reality :-) I wonder if there ever be more than one skin :-)

Hence - this is the reason I might prefer in-style storage.

Henrik - am I right thinking, that 'materials do affect only area-fill 
parameter in the draw block? I am a bit confused - I can see various 
colors in styles, hardcoded. So what actually material system abstracts?

The practical benefit is that you can adjust the appearance of styles 
in a more logical way, than fiddling with RGB values. It's much harder 
to produce a correct look, when having to work with plain colors, 
unless you are producing abstract or flat cartoony styles.

Following is the CLICKER style FACETS definition:

	facets: [
		init-size: 28x28
		area-color: 80.100.120
		edge-color: 0.0.0.128

		pen-color: ; set by on-draw
		area-fill: ; set by on-draw
		material: 'chrome
		focus-color: red
		draw-mode: 'normal
		materials: none
	]


Too many colors around :-) Those are not part of material abstraction? 
I noticed that material basically defines area-fill ....

Henrik - once again - I might not be questioning material system, 
but it's central storage, vs per style storage. When I studies sources, 
it constantly distracts me to look-up some parts elsewhere ...

Then, in the above, the material system is not used correctly.

Nice to know :-)

The difference in these two images is one setting:

http://94.145.78.91/files/r3/gui/024.png
http://94.145.78.91/files/r3/gui/025.png

Generally, colors should never be hardcoded inside the style. Colors 
should be derived from the material system.

So in the above clicker code, those facets should not exist at all? 
Or should be set by material system?

But look at material 'base style. It does not contain any field to 
hold colors?

	base: make object! [
		up: down: over: make object! [
			specular: 'high
			intensity: 1
			diffusion: [1 1]
			opacity: 1
			texture: none
		]
	]

They should exist, because they are words used by the draw block, 
I assume. But the specific colors should be set somewhere outside, 
and then you use materials to derive the correct color.

The color is something you set, when creating the use of the material. 
That's how I can create buttons of many different colors, but with 
same material properties. That is another abstraction, which is not 
yet implemented, so I had to do it in the style for those buttons.

I don't understand - so color fields should be regular facet fields, 
but just settable by material system? And that is not implemented?

No, that is implemented, but the color that is passed to the materials 
system to generate the final color or material object, is ultimately 
still passed to it inside the style.

material != color

In the following document (images don't work), there was a way to 
show, how one can create complete style. No need to go outside the 
stylize. No imagine incorporating material system in there. First 
you have to know, how it works, so it is not enough to work with 
style draw frames, but you have to react accordingly in various phases, 
as on-init, on-draw. 


Then you have to go to completly different place, to define it. And 
that is breaking the workflow for me ...

http://www.rebol.com/r3/docs/gui/styles.html

If you keep everything inside the style, it's hard to create a skinning 
system.

No, it is not, why it should be?

because that means you have to create entirely new styles with every 
new skin.

1) Anyone yet has to prove to me, that having centralised skin/material 
storage will be practically usefull. What tool on Earth will you 
use to visually edit them? Imo none - we will have to come up with 
own REBOL based tool, which might understand all those draw defnitions 
imo


2) Having materials stored in the style (being part of stylize) means 
you can internally do whatever you want with it. In fact - what material 
system does in on-init style phase is, that it physically stores 
the material object into face/material. You could work even the opposite 
way - knowing the list of styles, you can collect all materials, 
if you need them to have in one place - what for, I don't know, maybe 
for some visual tool, where you will be able to tweak them ... one 
day ... maybe ... as surely Photoshop is not usable ...


The fact is, that having materials stored centrally is correct design-wise. 
But having to deal with styles, and based upon practical merits, 
having definitions scattered around lowers usability of the system, 
and easiness of understanding of system internals ...

ad 1) if the styles are draw blocks, no tool will understand them 
no matter if there's centralized storage or not.

Rebolek - yes, and that is why I prefer things having in one file 
per style ....

Do you prefer using images in buttons? Patching current buttons to 
use images instead of draw blocks isn't that hard.

Even current source distribution is wrong for me. What would be cool 
would be system internal functions being separate. And all particular 
style functions being part of the style itself.

Images? No. I talk about logic of how things are organised.

And all particular style functions being part of the style itself
 - what exactly do you mean?

I mean - there is an engine. And then there are styles. My idea (maybe 
wrong :-) is, to have one file per style, containing everything style 
related. Or at least having max 2 files. panel.r3, panel-funcs.r3. 
I just don't know - looking into style definitions is a disappointment 
for me - there is only few basic things, and there should/could be 
more. First things which come in my mind is materials, then options 
block handling, and I can imagine even functions: [] slot, where 
all related functions could be put.


I'll leave it where it is now, before the system is more complete. 
But later on, if I have a feeling, that there is some usability problem 
for users, I'll restructure the system myself.

looking into style definitions is a disappointment for me - there 
is only few basic things

 - isn't it good thing if you can write new style with changing just 
 few basic things without need for long code?

No, because it is not of course true. What you show to user inside 
of stylise, is only part of the style. For some styles, as shown 
in the above link, it might be true. But when you start to add things, 
you need to go outside the stylize, and I would like if stylize would 
be able to contain everything, having following slots:

style: [
    about:
    tags:
    facets:
    options:    
    actors:
    draw: 
    materials:
    funcs:
]

Plus the naming of inline options, options block, and style level 
facets vs options - http://curecode.org/rebol3/ticket.rsp?id=1847&cursor=7
should be resolved too ...

If I would not meet with Ladislav, I would not be able to find out, 
how are those things related. That is time-waster to anyone trying 
to study the system ...

it might be that I'm understanding it wrong, but do you simply want 
a MATERIAL word for the style? that seems to be the only difference.

Not exactly. Because in fact, there are both material, and materials 
words in the final face object. What I would like to see is the materil(s) 
word(s) for the style/stylize phase.

My idea is to have style "simulator", having just few named code 
areas, representing above post style: [ ......] structure. Then by 
protytyping, you would be able to develop full style, by putting 
code into particular slots. Well, that could be done even now, but 
I don't find a reason, why e.g. draw blocks, or actors are there, 
but code like options block handling, supporting functions, materials, 
are not part of the process ...

But I think that ideas for IDEs will come later. The system is still 
not complete.

I don't see a single reason why code like option block handling should 
be part of every style, it simply bind words from options to facets 
and one function does it for every style.

Petr, maybe it helps when you think about "programming in the large". 
I like self-contained stuff too. It's simple and fast to use. The 
problem is, it doesn't scale.

Imagine 20 customers, all wanting their own branded version etc. 
with an externalized material system you just link in a different 
setup code and you are done.

One rule we follow with the GUI is, that everything that provides 
"additional features" should be plug-in able. If you want to use 
it, you can include it and you won't notice an artifical break. If 
you don't need it, don't use it.

I don't see a single reason why code like option block handling should 
be part of every style, it simply bind words from options to facets 
and one function does it for every style.

 - Rebolek - what function is that? I found that e.g. for panel, it 
 seems to be an init-panel function, which maps options block to facets. 
 And no, it is not about simple binding, it does more than that.

Yes, it does more, but this is clearly not part of style but part 
of GUI system.

Styles should be easy to write, so the system should provide funcionality 
that can be used by style writers. Why would you want this functionality 
be part of every style instead?

Robert - my long time experience is, that code reuse is very often 
being a trade-off. I can't even imagine, how you make new material 
for your new customer. You don't have any visual tool for that anyway. 
And I am not sure if I can if it is in separate file, or with each 
style. I can understand the plug-in mechanism, but I am just right 
now not sure, if it outweights the usability aspect. I simply remember, 
that I liked to use the AMOS basic. Because it allowed cool things 
rather easily. And if users like the system they use, they will use 
it, and extend it. And sometimes it is about how cleverly the code 
is organised. We will see, how it turns out ...