World: r3wp

Pekr, regarding your

lay: [

		when [load] do [print "Load trigger!"]
		clicker
		button "Do" alert "Button pressed!"

  button "Big Quit Button" maroon options [max-size: 2000x50] quit
		bar
		text "Toggle button..."
		t1: toggle "Toggle" of 'tog
		button "Set False" set 't1 false
		button "Set True"  set 't1 true
		toggle "Mirror" attach 't1
		toggle "Mutex" of 'tog
		bar
		text "Radios and check boxes"
		radio "Set above toggle on"  set 't1 true
		radio "Set above toggle off" set 't1 false
		bar
		check "Checkbox attached to above toggle" attach 't1


]

child: make-face 'vpanel []
set-panel-content child lay
view child


example - it is incorrect, since you try to give VIEW a HPANEL instead 
of a WINDOW, I suppose, that it was just a test, how it would look?

Yes, it was a test, to isolate the example form layout from the demo 
....

Pekr, since you are passing the FACE object as argument to VIEW, 
currently, it jsust shows what you pass.

I thought that gob, panel, are directly "viewable"

So in your case the example should look like:

lay: [
	backdrop [
		<your layout here>
	]
]
okno: make-face 'window reduce/no-set [content: lay]
view okno

what is 'window type? I remember from the past, that it was stated, 
that just "view lay" simply adds lay into the panel, which is just 
- implicit?

Every face is 'directly' viewable but it won't resize always correctly 
unless you don't comply to the resizing rules

It just should be - easy ... or the directly viewable face is - useless 
...

In the current VIEW code the FACE arg case is simple low-level stuff. 
But we could use th AS-IS refinement for this current behaviour. 
If you don't specify /AS-IS then the passed FACE will be wrapped 
into the appropriate window sturcture as it is in the VIEW block! 
case.

Is 'window type just a panel? Or special window gob?

If WINDOW would be just a panel there won't be need for that WINDOW 
style no? :) Anyway, the WINDOW is the base style which controls 
all the content.
The structure looks like:
WINDOW [	; this is the main container GOB
	BACKDROP [ ;renders solid background under the content
		<your layout>
	]
]

and if I don't specify backdrop? Aha, so window is not just anonymous 
parameter to make-face, but a regular style?

yes, window is a style

btw - I don't like the name make-face, to make a window, which is 
a special style. We have:

make-panel
make-face
make-style


in the above case, window, is a widget for me. I really don't know, 
if we have terminology OK here. I simply don't regard instantiated 
style, being a face? Or is it aligned correctly?

We have: make-panel

 - wrong, you do not have any make-panel, I thought you read that 
 above

You do have just MAKE-FACE, which makes a face for you, as specified

yes, but I still don't understand it. My latest understanding is, 
that this function is going to be overhauled? Or - should I forget 
it exists, regard it being an internal function?

Forget to use it at all

ok, so what paramters make-face uses as first argument? Can I use 
any style name? E.g. make-face 'button?

You need to specify the style of the face you need to create

Of course, only existing styles (styles you, or someone else defined) 
can be used

So basically I can create instance of any style? If so, then heck, 
it is more flexible than I thought :-)

Yes, it is

I initially thought only 'hpanel, 'vpanel is possible, and that it 
is only for panel :-) Well, now I am cool with make-face :-)

I simply don't regard instantiated style, being a face?

 - why not, if we "borrow" the class-based OOP terminology, then styles 
 may be considered analogies of classes, and faces may be considered 
 analogies of instances (objects) of their styles

Why following works:

child: make-face 'window reduce/no-set [content: lay]

while following does not?

child: make-face 'window compose/deep [content: [(lay)]]

Here, the latter works as well

This one should work too:

okno: make-face 'window compose/only [content: lay]

Pekr, using only the MAKE-FACE for making faces was a step for simplifiing 
things. No need to know any other functions for that.

** Script error: button has no value
** Where: make make make-face catch either either -apply- do

** Near: make styl/facets opts options: make object! any [opts []] 
ta...

You need to show the code, for me it works

sorry, my last example should have been:

child: make-face 'window compose/only [content: (lay)]

lay: [button "OK"]
child: make-face 'window compose/deep [content: (lay)]
view child

ah, my bad :-( I miss the enclosing block to lay

you need to use either the one you wrote:

child: make-face 'window compose/deep [content: [(lay)]]

,or the one I wrote

can you pass an object to make-face?

the style has to be specified as a word, if that is what your question 
was about

it was the data argument, instead of fiddling with composing a block.

Aha, you meant options? They can be supplied as #[none] meaning "no 
options supplied", or as a map! as well

but not an object?

not currently, do you want to have such an alternative as well?

you should use a map when you don't like a block

I don't see why not. I think there would be plenty of advantages 
in allowing objects as face options. They are easier to build, store 
and configure than blocks.

If it's not against some security aspects, then I support Henrik, 
and such alternative could be added. You can decide priority for 
yourself, I am not pushing for it ...

The reason we didn't allow object! for options was the 'inconsistency' 
of:
make object! object!
vs.
make object! [block! | map! | none]


in R3. We might add support for object!s but it will make the function 
a bit more complex.

I am against it, when:

- maps are available
- no convincing reason exists

As long as you can do at least the same with maps as with objects, 
then it's ok. I'm focusing on ease of building, storing and configuring 
potentially very large options for faces.

You can do more with maps - e.g. remove fields

ok, then I retract my request.

Pekr, any news about porting the Carl's gui demo ?