World: r3wp

sorry, several = two

yes, this is what I would expect,...

 - I am sorry, but you cannot expect HPANEL to behave like HGROUP, 
 that would not make any sense at all

I guess, that what Pekr wants is just to be able to align the label 
text to the right

BTW, you can make a similar layout using hpanel as well. Are you 
able to do it, Pekr?

a similar layout
 = "a layout similar to the one I described above using HGROUP"

Ladislav - I will have to think about the challenge for a while, 
let me think :-)

Rebolek says, it should now be changed so that TIGHT, GROUP and PANEL 
no longer draws any frames, as this is relegated to higher level 
FRAME styles.

how will one name - frame - cover all tight, group, panel?

or will we go for something like hfpanel, vfpanel? :-)

HPANEL [] - no background, no border
HPANEL #FRAME [] - same as current hpanel

same for all other panel styles

is it a good idea to use issue! ? it will collide with build scripts.

uh, what?

So we have got new way of how to parametrise stuff in the dialect 
level? Not sure about that

Nevermind, Pekr.

besides that, # should be reserved for accelerator keys, no?

Ah, you don't like it? I was really afraid you will.

I don't like anything new :-)

Which doesn't prevent you from wanting something new all the time 
:)

Yes, but the outcome is often imo rushed, like the above one :-)

Anyway, this change wasn't submited yet, so it can be changed still.

It needs more thoughts. We could as well use options [framed?: no], 
but then I would scream, that I want to have it in the name of the 
style directly :-)

exactly.

hmm, I still have to think about all the skinning/material system. 
Just brainstorming, not able to foresee the consequences. So we have 
all those colors, draw blocks (multiple), gradients as a materials. 
I wonder - could we thought about the way style is being drawn in 
terms of a state/material?

I mean - what we are after is having tight, panel, and group being 
just displayed in a different way, no other change of functionality, 
no?

I think we should be rather careful about adding skin options directly 
in layout. It is really not meant to be there. Once we go there, 
we can't go back and we'll be back in the old VID face hacking mess.

In the case of 

hpanel [] options [framed?: no]

I think that someone might want to create a shortcut:

stylize [hpanel-frame: hpanel [] options [framed?: no]


... so in the end ppl would try to come up with new name anyway? 
Just thinking lound, not having particular preferences here, but 
still not sure about #FRAME, as it introduces new way of how to parametrise 
the style?

what's new about it?

Henrik - it is not about adding them into layout. You can as well 
add it to the options block, which is part of the layout too. It 
is simply about following aspect - are we able to have just ONE style, 
which draws borders, or it does not? Does not it create many variants 
for draw blocks, or other complication for material system, etc.?

Rebolek - we don't use # to further parametrise any other style. 
In the past it was reserved for the accelerator keys ....

I would rather have a specific HFRAME, a style that explicitly is 
created for visibly framing elements. This means you can tag it separately 
and it's easier to skin, because you don't have to create multiple 
draw blocks for a single style that is meant to do one thing. The 
end result is less complex.

ok, got to go to the meeting ...

Henrik - HFRAME, ok - but does it behave like a panel, or like a 
group? And how do you name it, if you want to support all variants? 
hpanel, hgroup, tight?

ok, HFRAMEGROUP perhaps. I don't know.

Alternatively, we have a FRAME style where you put GROUPS and PANELS 
inside.

Sorry, but that's really bad idea, using two style for it when it's 
supported internally.

I don't know if it is a bad idea, because the combinations would 
be fewer for what kinds of frames you want and you avoid cluttering 
GROUP and PANEL styles. You could say that FRAME supports only one 
face inside it to avoid deciding on flow.

I don't see a single reason why frame should be separate style when 
the border can be drawn very easily inside each style.

You will have N styles for N variants of grouping and panels. Then 
you will need N + N styles in total to cover proper framing of all 
styles. With FRAME, you only need N + 1.

and you will need to skin them all, as opposed to one style.

or one option.

in all styles :-)

you're wrong, that option is only in one style, all other styles 
inherit it.

I think you will clutter the base style with things it's not supposed 
to do. This will be dragged along inherited styles.

And, what about tagging? How do you discern a visible frame from 
an invisible one, in case we decide that skins should rely on tags?

tagging is good. But it is just another way of how to make options. 
Other is regular facet fields ...

Tagging is neither facets nor options. They are information that 
usually relates to the GUI system to describe the state and capability 
of the style.

To Pekr - here is a layout you might not know how to lay out:

stylize [lab: label [align: 'right]]

view/options [
	hpanel 2 [
		lab "name: " field
		lab "last name: " field
	]
	hpanel [button button button]
][break-after: 1]

correction:

stylize [lab: label [facets: [align: 'right]]]

view [
	hpanel 2 [
		lab "name: " field
		lab "last name: " field
	]
	hpanel [button button button]
]

but, this is somewhat "indirect", and it should be possible to do 
otherwise

as for your examples - this is method I used before. I thought that 
you might find a way of how to do it in terms of just one panel, 
which is not imo possible?