World: r3wp

To not be misunderstood:

- everybody is allowed to set INIT-SIZE howewer he likes
- everybody is allowed to set MAX-SIZE however he likes

- nobody is allowed to ask me to be more clever than him and to "correct" 
(read: "mess up") the MAX-SIZE for no reason, in fact

There was very long discussion, towards if we should allow to change 
the size of the button to allow any size being set" - did you really 
mean it? One can easily make sure, that the init-size of the button 
is set as specified." - Yes, I meant it, because IIRC there were 
opinions, trying to suggest here, that it should not be allowed at 
all :-)


All stuff you write - I know. It is just that I might not necessarily 
agree with the outcome. I am trying to think form user's point of 
view. I wonder to what points you would agree, and to what not:


- Let's assume I set button in bounds (between what min-size/max-size 
allows): I tried various scenarios, and I almost never got button 
of requested size. The reason is in how resizing system works. In 
fact, when inspecting various sizes - init-size, min-size, max-size, 
those don't contain actual button size. Actual size is in face/gob/size. 
Button gets different size due to resizing system cell alignment 
imo. From the resizing system point of view, it is correct behaviour, 
but from the user's perspective, it is questionable, if the result 
is OK?


- In regards to above point, I really wonder, if buttons should be 
resizable at all. I said - resizable, not settable. I wonder, if 
I would like buttons to be of consistent size. I might try with face/resizes?: 
false, if that would make the trick.


- Then, in regards to above - I might think of init-size setting 
the requested button size


- Maybe (and I am not sure about that one), we could allow some debug 
info - "out of bounds", if my init-size value does not fit in between 
the min-size, max-size, as style author defined it. I have heard 
that guys are working on some field accessor functions - those might 
be able to print some debug info to console, at least when in interactive 
mode.


Othere than that - this one is a minor issue for me, I e.g. care 
more about architecture, and so far I can see materials having real 
low benefit, for how complicated it turns out ...

you just set material's name, what's so complicated about that?

If you would read CC tickets, you would know :-)

It is an abstraction, to which I don't know, if it is necessary, 
or not. For me the beauty of "VID" is in two things mainly - ability 
to prototype quickly, ability to declaratively read the source of 
the style/widget.

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.