World: r3wp

Also, the size of the face structure is not at question. It hardly 
eats any memory, a few bytes at worst.

Studying GUI I have following psychological problem - I never know, 
what possible elements it might contain. The problem is evident, 
when you create style using stylize. Even Carl was aware of that, 
and e.g. for actors he created comments, so that user know, what 
argument it takes. Looking at various styles, I always wonder, if 
I can make any facet I want, or is there any MEGA FACE object, containing 
all possible fields? :-)

e.g. look at button facets:

	facets: [
		init-size: 28x28
		bg-color: 80.100.120
		border-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
		face-width: none
	]

There is no limit to what facets you can create, but facets are inherent 
to the style as tools for storing intermediate information for draw 
blocks, states, etc.

so many colors above. I wonder if draw blocks, containing drawing 
info, should not contain static varialbe definitions? E.g. focus-color 
relates only to the draw mode, when button is in focus.

So you want to create additional contexts, such as SIZE? Then you 
would have size/init instead of facets/init-size. Is that what you 
mean?

I am not sure, just brainstorming loudly. I can as well push my brain 
to accept the fact, that face/facets is a junk block, containing 
whatever you want ....

we should at least segment the code by empty lines

And now you introduced another group of settings:

			;turn auto-sizing on		
			init-hint: 'auto
			min-hint: 'auto
			max-hint: 'auto

btw - I am not sure "hint" is a good name? I know term hinting, being 
related to fonts. But - above is the way - group values together, 
add comment, use empty line as a separator from other group of settings 
...

By creating new contexts, we would have to have an advantage to using 
them. In a way, I don't mind it, as it could be used to apply particular 
groups of facets, in a standardized way, so you know that a particular 
context will have these items. But FACETS does technically not prevent 
this. From a technical perspective, I'm not sure I can find an advantage, 
since there is no difference from R3's perspective on speed or efficiency 
in accessing size, color or hinting information.

However, I can see the following groupings or contexts:

- color
- hint
- size

hint and size would be standardized map!s, as they are used by the 
system.

you would have to access them by path, not sure how it would look 
like in the source-code, as in draw block? e.g. pen color/pen-color?

you would say: color/pen. not much difference in typing.

yes

if you look into box model, items are grouped too (well, because 
they contain identical field names). Anyway - you have another food 
for thought, I am just not sure if it would help the understanding 
or clarity of the code, it depends ....

btw - when I met Ladislav, I asked him, why there is a face/gob, 
and face/facets/gob, and he was not sure it is like that IIRC. Later 
on I checked it, and it is really like that. But I don't remember, 
if he gave me an answer - are those identical gobs? Why I am seeing 
them in two places, when I mold the face?

Yes, they are two identical gobs a the reason why it's also in facets 
is binding for draw block.

a=and

so in memory it exists just once?

yes

with prior gui, I could see 'draw-results, or something like that 
in the structure. Was it removed? What was it good for? :-)

I am not sure, but I think it's result from translating draw dialect 
to draw commands, this will be simplified later.

Pekr: 'btw - I am not sure "hint" is a good name?' - actually, yes, 
since the INIT-HINT is a hint (look up the word in the dictionary), 
how the algorithm should determine the INIT-SIZE value

(for a panel)

The 'AUTO hint just tells the algorithm to calculate the panel INIT-SIZE 
"automatically" (= using an algorithm) taking into account the panel 
contents. This means, that you, as a user, do not have to specify 
the panel INIT-SIZE, which might seem less comfortable to you.

Of course, if you know, what is the INIT-SIZE you want to have, you 
can specify it as well using a different hint.

'Yes, they are two identical gobs' - funny, that is a nice contradiction

In fact, you cannot have 'two identical gobs', you can have only 
one

R3 still hard crashes with the GUI :-( unreproducible ....

I have a question towards the aproach to design a form. Following 
code does not work for me (result-wise):

view [hpanel 2 [label "Name:" field button "ok"]]


Simply put - button is on a new row, but it probably causes field 
to align to the right? Or more precisely - button extends the column 
cell, and so the field is pushed to the right in an undesirable (albeit 
expected) manner. Should I put buttons supporing the form out from 
the panel containing fields?

you use panel style, so you've got 2x2 grid. "ok" button is simply 
on 1x2 position and 2x2 position is empty. If you don't want grid, 
use group style.

I don't like the group style :-)

why is that?

the group style is not for forms

I am just not sure. What I am still confused about is the different 
semantics of particular styles. I wonder, if there could be just 
panel-like semantics, so I could use:

hframe 2 []
hpanel 2 []
hgroup 2 [] ; with no need for return keyword


But that would be limiting to the group style, as it has no cells 
- each row is separate IIRC ....

That's why there's different semantics.

But my above example is some food for thoughts. When I think of forms, 
I know that form might be enclosed in some pane (being it group or 
panel or frame I don't care - just visually separated from the background). 
Then it usually contains pairs of labels and fields. Btw - in R2 
it was easy to right-align label - is that possible with R3 GUI? 
And I think that some buttons belong to the form - e.g. Edit, Submit, 
Cancel, and some might belong to the Window.

So the question is, how do I get button visually together with labels 
and fields, not influencing my design? Put buttons into subgroup 
or subpanel?

yes, buttons should be in a subpanel

Does not work for me:


 view [hpanel 2 [label "name: " field hpanel 3 [button button button]]]

The nice thing is, that I do know, what it does not work, and I do 
know that the behaviour is correct, it is just - undesirable ... 
:-)

Yes, there's support for alignment. I'm not how much of it is currently 
accessible, but you should be able to align cells in panel.

hgroup for buttons does not work either, because that group is part 
of the first cell of the second row ...

you want the button panel outside the other panel.

Pekr, it works exactly like it should.

(don't be distracted by the visual frame. this will change, so you 
will have better control of what is visually framed)

That is what I asked - if I should put buttons outside the first 
panel? But philosophically - that does not work

Maybe not philosophically, but technically it's perfectly working.

Rebolek - don't drag me in that discussion - I said, that I know, 
that it works like it should. But I also said, that the result is 
undesirable for me ....