World: r3wp

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?

E.g. one of the examples in the gui-panels.txt

do you guys have an html version of that?  I don't have mdp setup.

no html needed when you just need to copy a part of it and do

...and, it is not mdp

seems to work good, nice work.

thanks

Ladislav: ""I can see you use empty rows...Aren't we wasting memory 
here?" - how can an empty row waste memory?" - :-) This is misunderstanding 
:-) My question relates to my previous discussion with Cyphre, about 
removal of 'faced element. Previously, we had facets, and faced (instance 
locals). Cyphre pointed out, that now everything is instance local, 
and goes into facets. If you want stuff to be shared, new 'intern 
slot should be used.


And that was my question - I can't see intern used anywhere in the 
stlyle definitions. What I noticed is, that in the facets blocks, 
stuff is somehow visually separated by empty rows. Hence my question 
- if I see things like min-size, max-size - aren't those a good candidate 
for items being shared? And if those are not shared (referenced), 
we are kind of "wasting" memory here. I think that it will not be 
significant though ...

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

 - not a big deal, really. My problem is, that what I want is behaviour 
 of panel style, but without gfx borders. But - I could create new 
 style, removing the visual elements of panel. Maybe such a style 
 could be added by default, but not sure others would find it usefull, 
 nor do I know what name to use ...

Well, empty rows in the source code are just means to organize the 
text anyway ;-)


Regarding your MIN-SIZE and MAX-SIZE - those aren't shared, since 
I thougth (and still think), that it is necessary to allow for every 
face to have individual MIN-SIZE and MAX-SIZE

Example: it is expectable, that two panels have different MIN-SIZE 
and MAX-SIZE, especially if their contents differ

Really? E.g. think about buttons. I think that all buttons will share 
those values, no? But anyway - this is just speculation on my part, 
and call for "premature optimisations". In fact I don't know how 
to measure memory consumption (even if we have stats function) of 
an object, which has two more fields (slots) plus values. Then you 
can count average number of instances your app has, and you can guess, 
how much more memory your app is going to use. I expect it being 
just KBs ....

Of course, some styles might "prefer" to use the same MIN-SIZE/MAX-SIZE 
for all their faces, but it is not a general property.

(as demonstrated for panels)

Ladislav - did not read all your posts here, but as you are here, 
and for me to proceed - how do I "easily" create panel, if I have 
layout stored in a block? Carl's demo uses:

view-sub-panel: funct [
	index
	main-pan
	desc
][
	set 'current-panel index
	set-face desc form pick test-notes index
	pan: pick test-panels index
	unless pan [
		pan: make-panel 'group pick test-blocks index [columns: 1]
		poke test-panels index pan
	]
	switch-panel main-pan pan 'fly-right
]

his

 make-panel used three values. OK, options block is not needed, nor 
 supported right now. Function attributes are now reversed (dunno 
 why, the argument order is not compatible with make-face for e.g.). 
 That is still easily fixable. But now "rma's" make-panel accepts 
 face, not dialect block. I tried to use make-face on a dialect block, 
 but no luck ....

I simply need to fix this line: "pan: make-panel 'group pick test-blocks 
index [columns: 1]", if possible. Henrik suggested that the aproach 
is different, and that I should use 'content functions, which I know 
nothing about yet.

Maybe such a style could be added by default, but not sure others 
would find it usefull, nor do I know what name to use ...

 - yes, that is possible. The difference between original, Carl's 
 implementation, and the new one is, that you have all the box model 
 attributes accessible, so you can do it easily now on your own.

re min/max-size, here's my take. I don't mind having both, not a 
big deal for me. But - when I tried Carl's examples back then,I tried 
on my nice Samsung FullHD TV. I maximised the screen, and wondered, 
why the heck fields don't resize properly. Then I found out, that 
their max size was set to 900 pixels. I asked Carl - why? And he 
told me, that fields should not be long, or it does not look nice 
anyway. So - as I know myself, my intention for max-size for the 
years to come will always be to cover FullHD displays. But as you 
can see, then it is artificial - I will simply use values, just to 
avoid effect I had with Carl's example.


As for min-size - I was negatively surprised by its removal, because 
I wanted panel of certain min-size to be displayed. But - I found 
there is new item, called initial-size, which fixed the situation 
for me ...

btw - can someone confirm the rendering "bug" with simple example? 
I can see the black box next to "test" text, which is transparent, 
and I can see underlying window content.Resizing causes redraw, and 
corrects it. It still should not happen imo though ...

view [hpanel [text "test"]]

And he told me, that fields should not be long, or it does not look 
nice anyway.

 The problem is that you can't solve the maximum size restriction 
 issue of a nice-looking interface, by using a MAX-SIZE at the style 
 level. Such a problem would be at a higher layout level and much 
 easier for the UI designer to solve at the layout level. There is 
 simply no reason to have it.

yes, and R2 does the same btw... strange

(that was a reply to pekr)

Regarding the

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

code, you should be good with:

	unless pan [
		insert-panel-content/pos/no-show test-panels compose/only [
			pan: hpanel 1 pick test-blocks index
		]
	]

sorry, forgot the paren:

	unless pan [
		insert-panel-content/pos/no-show test-panels compose/only [
			pan: hpanel 1 (pick test-blocks index)
		]
	]

and the index:

	unless pan [
		insert-panel-content/pos/no-show test-panels compose/only [
			pan: hpanel 1 (pick test-blocks index)
		] index
	]

aha, insert is probably not good, since it does not replace the previous 
content - well, the problem is, that change does not work for gobs 
yet, so you need to remove and insert, until change is corrected 
for gobs