World: r3wp

1) make-panel does not accept third options argument anymore
2) the first two args are reversed

3) make-panel does not accept block (style) anymore, but a face object 
- I don't know how to do this one yet ...

I simply need to make a block with layout elements a face. Trying 
with make-face, but make-face accepts two arguments - style name, 
and options, I don't know what should I submit for the name ...

I translated it into:

	unless pan [

  pan: make-panel make-face 'vpanel (pick test-blocks index) 'group 
		poke test-panels index pan
	]

why make-panel reversed arguments? It is now different to make-face 
in that regard. Carl's version accepts the word argument first.

It should be either put back, or make-face should change argument 
order too ...

I changed it to:

	unless pan [

  pan: make-panel make-face 'vpanel (pick test-blocks index) 'group 
		poke test-panels index pan
	]

But something is "not bound" ... I get following error:

** Script error: when has no value

** Where: make make make-face unless view-sub-panel do switch -apply- 
apply if f

oreach if do-face switch do do-bind-actor actor all foreach do-style 
set-face sw

itch do do-bind-actor actor all foreach do-style case do-event do-event 
do-event

 either -apply- wake-up loop -apply- wait do-events if view catch 
 either either
-apply- do

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

hmm, I go the wrong way ... make-face serves different purpose, not 
to insert layout into panel ....

Guys, please don't remove help string from functions (make-panel) 
....

I think switching panels is much simpler than you're trying here. 
Try looking at the source for tab panel.

make-panel is an internal function.

you made it so ....

the interface was really nice:

make-panel: funct [
	"Create a panel from layout dialect block and options block."
	style [word! none!]
	content [block! none!] "Contents of the panel"
	options [object! block! map! none!] "Options of the panel"
][

and you made it:

make-panel: func [
	face [object!]
	layout-type [word!]
][

not commented, func instead of funct, removed options, reversed arguments, 
and made it accept face instead of the layout block. You should not 
excuse something by just stating - don't use it, it is just internal 
function ... what if I want to use make-panel?

I don't think you want to. The point, I think, is to use the CONTENT 
functions.

My question still persist - how do I easily create a panel from a 
layout block? :-) Instead of one nice funcitons, which served well, 
I need to study  different concept, and make-panel is generally not 
usefull to average mortal :-)

OK, I'll continue tomorrow ... I can see content fields - dunno so 
far if it is kind of equivalent to R2's pane, or what ... need to 
find content handling functions ....

uhhh,enough for today :-) "set-panel-content face get-facet face 
'panel-face" - I need pizza, to get back some imagination :-)

hmm, I don't know why, but I don't like those long name functions 
as set-panel-content. I already disliked it in Rugby times. Too much 
function variants. Sometimes I think, if REBOL does not have something 
wrong. I thought that set-panel 'param 'value or set-panel/refinement 
could be a better way, but maybe it is not. I miss some level of 
better functionality encapsulation from time to time. We can't use 
set-panel, as it serves for setting of its content ... I probably 
prefer old-school object panel.method aproach ... that is just a 
philosophical note, not a complaint to R3 GUI :-)

trying to do some tests with Carl's demo, and it is going to be pain-in-the 
a..., to insert returns in there

 - that is an error, the group style is not the style Carl had, so 
 you should not do that at all

The style Carl named group was just a kind of a hpanel, with its 
box-model characteristics adjusted to not have a margin, IIRC

I can see you use empty rows...Aren't we wasting memory here?

 - how can an empty row waste memory? For example, I use empty to 
 make something like 'paragraphs' to group code parts that are somewhat 
 "related". E.g. if I resize a panel, the 'paragraph' resizing lines 
 precedes the 'paragraph' resizing columns, which is followed by the 
 'paragraph' resizing subfaces.

In general, if you don't want to use the RETURN keyword, don't use 
the *group styles, they are designed *for the purpose* of supporting 
the RETURN keyword

MIN-SIZE and MAX-SIZE of panel - currently, those values are computed 
by the updating software. Do you think we should allow the user to 
set these? When you think this should be allowed, and for what purpose?

I also noticed, that make-panel can't anymore accept options block.

 - because you are not supposed to use the function at all. Use the 
 MAKE-FACE function.

Never use the MAKE-PANEL function

The MAKE-FACE function makes panels as well as anything else.

MIN/MAX-SIZE: I'm not fond of the idea of having the ability to set 
certain style variables in too many places. That said, setting them 
in styles rather than in layout is a decision that is hard to predict 
the outcome of, when using the styles in different layouts. I never 
really liked MAX-SIZE, but I suppose we can't get rid of it.

Why I'm not fond of it: We return to face hacking like VID, which 
encourages poor layout design.

MAX-SIZE is totally necessary, if you want to have a resizing algorithm 
respecting the MAX-SIZE attribute.

...and that is what Carl insists on

(the other variant is to not have any such attribute allowing unlimited 
magnification...)

none of my algorithms have max-size and its never been a problem 
in any layout I wanted to do.

though it can be usefull .

Then, that is the reason why Carl would never accept your algorithms 
(my original version did not have it either)

though there is nothing stoping me from adding it to a specific frame 
variant within my stuff.  I've just never found it to be that usefull. 
in general, when you want max-size, actually what you want is static 
size.

(for a layout fragment)

Are you sure?

Did you try some of the panel examples?

the problem with max size is scaling the extra-space.  it never ends 
up scaling, quite right.  its better to have some of the things static 
which leaves space for the "space benefiting" areas.


then, whatever would need a max-size, should have a manual resize 
bar (which might be blocked so  but doesn't require support in the 
actual layout)

what I'm saying here is not about capacity, its just design philosophy.

preventing something to resize bigger is always frustrating to me, 
in any software.

the problem with max size is scaling the extra-space.  it never ends 
up scaling, quite right.
 - again, did you see some of the examples?

I haven't had time to play a lot with the latest R3.  though my notes 
are general in nature.

I've never, ever found MAX-SIZE useful for anything, because it doesn't 
fit intuitively in a layout situation, where there are much simpler 
means to produce a similar result. I suppose it makes sense for Carl 
in his old resize system, where MAX-SIZE was (shudder) tied to weighting, 
which produced some completely unpredictable results.

MIN-SIZE makes perfect sense, though.

yes, its actually required, there is no way to design resising without 
it.

Well, relating MAX-SIZE to weithting was a bad idea, and we corrected 
that.

I haven't had time to play a lot

- then don't, just pick one example, try to resize the window, and 
see how it works.

what examples?