World: r3wp

Claude - I understand what you mean, but I am also glad, that things 
are finally moving forward :-)

;-) justo

Posted 5 shots:

http://rebol.hmkdesign.dk/files/r3/gui/212.png


from 212 to 216. I think they need some explanation from either Ladislav 
or Cyphre.

yes, nice boxes, and? :-)

Claude, it took 2 weeks not because nobody was working on it, but 
because it was really tough problem.

well, they resize really nicely.

so it is a mixture of original Carl's VID model, plus some new alghoritms?

btw - is there still the need to define max-size for the style? :-)

Pekr: nice boxes, and? ... MAGIC! That's the holy grail of resizing, 
you just don't see it.

Reminds me of Mondrian :)

Mondrian indeed. :-)


What does the code look like to define sizing behavior, or is this 
still all low level and will be wrapped in VID++?

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)