World: r3wp

Is the change planned for the next release?

Yes.

#[[Pekr:

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

Pekr:]]


Could you please write it down in a form understandable to mere humans?

I would especially like to know what do you want.

Something like "does not work for me" may be understandable to some 
supernatural beings with mind-reading capabilities, but, being a 
mere human, I am lost.

How about this, would you prefer such a result?

view [hgroup [label "name: " field return button button button]]

yes, this is what I would expect, if I would don't know about panel 
implementation internals (cells)

you wouldn't be able to align labels and fields correctly below eachother, 
as far as I can see

you mean without cells?

in R2, I just do:

stylize [lab: label right]

view layout [across lab "name: " field return lab "last name: " field 
return button button button]

What's the r3 equivalent to align to the right? :-)

In R3 you would have several possibilites, depending on whether you 
want to align the label text or the label itself.

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.