World: r3wp

OK, so my weak brain just dictated to create four tickets, related 
mostly to architecture of the GUI :-)

I will not submit particular style problems, as what I can hear most 
of the time is - it is not yet adapted. But it depends, maybe for 
clarity it would be good to have any findings in there too ...

OK, so I added bunch of tickets, which record some of my worries. 
There are also two fixes to 'doc style. While I know it is going 
to be replaced, but if it does not happen soon, it might still be 
worth to patch them.

I spent a bunch of hours in the code, and thinking about the architecture, 
so hopefully you don't dismiss them in 10 seconds :-)

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. The fact, that the result of the 
 resizing is different demonstrates, that the result of resizing depends 
 on other attributes as well.

So, nobody forbids you to set the INIT-SIZE as you see fit.

It is demonstrable, that frequently, it can be useful to have INIT-SIZE 
outside of the MIN-SIZE to MAX-SIZE range.

That being the case, it is necessary for the three dimensions to 
be independent, in that it has to be allowed to set the INIT-SIZE 
outside of the range, i.e. set all three dimensions independently.

current behaviour allows inlined set of init-set, which has no effect 
though, and hence causes user confusion 

 - that is not true again, since the user can examine the INIT-SIZE 
 attribute, he can easily find out, that it has been set as specified. 
 What was not set (and not specified) is just the MIN-SIZE and MAX-SIZE 
 values.

So, the default values (examinable) are used.

- allow max-size override. If user requests 400x400 button, which 
exceeds max size in x and y axis, set new max-size to that value. 
The argument that that might not be eventual max-size user might 
imagine does not hold any water. 

 - as said, MAX-SIZE shall be independent from INIT-SIZE. What I do 
 want to preserve is the independency between INIT-SIZE and MAX-SIZE, 
 since that *is* needed in reasonable cases.

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.