World: r3wp

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.

But generally yes, for forms, I expect easily setting up pairs of 
right alighned labels, and fields. That has to be ultra easy, along 
with the ability to set some margin, but that should be workable 
via the stylize.


Henrik - I think that if you add frameless alternatives, then it 
is not a big deal ... I just have problem with current aproach, where 
subpanels create too many lines in the GUI :-)

Pekr, ok. Just ignore the lines and spacing between panels for now. 
The arrangement is not going to change.

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?