World: r3wp

frame name works better for me than box-model, although it suggests 
a bit - frame - yes or no? frame-type would be more descriptive, 
but longer. I would be ok with frame, frame-type (mode), draw-mode 
- all better than box-mode imo ....

as for alignment - from html I do remember align="left | right | 
center" .....

I would go for EDGE, like VID, if you are to implement such a feature.

alignemnt - really - go to example #35, write down all variants on 
paper, forget the visual representation you are provided with, and 
just draw it on the paper out from your head. I bet you will make 
a mistake. And align + valign is not understandable for me at all 
....

Henrik - whatever name might work. As for EDGE - this is yet another 
term though. EDGE was regular facet in VID though, and in R3 it is 
replaced by BORDER, no?

I think the edge/frame/border usage is a little confusing. EDGE was 
a standard feature for every face in VID and it was fixed how it 
worked. In R3, an edge would be implemented on the DRAW level and 
could basically mean anything, including what it means in relation 
to the box model. This is why I'm still advocating a special FRAME 
style, which in *one* place, settles the meaning and the appearance.


Furthermore, a FRAME could be required for any type of face, be it 
a form with many fields, a compound of faces or groups of compounds 
of faces, which need to be surrounded by a pixel accurate frame, 
like in the example below, which I had trouble defining properly, 
when I experimented with skinning:

http://94.145.78.91/files/r3/gui/162.png


I had problems with it, because it had to be part of COMPOUND, and 
yet, certain COMPOUNDs would not have a frame and certain other panel 
types would also require the frame, but not be a compound. It is 
just much simpler to have it in a separate style.

but how would you define, what layout engine should be used? We have 
two, no? panel, and group ... and their respective vertical vs horizontal 
variants ...

The question is, if we can please all users. Some will like borderless, 
backgroundless clean style. Some might want frame around the panel, 
and I can imagine users wanting just a bit different color or gradient 
to distinguish the panel from the surrounding.

#[[Pekr

Does drawing the surounding frame (or simply parametrisation of one 
of style visual) has anything to do with the term "box model"?

Pekr]] - surely it does, the box model specifies that, and other 
properties

#[[Pekr
frame name works better for me than box-model

Pekr]] - it does not for us, since that way, you would be limited 
only to one of the box-model aspects

Ladislav - I know, but imagine user will just want above mentioned 
variant - panel, which will be distinguished by a bit brighter bg 
color, not a drawn frame.

Pekr, by only allowing a single face (with any number of subfaces) 
inside such a frame style, layout would not be an issue.

What do you mean by box model aspects? margin, border, padding, content?

Henrik - aha, so you mean that FRAME would be special face type allowing 
to create various surroudings upone certain face? So that it would 
containt panel, or group? That might work ...

But of course then - we have altready those facilities for all faces 
- a box model, where's the space to draw any borders,etc. Well, we 
could say then, that FRAME is special decorative kind of style. The 
question is, if it would not be overused by uesrs, putting even buttons 
inside of FRAME, to have a decoration? :-)

Pekr, "That might work" - precisely. :-)

You don't need special enclosing face if you can use box-model for 
it and draw in the border.

Ladislav - box model/frame is not much of an issue for me. I think 
that worse problem for me is how currently resizing is behaving in 
above mentioned styles, and all that align examples and its naming 
- very confusing.

align and valign are pretty standard names if you've ever seen HTML, 
what's so confusing about them?

#[[Pekr
And align + valign is not understandable for me at all ....

Pekr]] - right you are, you should see the code to understand what 
the text means. In short, it means, that the HALIGN and VALIGN properties 
are set somehow, instead of using the default values, that are 'LEFT 
+ 'TOP

everything. Have YOU ever seen  html?

as I said - in html align = left | right | center ...

can you please explain to me, why the align + valign aligns left 
red box vertically in reverse position than signle align?

err, I meant: "ALIGN and VALIGN are set somehow, instead of using 
the default LEFT + TOP setting"

ALIGN + VALIGN does nothing

their values do

aha, now I look into the code - makes much more sense now. Then it 
is about the description in the demo, which confused me

ALIGN can be: LEFT CENTER RIGHT

as opposed to left right center... ;)

It is in the documentation

ok, my question towards the align, valign. I know we might want to 
be "compatible" to html, but to stay consistent - we have vpanel, 
and hpanel, not vpanel and panel. Wouldn't it be wise to use valign, 
halign too?

ok, got to go. So the only yet unexplained part to me is that of 
a resizing. As Rebolek hinted, it might be caused by the text being 
resized. It is just, that with examples I mentioned, the result is 
(of course IMO) not a desired one.

Regarding Henrik's FRAME note - that is a surprise for me, never 
heard about such a proposal, and disagree with it.

E.g. try also panels-26.r3 - why the last line of boxes stays "attached" 
to the bottomof the window, causing a space?

If you will say, that it is explainable by how the resizing model 
works, then I might reshape the question and ask how to avoid it?

#[[Pekr

I think that worse problem for me is how currently resizing is behaving 
in above mentioned styles

Pekr]] - resizing is behaving as it should. The problem is just that 
Bolek specified that the vertical size of the text is "unlimited" 
for resizing purposes. That is causing the layout to look ugly.

Ladislav, I discussed it a few days ago, but not to worry. Rebolek 
disagrees too, so it probably won't be done. My worry is that the 
act of creating a border or frame around a style will be an obscure 
part of a base style.

#[[Pekr

E.g. try also panels-26.r3 - why the last line of boxes stays "attached" 
to the bottomof the window, causing a space?

Pekr]] - that is an example "inherited" from Carl, and it behaves 
as it should, taking into account, how it was defined. You need to 
take a look at the code

#[[GiuseppeC

I have ran the latest RE-GUI and the examples. I have see that when 
the CHECK is off the "v" is still visible but greyed.

GiuseppeC]] - you are not the only one who dislikes this. Count me 
in.

#[[Henrik

My worry is that the act of creating a border or frame around a style 
will be an obscure part of a base style.
Henrik]] - you need not worry, it already works for all styles

Ladislav, we'll see.

No, you already can see it *is* implemented.

No, what we don't have is many varied types of compound styles, where 
this would be used. That is why I'm not convinced.

Used how? As I said it already *is* implemented.

Used for multiple compound fields, calendars, for example.

I don't understand where you see any problem.

We have also not shown that text-table can place widgets with pixel 
accuracy.

But never mind, it probably won't be really relevant until skinning 
starts.

As for example #26, I checked by adding following line to stylize:

    pad: pad [facets: [bg-color: orange]] 


So Ladislav is right, code behaves correctly - the last line of color 
boxes is shifted to the bottom by upper 'pad style resizing.

We here to help you, Pekr, we don't understand why you resist us.