World: r3wp

I am still not sure I am comfort with group having different semantics 
to panel :-( .... trying to do some tests with Carl's demo, and it 
is going to be pain-in-the a..., to insert returns in there. From 
the very beginning of the R3 GUI projects my opinion was, that group 
should be just de-stylised panel (no visual borders), but identical 
in behaviour ...

I hope I will change my mind later in the proces ....

Hmm, but then we would probably loose flexibility of different layout 
model if those two were identical ...

rendering/refresh bug -  view [vpanel [text "test"]] ... I can see 
the content of underlying window next to the vpanel ....

I can see, that along the min-size, max-size parameters, we can now 
set init-size parameter. Why was option to set max-size removed from 
panel? Because resizing system does take care for that? I also noticed, 
that make-panel can't anymore accept options block. So you found 
it not being necessary?

btw Pekr, from an API designer's standpoint, these types of questions 
are all very good  IMHO.  they force us to reflect on decisions and, 
often, trying to do so will either confirm them or with discussion 
might give new ideas.   I'm not part of this gui team, but I'd really 
like if someone asked pointy questions like this on my stuff.

(I'd really like == I really like it)

those come from concrete effort to make Carl's demo translated to 
the new GUI engine  :-) First and second screen is displayed, but 
make-panel just differs, and options argument does not exist anymore, 
it also has reverse order of arguments, and does not accept style, 
but face instead, and so on ...

are you supposed to use make-panel?

Henrik, when switching panels, there's following function I need 
to adapt:

	unless pan [
		pan: make-panel 'group pick test-blocks index [columns: 1]
		poke test-panels index pan
	]

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.