World: r3wp

- 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 :-)

Ladislav - let's not just take it personally :-) For me, and as you 
can see, it is a good experience to experiment with the GUI, as I 
am gaining some internals knowledge. I published the tickets for 
RMA team to consider the consequences, and it is up to you, to react 
accordingly. So - if you guys feel that it is ok, then just dismiss 
the ticket, ad the comment there, and it will server for future GUI 
users as a knowledge base, that's all ...

pekr, short story: you want the OPTIONS word in the layout block 
to be FACETS instead?

- style/options does NOT clearly define, what options user can set 
in dialect options block

 - yes, I wrote that above, style/options specify just the inline 
 options (different context). Since you did not get that, what you 
 would need instead would be to rename them to style/inline-options?

Henrik - short answer - I would like to have it aligned, but - the 
naming is tricky, as I like dialect level options word. Hence my 
second proposition was to rename face/options to face/inline-option, 
but that stil does not describe, that dialect level options "maps" 
to facets ... So so far I am not sure, how to resolve this, I just 
pointed it out ...

This is part of Carl's original design and I imagine that he made 
the idea of "slots" as you call it, so there is a simple way to map 
grouped areas of code to faces, when they are created. Note in the 
source, the definition of a style and a face are right next to eachother. 
So it becomes "how do I create a face from a model of a face, as 
quickly and easily as possible?"

The source is gui-object.r3

What Ladislav proposes is interesting, because it leads my thoughts 
even further, and then my concepts probably break anyway :-) Imagine:

style [
options: ; renamed facets
inline-options:
]


Because then writing "button "OK" options [field: value]" could lead 
users to think, that they are directly setting facets (options, if 
renamed), which is not the case either, as there is an abstraction 
in between the options and its mapping to facets. Besides that I 
think, that Carl would surely not like to give-up on facets name 
(although for me as non-englishman) the word has not meaning, although 
I know it exists in vocabulary ...

So, what he does is create an object that contains "slots" that are 
relevant to the style, and then another object with "slots" that 
are relevant to the face.

But, otherwise, I do not see any urgent need to do any renaming, 
since in button 50x20, hardly anybody would have any trouble understanding, 
that the 50x20 value is an option user is allowed to specify, similarly, 
as any option in the Options block...

slots, fields, attributes, parameters, options ... so many words 
to choose from :-)

Yes, no problem if explained - just my thought chain was - how is 
that I can see some values being specified in an options block in 
a dialect level, which I can't see defined in style/options? That 
is all. If documented, maybe no confusion is going to happen. And 
maybe - not all ppl will think the way I was ...

You named them "slots" first, so that was the word I use, but the 
words you use there are distinctly different. because this is an 
attempt at creating a sane interface for the face. In VID, you didn't 
have that. There was one single object and it was flat, and therefore 
could become large.

IMHO, if OPTIONS in layout were to go, I would replace it with WITH.

the WITH word was used before, but, I guess, that Carl found the 
OPTIONS word more acceptable, otherwise he would have continued to 
use the WITH word, in my opinion.

IIRC, I recomended the word OPTIONS to Carl back then :-¨)

Then OPTIONS in the style object should perhaps be ARGS or PARAMETERS.

args, params .... you can write your thoughts to the CC ticket, if 
you like. I expect it staying the way it is though :-)

btw - any new release around the corner?

Today

reactors have ARGS too

I would not mind, if style/options would be renamed to args or params. 
And if it will unify with reactors, then - why not? I know that other 
pov might be, that those really options, just inlined. So - you can 
have RMA voting, as now you imo clearly understand, why I had the 
problem with the recent naming. Maybe you will decide that it is 
fine as it is, it's your GUI after all :-)

It depends. I'm sure that everyone is interested in new names (that 
make sense) that take less typing. :-)

rebols - obsessed with the naming being right :-)

ARGS and PARAMS are ugly abbreviations of technical words. If the 
problem is that OPTIONS do not map directly to options in the face, 
it seems that WITH was the better name :-)

USING comes to mind too, but then WITH is probably nicer, and "compatible" 
with VID :-)

release date: Cyphre will not be available to commit a new release, 
and some scroller, etc. changes are on the way, so, the release will 
happen on Monday or Tuesday

naming: we have to be mindful with reactor names as well, because 
they exist on the same level as OPTIONS.