World: r3wp

Rebolek - then there might be a difference to init knob size. I know 
it should be recalculated to the amount of data, but maybe by default 
it could be the minimal size, instead of 100%?

Usually when you work with IDEs, you are able to choose scroller, 
and the know size is at the minimal position, not at the maximal 
one, imo ...

Yes, that may be changed. OTOH, scroller's main  purpose is to scroll 
an inner area, while you want to set value, which is slider's purpose.

Slider is just scroller without arrows, no? :-)

Nope, slider is a value adjustment tool. It doesn't need knob size 
management.

Ah, visually different. IIRC we had used "scroller without arrows" 
for such purposes in the past?

I'll change the demo then ....

We did, because VID provided such features in its usual extremely 
bare-bones style. :-)

What is the situation with compound styles? When you e.g. design 
scroller - is it a mixture of two styles? Slider (in old gui sense) 
+ arrows? I mean - if we have arrow style, and you will use the arrow 
in some compound style, then when you change/restyle arrow, will 
it change also inside of compound style?

Or are arrows "hardcoded" in scroller style?

SCROLLER is not compound style and arrows are "hardcoded".

So what is an example of "compound" style? E.g. table?

text area + scroller

Can SCROLLER be compound style? - Yes, it can.

Rebolek - your above example of setting the delta to 10% does not 
work. It displays something, but the know is 100% sized anyway ...

I can confirm from demo:

radio "Delta 50%"  set 'sbar 'delta 50% ; does not work
button "Set 50%"   set 'sbar 50% ; does work

Pekr, maybe it requires some fixes that weren't released yet.

What is the 'state object? I can see there is knob-size set to 100%. 
What is the purpose of this slot? I thought that parameters are stored 
in facets?

Well, the STATE object is for internal parameters that shouldn't 
be changed by user... We got rid of FACED already, as it was only 
causing confusion and wasn't solving anything. STATE will probably 
stay, but various words may be rearranged and moved between STATE 
and FACETS.

My secret plan is that SET(GET)-FACET should one day probably work 
as SET(GET)-FACE/FIELD but currently there's only one style that 
supports fields, so this will take time.

I think the original idea was that user should always use SET(GET)-FACET 
for accessing values and should pretend that FACE/STATE/... is impossible 
to do, so STATE would stay internal and inaccessible.

For better understanding of material system. I can see code like 
this:

		material: 'scroller

		area-color: 200.233.245
		edge-color: 0.0.0.128
		arrow-color: black

		area-fill: 
		over-fill: sky
		down-fill: coal 

And late in the on-make, this:

			; Prepare materials
			make-material face get-facet face 'material
			set-material face 'up 

Questions:


1) why are those  facets being set? Is it just that you need to give 
them some initial value? Is my understanding correct, that during 
on-make, those values are being overriden? Most probably not, because 
materials field hold up/down/over values.


2) is material system sufficient, if it holds only gradients? It 
should imo hold all values, which might influence the design of the 
widget. And hence even bare-bones colors. The question also is, if 
draw-blocks shold not be part of the material system too, because 
my impression is, that so far, it does very little to be any usefull, 
and the difficulcy to understand the whole concept might not be worth 
the effort.


3) There is an architecture discrepancy - materials do use central 
storage (kind like old VID kept 'feel actions block together - nice 
idea, but really not any usefull, and VID2 design mistake imo), while 
draw blocks are contained per style definition. I think it might 
be wise to think about moving materials: [up [] down [] over[] ] 
slots to the style definition itself

Rebolek - I hope you know what you are talking about :-) FACED was 
usefull - it was local instance copy of the value, not the shared 
one. FACETS then kept the values shared. RMA changed the design, 
so that FACETS are now instance local, which of course might lead 
to the increased memory consumption (that would have to be proven 
though). RMA introduced INTERN slot for holding instance local values, 
but from what I saw, that is not used that much yet ...

What I really start to miss is high level design docs. I simply don't 
necessarily agree to some of architecture design decisions. I know 
that last thing you want to do is to create docs, but I am starting 
to think I'll produce some CC tickets for that ...

I have yet to see a single case where FACED is useful to change my 
mind about that decission.

FACED is not usefull anymore, as you reversed the design. Once gain 
- Carl's gui: FACED = instance local, FACETS = shared. RMA's GUI 
- FACETS = instance local, FACED = dismissed, INTERN =  instance 
local. So if you question usefullness of FACED, then you are also 
imo questioning usefullness of INTERN. I must miss something then, 
or you did not understand, what was FACED supposed to do in Carl's 
GUI?

My secret plan is that SET(GET)-FACET should one day probably work 
as SET(GET)-FACE/FIELD but currently there's only one style that 
supports fields, so this will take time.
 - Sadly I have no idea what you are talking about here. 

GET-FACET FACE 'SIZE
vs
GET-FACE 'SIZE????

FIELDS are probably not part of the latest public release. Currently, 
[set-facet face 'size 10x10] is basically the same as [face/facets/size: 
10x10]. With fields you can have some code that will check the value 
for right datatype, boundaries, etc.

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.