World: r3wp

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

In R3 GUI, style names themselves act as classes, where in HTML you 
have a fixed set of tags that need to have classes. IDs are set-word!s, 
so there is no need to add any superfluous layer to identify specific 
faces.

Henrik, not quite.


using CSS you effectively "tag" your gui and then you can apply effects 
to multiple types of things which match a tag or pattern.

a tag is a cross-cutting concept, not a family or class/type  like 
concept.

OK, let's say set-words can simulate IDs, then Rebolek is correct, 
sorry.

yup, Rebolek was right.

Maxim, this is necessary in HTML, because of the fixed naming of 
HTML tags. set-words in the R3 GUI do this.

But - it might be a bit different anyway. If you make b1: button, 
it is a set-word, a name. And now how do you use stylize, to refer 
to such a name? Stylize creates new style name, e.g. b1, but that 
is direct name for the style itself

in combination with style names, that is.

Pekr, you don't stylize a singel face. you stylize a style and then 
create an instance of that style as a face.

Henrik - but then ID != set-word

no henrik, its a completely different thing.  you can use a class 
name for completely different classes.


a button and an paragraph can share the same class name.   and you 
can then affect them both in the same way.

stylize [
   b1 button []
]

view [b1] differs to view [b1: button]

so classes are neither types nor serial IDs.

(in html)

Pekr, you are mixing up two things. The style name is not affected 
by the face name.

yes, class in html is just an 'group-id'

classes in html/css really act as associative tags.  

in GLASS I am using #issue to simulate html class="label"

Maxim, I was talking about IDs, not classes.

though this is just something I've played with its probably going 
to stick, and multiple tags will be applicable to any control.

ok, I guess I mis-interpreted the angle of one of your replies  :-)

Henrik - ok, so to be clear - show me possible stylize definition 
of a button variant, and how you refer to it in the layout code?

I suggest that classes in the R3 GUI is not useful for the reason 
that it interferes with the "intelligence" layer, where we already 
have:


1. tags to identify state and capability of a face, such as finding 
the default button in the window or whether the button is disabled.
2. name to identify a specific face

3. style name to identify the style and to create a distinct appearance
4. the ability to group faces by panels

5. have information about the ordering of faces stored in the face 
tree

6. use specific policies on how to act on a particular face with 
particular tags

(good feature list. We should keep this.)

Pekr:

stylize [my-button: button [facets: [text: "Pekr!"]]]

view [my-button]

Henrik - you see? I just wanted to have a "button" inside of view, 
and by change of stylize parameter, to change some aspect of the 
button. But I might be mixing few things together. In your above 
example, my-button is a class. So your saying that in R3 GUI, classess 
are not usefull, is an incorrect statement, as we already do have 
classes? Or what you would call your 'my-button then?

ad 1. I have a feeling, that we incorrectly mixed two things. TAGs, 
in my vocabulary or understanding, are "categorisation" elements. 
As for "state", there should be FLAGs, no? :-)

The feature list is not complete, we miss - 5a. ordering of faces 
for tabbing purpose

There is a slight discrepancy in the syntax of stylize and view. 
Not saying, that they should be identical, just a food for thought:

stylize [my-button: button [facets: [text: "Pekr!"]]]

view [
   b1: my-button
   b2: button options [text: "Henrik!"]
]


1) 'Stylize could theoretically use the same syntax as 'view? So 
the code above could just be:

stylize [my-button: button options [text: "Pekr!"]


That would make it more (almost) compatible with the layout definition


2) Currently set-word inside the stylize defines a new style (class), 
whereas a set-word inside of 'view, defines a face name = ID. There 
is no simple way, of how to resolve that, maybe something like:

stylize [
   my-button: button options [text: "Pekr!"]

   button options [text: "Henrik!" name: b1] ; no set-word, so probably 
   a problem syntaxwise. We simply can't style particular named face?
]


view [ my-button b1: button] ; b1 kind of simulates ID, inherits 
from stylize definition


Of course, it all depends how far do we want to go. We can introduce 
completly different semantics to the stylize function, even a complete 
selector behaviour from CSS, if there is a need ....

So your saying that in R3 GUI, classess are not usefull, is an incorrect 
statement, as we already do have classes? Or what you would call 
your 'my-button then?

 - A style is not a class in the HTML sense, where you can apply a 
 particular class to any tag.

I just wanted to have a 

button" inside of view, and by change of stylize parameter, to change 
some aspect of the button." - the method I posted is exactly what 
you need to do in order to allow such a change.

There is a slight discrepancy in the syntax of stylize and view.
 - there should be, since they are not the same at all:

stylize: func [
	"Create one or more styles (with simple style dialect)."
	list [block!] "Format: name: [def], name: parent [def]"
...

http://design.canonical.com/2011/03/introducing-overlay-scrollbars-in-unity/

the method I posted is exactly what you need to do in order to allow 
such a change

. Not sure - my idea was to use only "Button" name in the layout, 
not my-button, and diversify upon e.g. where the button is placed 
... but otoh even  in CSS/html, in most cases, you have to specify 
class or id, and hence my-button is kind of equivalent - you have 
to declare the special case. But - not sure all aspects of CSS are 
usefull to us.

I will be glad, if we have system, where I can easily style elements, 
and configure their parameters. I'll wait how you resolve the FRAME 
style or simply borderless PANEL, GROUP, etc.

stylize - thanks for explaining to me, that the function is different, 
because it is different :-)

the function is different, because it is different

 - it's different, because when you stylize, you make style objects. 
 when creating layouts, you are creating faces. faces and styles are 
 not the same kind of object.

what is the difference to state fields, in comparison to holding 
a value in the facet field? Are state fields meant to hold interim/computed 
values? Is there any usage rule?

guie/face: object [
	; Faces hold the state and options of instances of a style.
	style:   ; WORD!   - name of the style for this face
	facets:  ; OBJECT! - properties unique to this face
	state:   ; OBJECT! - state variables (not properties)
	gob:     ; GOB!    - graphical object(s) for this face
	options: ; OBJECT! - optional facet changes as specified
	tags:    ; MAP!    - tags for this face

	; NOTE: optionally extended in face creation with:
	;name    ; WORD!   - reference name
	;reactors; BLOCK!  - block of user actions

	; PANEL faces also add:

 ;trigger-faces; BLOCK!  - faces which reacts on triggers in panels
]

Cyphre - what will layout be good in next version? To preconstruct 
GUI, not displaying it?

yes, mostlt...but you should be able to pass LAYOUT result  to VEW 
function as well without any problem

=mostly

so we are going back to view layout [], or not necessarily, and layout 
is just a helper to prebuild a gui?

it doesn't matter what way you use...even if you use view [...] the 
equivalent of 'layout function must be called internally