World: r3wp

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?

Pekr, we don't have cascade styles...do you think this would be worth 
doing?

I am not sure what exactly you do mean? The ability to inherit or 
redefine particular parts of the style?

BTW you can do it for one panel this way for now:

label-right: [align: 'right]

view [
	hpanel 2 [
		label "name: " options label-right field
		label "last name: " options label-right field
	]
	hpanel [button button button]
]

Guys - to make it obvious - I can find out the way of how to make 
things work. I was just curious, if mine example could be done in 
some easy way. I hope you don't take it as a complaint.

Cyphre - your method is OK with me, with just a small note, that 
I would welcome the option to have borderless panel in the case of 
buttons in your above example ....

But everything is solvable ....

cascading styles: I meant you could write for example:

stylize [
	#my-panel label [
		facets: [
			align: 'right
		]
	]
]

view [
	my-panel: hpanel 2 [
		label "name: "field
		label "last name: "field
	]
	hpanel [button button button]
]

hmm, interesting :-) I am curious what others think. It kind of adds 
another level of possibilites into the system, but maybe it makes 
it a bit more complicated too? :-)

borderless panel: we are working on a feature that makes the box 
model configurations easier to use

cascadign: that's how CSS works with HTML

Hmm, I can't imagine, how should it work? Because on the low level, 
there is just a face, and a gob. So how do you internally distinguish, 
if the panel is separate, or nested in my-panel, and hence needs 
to use different styling?

the implementation id different topic...the question is though: do 
we need such feature?

id=is

It depends - I would welcome more broader input here. But I am not 
sure much ppl will contribute here :-(

anyway, this is not hi-priority at the moment...just something to 
think about.

The reason why I might be interested in inmplementation detail is, 
that maybe I will be style author too, and hence I would like to 
know, how things get complicated in the low level. So in your above 
example - what does stylize do? Does it create internally named label 
style, to keep its visual configuration somewhere? And then during 
the layout phase, you would have to check on nesting, and use  those 
internal styles in the low-level?

There are two concepts, which might be helpfull (maybe it is one 
concept?):


1) having the same style in various sections of your GUI styled differently


2) having the option to style differently the same style in the same 
level (that can be done by options)