World: r3wp

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

Rebolek - no, because it IS NOT part of the system, but part of the 
style, can't you just see that?

I hated AMOS basic because of how system-unfriedly it was.

Imagine I am writing new style. How on earth I define, in stylize 
level, how is options block mapped to facets?

Show me other basic allowign rather easy animations, sound, and game 
creation :-)

blitz basic  ;-)

:)

Rebolek - to not be confused:

button 100x20 "OK" options [here is the options I talk about]

actually better in all regards  :-)  but it had all the OS friendliness

Max - a good one :-)

their cow and camper racing game was hilarious  :-D

How on earth I define, in stylize level, how is options block mapped 
to facets?


Why do you want to do that? Let's say I want to write KNOB style. 
I can set for example it's value, color and size, so options would 
be something like:

options: [
	level: [percent!]
	knob-color: [tuple!]

 knob-size: [integer!]	; it's round, so diameter is enough for size
]


Then I can use knob-color, knob-size... in draw block without any 
manual mapping.

You see, you have mess in naming, no wonder you don't know what I 
am talking about!

what mess?

Options you put here, are inline options, whereas what I am talking 
about is the options block from the dialect level, which maps to 
facets!

http://curecode.org/rebol3/ticket.rsp?id=1847&cursor=7

Uh oh, trying another way:

button "OK options [my-field: "test"]


Where is the 'my-field processed? That is the 'options I talk about, 
which I want added to stylize ...

And because style has 'options block, which maps to inlined parameters 
("OK" string in above example), what I am claiming is a name clash/confusion 
here ...

hence the ticket ...

I can rephrase the question - how does user define, creating a style, 
what might be declared in an options block (dialect level, my-field: 
"test"), and how is such options block being evaluated, and values 
being assigned to facets?

Pekr, values that are specifiedin OPTIONS field in layout by user 
are set in the face/facets context.

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.

 - yes, the size is always a result of resizing rules, as applied 
 in a specific style. There are two methods working quite differently, 
 the first one is used by vgroup/hgroup, the second one by vpanel/hpanel. 
 If none is what you like, then there is a possibility, that you would 
 like to have a completely different style, with different resizing 
 rules...

If you really want to have a completely different style, with different 
resizing rules, you should carefully write down your requirements/ideas 
so, that it would be clear how it would work.

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

 If you set the RESIZES attribute to OFF, you get a completely different 
 behaviour, than what you expect:


- the resizing algorithm will leave the button untouched, which means, 
that it does neither compute the position, nor the size, and the 
button would just "float" - the next version will contain more than 
20 different examples, Cyphre's visibility example manipulating the 
RESIZES attribute included


- if you just want the resizing algorithm to not change the size 
of an element, while allowing the resizing algorithm to compute the 
position of the element, you should do it differently. Just set the 
INIT-SIZE, MIN-SIZE and MAX-SIZE of the element all to the same pair. 
You will notice, that the size of the element will not change, no 
matter what, only the position may change.

Pekr, regarding your OPTIONS vs. FACETS naming. I don't see any problem 
here. It's normal, especially in Rebol, that  word symbols can be 
used differently in different contexts:
in style context - the OPTIONS means 'inline options'
in layout context - the OPTIONS means 'face options'

Also from the beginner POV...it is easier to understand word OPTIONS 
in the layout dialect than FACETS no?

Ladislav - I might wait for examples, but - what is the main difference 
between - floating vs computing the position of the element? I somehow 
can't imagine it. Will it be shown in the examples?

Cyphre - what you just said says it all. I don't care for different 
context and word meaning, if those contexts are so close one to each 
other, that it might confuss users :-)

yes, you shall find out, in general, "floating" means - the resizing 
algorithm influences neither the size nor the position in any way, 
i.e. the element "floats unnoticed by the resizing algorithm"

I think I understand the difference, but I was not easily able to 
see what is what, unless I studied it more deeply, and unless Ladislav 
told me during our meeting, that layout level 'options does not necessarily 
directly map to face/facets ....

aha, so floating might mean, that the elemetns xy offset stays the 
same, so that e.g. button stay upon the area, or something like that? 
Is that usefull? :-)

Yes.

- if you just want the resizing algorithm to not change the size 
of an element, while allowing the resizing algorithm to compute the 
position of the element, you should do it differently. Just set the 
INIT-SIZE, MIN-SIZE and MAX-SIZE of the element all to the same pair

 - this is the worse solution from the two offered, while more usefull. 
 I can imagine I simply don't want buttons being resizable. Then 'resizes 
 field does not express the meaning of the word, as in fact it does 
 not resize, but it also floats, which is imo not that much usefull.


In order to prohibit e.g. button from resizing, I need to derive 
the styles, and remove the init-size options from being set.

IIRC there were also some other "tags", allowing to describe parameters 
as HIDDEN, etc. - where are those set? I forgot ....

Hmm, you don't have to forbid setting INIT-SIZE. As I mentioned, 
it suffices to make sure INIT-SIZE, MIN-SIZE and MAX-SIZE are all 
equal.

float faces are very useful, Pekr.

How can I assure that for the end user? :-) So you mean - if user 
does not want button to resize, he has to be sure, those values are 
identical ....

Rebolek - are float faces something like absolute CSS positions?

I would prefer 'resizes, 'floats or other fields, which would take 
care of it internally. But not sure. That is why I asked where other 
valueas as HIDDEN (that one I remember) are set? Are that flags/tags?

Yes, absolute positioning. You can't do for example drag'n'drop without 
that.

ok, moving to pub  to watch Sparta vs Liverpool :-)

The properties like HIDDEN, etc. are implemented somehow, (implementation 
detail! don't ask - but you can check the SHOW-FACE function, if 
you insist you need to know)

Pekr, you said "layout level 'options does not necessarily directly 
map to face/facets"...that's why I don't want to rename OPTIONS to 
FACETS in the layout block. Also so far you are the only one who 
has problem understanding the 'options in layout vs. 'options in 
style definition and in fact you haven't proposed any concrete solution 
(evenin your CC ticket).

I'm not saying I'm against reasonable change here but since there 
is no good viable solution(and noone except you cares) we should 
 either wait until it pops out from someones head or just let it 
be as it is now.

Cyphre - let's be realistic - I am the only one, because in fact 
I am most probably the only one, who is investigating GUI in such 
a deep manner, if not at all. This is imo a result of bad RT's treatment 
of R3, which is bringing REBOL into isolation even further more, 
making less and less ppl interested with almost zero RT's action 
... and that's the reality ...

sadly you are right Pekr

Wrong, reasons: 

- those values clearly *are* options the user specifies

- the fact that some options may be inlined (i.e. the name may be 
used in another context) does not change that in any way

- what is "deep" about saying you don't like a name (in an arguable 
case) is beyond my understanding

- renaming to "facets" would not help anybody including Pekr as he 
surely knows

OK, and I think you are wrong too, and we can let it that way :-)


the fact that some options may be inlined (i.e. the name may be used 
in another context) does not change that in any way

 - yes, it does. So far I can only follow my brain logic, which simply 
 was confused. Well, I could admit, that I am dumb :-) But the chances 
 are, that some other ppl might be confused too, so my answer is:


- style/options does NOT clearly define, what options user can set 
in dialect options block, because that block, is SUPERSET of the 
style/options. It allows you even to define whatever word, without 
the word being a regular facet field:


>> view [b: button options [ble: func [][print "huh?"]] do [b/facets/ble]]
huh?


I wonder if that might even be a security issue, to pass such a function 
via the options block? So - how is that options block even closely 
similar to what style/options is? Those two have completly different 
meaning/functionality :-)