World: r3wp

Nice Anton!

REBOL[]

scroll-pane: make face [
    color: red

    set-bounds: func [ offset [pair!] size [pair!] ] [ ; why not be called?
        print "$"
    ]
]


Window: make face [
    offset: 30x30
    pane: reduce [ scroll-pane ]
    feel: make feel [
        detect: func [face event ] [
            switch event/type [
                resize [
                    print "%"

                    Window/pane/1/set-bounds: 0x0 Window/size/x / 2
                    show Window
                ]
            ]
            event
        ]
    ]

]

view/options Window [ resize ]

; After resizing the window, only the "%" can be printed. Why set-bounds 
in the scroll-pane is not called?

Error is here:
Window/pane/1/set-bounds: 0x0 Window/size/x / 2
should be:
Window/pane/1/set-bounds 0x0 Window/size/x / 2

Thank you Anton. I am so embarrassed. I should not make such an error. 
Not like this.

That's alright :) We all do it.

Yup. Made that kind of mistake plenty of times.

Here's a document (using LAYOUT spec) which tries to explain a proportional 
resizing algorithm.
do http://anton.wildit.net.au/rebol/doc/resizing-algorithm-doc.r

And here's a demo implementation: A HPANEL style implements the algorithm 
(additionally with wrap) and you can play with it by dragging with 
the mouse:

do http://anton.wildit.net.au/rebol/doc/proportional-resizing-example.r

what exactly does the demo do?

Did you try click and drag with the mouse near the bottom of the 
window ?

yeah .. the window resized but nothing inside the window changed.

Click in the window.

It resizes the HPANEL, which then distributes the space inside itself 
to its subfaces.

Oh .. got it!

I am interested to know if people think it's a good system or not, 
with the four limits.

anton, what is the advantage of having hard-min, min, max and hard-max?

Gabriele, the four limits create, in between them, 3 zones where 
the available space is distributed proportionally. Having three zones 
allows the faces to behave differently depending on whether space 
is at a premium, whether there's an "normal" amount of space, or 
whether there's lots of available space.

(Has anyone ever seen a proportional sizing system with different 
zones like that ?)

The example faces in the demo are a bit abstract from reality, so 
I'll come up with some real-life examples...

hmm, I think if you are resizing proportionally the space between 
elements can be also distributed proportionally so no need to care 
about it? But maybe I just didn't get it so looking forward to some 
examples ;)

Yes, looking at it again I realise it's too abstract like this :)

Just fixing up the demo so it's easier to change the subfaces.

(Can't upload for some reason... must go to sleep, until tomorrow...)

A more concrete demo will help, but it's a cool demo none-the-less. 
:-)

anton, Glayout already does this and much more...

and again, its VID based.

GLayout really is only a stylesheet.

with extra hooks included in window managers and stuff.  you hpane 
is the same concept as my hgroup...

if you'd put a little time you could very easily put your vid styles 
within GLayout and benefit from all of this done and debugged for 
the last 2 years... I am using it commercially.

the looks are just a VID skin, you can very easily change that...

Ok, uploaded a new version

do http://anton.wildit.net.au/rebol/doc/proportional-resizing-example.r

the wrapping is neat :-)

So, starting small and increasing the size, you can see the buttons 
have a "compressed" state (hard-min), and they stay compressed until 
the location field reaches its min-size, which is the size at which 
the field has "enough" room for most normal location strings. So 
the field has reached its "preferred minimum" size.

Increasing further, the buttons expand to have enough room on either 
side of their text for some nice visual padding, but they don't need 
to get any wider. It is preferred for the field to get all the space.

Maxim, the problem for me with GLayout is the "and much more...", 
if only because it will take me longer to understand it.

its very simple, really...

but I do understand your point.

I think it's better to be modular. But anyway, maybe you could make 
a small demo which shows how each of Glayout's parameters work:

min-size, def-size, init-def-size, manual-min-size, static-size, 
elasticity, stretch... and any other I do not see.

although having someone like you on the wagon would help cleanup 
GLayout itself... Using it for myself has ironed out many little 
issues in the latest week... I've added some new facets like margins...

as I see your demo I see how these two approaches are similar, in 
many respects.  although I don't have a preset max size...

the way GLayout is built is that it just adds a few hooks where you 
can implement the calls themselves.

the actual attributes are style specific.

so you could implement your hpane directly within GLayout, but you'd 
have an automatic way to call the resizing, for example...

but anyways, I understand that at some point we'd have to get a few 
hours so I could explain (and then document the discussion) on the 
basics of those hooks.

Well, for a start -  replace/all read %glayout.r "self/" ""

I've already implemented henrik's toolbar in about one hour

and added a pop up to select icon, or text or both right on the toolbox 
 ;-)

those are details to improve readability.

you are free not to use self in your own code... but I can say that 
the 1 micro second which is spent  to look up a few hundred self/ 
 is nothing when compared to displaying 20x20 pixels of draw.

just ONE field with a linear fill in AGG, I have discovered, will 
bog down the whole display!

in normal view we don't notice as much because its static... but 
when you start adding dynamic resizing and real time scrollpane movement... 
its just sooo slow ... so much that I added a property in the field 
to remove all the prettyness!

so that large GUIs didn't become unuesable.