World: r3wp

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)

There are multiple ways how to doit....But If you are going to be 
style author you just need to know the syntax used in stylize command, 
nothing more ;)

ad 2) e.g. my example of having panel style, with borders, without 
the borders ...

re "I thought that you might find a way of how to do it in terms 
of just one panel" - it is possible to do it in "just one group". 
Do not forget, that R3-GUI H/Vgroups are more similar to R2 layouts 
than R3-GUI (H/V)panels.

I am trying to come up with usage cases here ....

I think (and maybe I am wrong), that even with VID we kind of had 
cascaded styles. If you needed different style configuration, you 
used stylize, and stored new config under different name, e.g. H1, 
H2, H3, LAB in above example, etc.


While CSS allows you to use just one name, and multiple styling set-ups. 
The question is here, how you identify it in the layout flow, what 
set-up should you use, and if it would be obvious. In CSS, you have 
ID, CLASS helpers ...

I mean "if it would be obvious looking into the layout source code"

Pekr, I think you are wrong here...I suggest to study for example 
this: http://css.maxdesign.com.au/selectutorial/

(especially the 'selectors' part)

I have not intention right now to burry deep into CSS, as I think 
I know enough to understand consequences. Your "you are wrong here" 
does not work for me :-) Wrong in what aspect? I still think, that 
I do understand how you style html pages :-)

By 'you are wrong' I meant your understanding whe 'cascading styles' 
really are is a bit blurry...if you check the 'selectors' section 
you'll see that this topic can be a bit more complex.

And the question still stands the same: Do we really need this? If 
so do we really need it all? If not what we really need? :)

CSS is clearly much more flexible in setups. You use tree of definitions, 
which are then applied in particular cases in document hierarchy. 
 If I am not mistaken, right now we don't have no easy way, of how 
to make e.g. first button in a last row of the panel e.g. red, unless 
you first define red button, and use it in the source of the layout 
:-)

If we need it? Who knows. Maybe not for the business graphics. Maybe 
so, if we would like to make model closer to CSS, from various reasons 
...

yes, no hi-priority at the moment...

Cyphre - I can simply imagine, how we extend stylize to allow such 
definitions. But - in terms of html, you have IDs, CLASSes, and you 
have also the document tree, so you might know, where to apply which 
part of an CSS. What I can't imagine is - we have layout flow ... 
and no ID, CLASS definitions, we also don't keep tree information 
of the layout (faces), or do we? So how do you instruct, in your 
layout, that first button in the panel should use button-red definition? 
Just curious about what possibilities there are :-)

why ID, when you can call face directly? And of course there's tree 
of gobs, that's how gobs works.

I've done a few quite complex CSS setups working with jquery, and 
at some point, CSS selectors become very brittle because the priority 
rules become a bit hard to properly prioritize.   


To reflect this, in some setups not all browsers actually match the 
same CSS selection rules.

Rebolek - what has an ID in common with the face name? Short answer 
- nothing :-)