World: r3wp

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

Henrik - what is planned then in that regard? New frame style, and 
new panel style?

I have to look into some forms in some other apps, how they do solve 
visually buttons belonging to form ...

GROUP and PANEL would by default not create a frame. Derivative FRAME 
styles would create a frame.

how they do solve visually buttons belonging to form

 - when this works correctly, you will be able to do any visual combination.

Rebolek, something that bugs me though is spanning multiple cells. 
Is this possible?

in PANEL style?

yes

or will there be a different solution of inheriting cell-sizes across 
multiple panels? this is for forms where label width is necessary 
to be identical for multiple form parts, such as 4 column forms or 
forms separated vertically by full-width spanning parts.

Henrik - so you want to be able to merge cells? Hmm, not sure it 
would not be difficult for Ladislav to count into the engine? :-)

I don't know how difficult it is to do, but it seems like a necessity 
to me in such cases.