World: r3wp

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

Steeve, that would defeat the purpose of buying a large screen so 
you can see more stuff. Used a spreadsheet lately? Graham, that can 
change the whole layout. If it autoadjusts, cool, but you'd at least 
need different layouts for languages that go in different directions.

I do no  say we don't need resizing

*not

well I think I'll restrict to languages that go from left to right

and are horizontal

It's not proportional resizing ONLY, if you want your elements to 
stay whey they were, you're free to do so.

Chinese used to be right to left and top to bottom... but I think 
they've changed

Is Arabic still right to left?

But the old way (fixing the corners to the container) is goog enough.

Graham: yes, but AFAIK, they write their numbers mostly L->R. Strange.

Our numbering system is based on the arabic one ...

yes, but it seems, that the origins of the system go back to Babylon

I also want a combination of proportional resizing for scale, and 
expanding sections for size. Fot instance, an iPhone 4 has a higher 
resolution screen than a Droid, but the Droid's screen may be larger. 
So I want to both scale to higher resolutions on platforms that support 
them, but make use of more physical space when available, as needed. 
I don't want my menu/ribbon to expand to fill more of the screen 
unless I am going to be further away from it.

Not to Babel ?

Yes, R->L. I'm tired today :)

Wasn't the babylonian system base-60? Or was that someone else?