World: r3wp

Carl's gui: FACED = instance local, FACETS = shared.

 - I know, but what is it good for? In the end everything will end 
 in face's facets anyway. Neither me nor Cyphre saw a single reason 
 to leave it, if you have some user case, then please, enlighten us, 
 because for us, FACED is only problem-maker.

So why have you introduced INTERN? INTERN is the replacement for 
FACED :-)

As for fields - what you are trying to say is, that just recently 
set-facet uses only direct assignment method, and what you want to 
achieve is set/get accessors, doing more stuff? What would be the 
usage syntax?

Intern was meant for style-specific functions. It may get removed, 
if it's not used.

So you still see there is not much place for fields, which could 
be e.g. shared for all buttons?

what you want to achieve is set/get accessors

 - exactly. Current syntax is (for compatibility) [set-face/field 
 face value field-name].

I just wonder where/how you define those boundary/value checks, etc.? 
But OK, I can wait for implementation ....

I am going to suggest the rename of do-style and do-face. Those names 
have absolulty no sense. DO-ACTION, DO-REACTION would be better one 
imo ...

You can dismiss the tickets ...

You must define map! with code for each field (two map!s actually, 
for get- and for set-). Unknown fields are ignored. This way you 
can also very easily get overview of what's possible to set(get) 
in particular face.

...rename do-style and do-face. Those names have absolulty no sense
 - Yes, I agree that those names aren't very good.

Rebolek - will it not complicate a bit design/syntax of style? so 
instead of facets [size: 10x10 color: blue  text: "test"] we will 
see maps? Or will it be hidden in some lower level?

Because - i have objections with the options block. One might think, 
that it directly maps to facets, but it is not the case. It seems 
to use similar mechanism you are suggesting now for fields. Or am 
I wrong?

No, you're not wrong, it's similar to options. But it won't change 
style design, nothing's going to happen to facets block. This is 
just preffered interface  for accessing already existing faces.

I am about to write CC ticket for 'options. There is naming discrepancy 
here, as well as I think, that those things could be made declarative, 
and move inside the style definitions. Ditto for materials ...

Hopefully you will be able to understand, what I have in mind. I 
decided to put my ideas into CC, if I feel it that way, because that 
way it is at least recorded, even if dismissed.

Options not mapping directly to facets - internal representation 
of data may differ from user preffered format.

CC ticket is always good way.

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
		]
	]