World: r3wp

Piet ? http://en.wikipedia.org/wiki/Piet_(programming_language)

I hope it does not make VID code to look bad, and that most of the 
behaviour is kind of "hidden" ...

No and yes. I'm not sure, why you're so afraid this must be bad somehow.

http://rebol.hmkdesign.dk/files/r3/gui/212.png- this is a layout 
using a PANEL style, elements are layed vertically, (in columns), 
center-aligned, having different (randomly adjusted) sizes

NO to bad code and YES to hidden behaviour

I agree Petr. And while we still may not *need* and IDE, we should 
consider how one would be built that allows you to easily set anchor 
and sizing behaviors.

Congratulations, and thanks, to the team!

(Henrik why you don't use alt-print instead of  manual cropping the 
image ?)

aha, sorry, I swapped 212 and 213, actually, the above description 
belongs to 213, 212 is layed out horizontally (in rows)

Is 212 vertical or is 213?

:-)

We're afraid because we've see some of these before, and they didn't 
turn out well. Specification dialects that don't require much specification 
and are easy to understand, make and maintain are preferred. If you 
were able to show us some layout dialect source with the resize specification 
markup, it would help a lot.

It's very exciting though. I want to see it in action.

Agreed :)

214 - vertical layout, in which all elements happen to have the same 
transversal size

(good to test the resizing accuracy)

Davide, much harder actually, since I use virtual box on a mac. :-)

Yes, that's what 214/215 seemed suited for.

Problems would show up very clearly.

what I don't understand for the gui is, what panel and group are 
layered in different directions - vertical vs horizontal :-) (unrelated 
to resizing)

that is a principle, you can have layouts defined with the horizontal 
direction being the "major direction", or the vertical direction 
being the major direction, the former ones are groups, the latter 
ones are panels

216 is a more special layout in respect to resizing. It is defined 
so, that it can be resized only horizontally, and only the first 
and the last element are allowed to change their sizes when being 
resized. (that is something you cannot define in RebGUI as far as 
I know, neither it was possible in Carl's resizing algorithm, afaik)

It was possible for Carl's original, but awkward. Don't remember 
if you could limit window sizing in Carl's original.

yes to "possible" in that you were allowed to specify it, no to "possible" 
you could obtain what you wanted

Well whai I wanted was a non-awkward, minimal specification method, 
so a definite no to that. How's the dialect on yours?

Dialect is not fixed yet

Ah. What are the factors in your algorithm? The semantic model is 
what I'm interested in.

The problem with Carl's original was that it was a good idea but 
it didn't work. That's fixed now.

Thanks to Ladislav and Cyphre.

So, similar factors to Carl's? Size and max-size, group and panel?

yes, max-size is still there.

But, are you saying, that you could get a picture like 216 being 
scaled so, that the two boxes in the middle do not change their sizes, 
while the first one and the last one do so, that the boxes remain 
next to each other all the time?

(Cyphre was pretty sure, it was not possible)

I am not asking about the math - I trust you and Cyphre to make the 
math absolutely perfect. I am at the moment asking about the semantics 
of the resize model

yes, but I was asking, whether that layout was possible, expressing 
the opinion it was not, but I may be wrong, of course

I don't like max-size, but the way it's done now, I think, that it 
can be omited from style-writing and R3/GUI can take care of it. 
But that's just a guess right now. There's now code to support my 
guess.

factors: min-size, max-size, group, panel

now=no

It was theoretically possible with Carl's resize model - ignoring 
whether the math worked - but it was really awkward to specify. That 
is my main concern.

Rebolek, actually you are wrong, you cannot define layouts with elements 
having max-size/min-size without having a direct support for these 
features (maximally, you can get some "ugly approximations", but 
surely not the same behaviour)

The main problem with Carl's resize model was that it was difficult 
to specify proportional scaling independent of max-size. This made 
layouts fail on unexpectedly large screens, or made it necessary 
to put in a lot of very large numbers in max-size.

That dependency does not exist in the new resizing model

Well then that is really good news :)

And, yes, that was a motivation for me to invent something more convenient

I know I'm wrong regarding the min-size, but not the max-size.

I just think  proportional resizing feature is the problem. It's 
usually useless and hard to code.

re language support .. I think primarily faces have to adjust for 
different lengths of text

when you translate from one language to another

Hard to code, yes. Useless, no, not unless you're on a fixed-size 
screen.

Proportionnal resizing without font resizing has no use, IMO.

Well, Steeve, you do not have to use it, but it will be available 
in case it is needed