ProportionalLayout not so suitable for Drag-and-Drop?

I have been playing with drag-and-drop and layouts,
and noticed that TableLayout seems to have much better
support for drag-and-drop than ProportionalLayout.
Are there other LayoutPolicies that I should take
a look at?

Stephan

On 09-07-2015, at 11:43 AM, Stephan Eggermont <[hidden email]> wrote:

> I have been playing with drag-and-drop and layouts,

You might get something useful from
a) http://wiki.squeak.org/squeak/6194, and
b)http://wiki.squeak.org/squeak/2141

Whatever you find out - please update any relevant pages on the swiki. We *really* need improvements in so many places!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
You can swear at the keyboard and it won't be offended. It was going to treat you badly anyway

Yes, proportional layouts are difficult to update when dropping an object into the hierarchy. If you take a look at how proportional splitters work, you can see that they tweak the #offset property of the adjacent layout frames.

There is only the TableLayout left, which fits better for adding morphs into the respective container on-the-fly.

You might want to take a look at the layout policy that I use in Vivide:
https://github.com/hpi-swa/vivide/tree/master/repository/Vivide.package/ViConstraintLayout.class
(It also needs #boundsInOwner: from https://github.com/hpi-swa/vivide/tree/master/repository/Vivide.package/Morph.extension/instance but should work in Squeak 4.6 without Vivide.)

It provides interactive layout configuration and automatic scaling.

Here is an example:

m := Morph new.
m layoutPolicy: ViConstraintLayout new.
m topLeft: 0@0; extent: 100@100.

m addMorph: (Morph new
        topLeft: m topLeft;
        extent: 30@30;
        color: Color random).

m addMorph: (Morph new
        topLeft: m topLeft + (50@50);
        extent: 30@30;
        color: Color random).

m openInHand.


Best,
Marcel

On 10-07-15 14:34, marcel.taeumel wrote:
> Yes, proportional layouts are difficult to update when dropping an object
> into the hierarchy. If you take a look at how proportional splitters work,
> you can see that they tweak the #offset property of the adjacent layout
> frames.

Thanks, I'll take a look.

> There is only the TableLayout left, which fits better for adding morphs into
> the respective container on-the-fly.
>
> You might want to take a look at the layout policy that I use in Vivide:
> https://github.com/hpi-swa/vivide/tree/master/repository/Vivide.package/ViConstraintLayout.class
> (It also needs #boundsInOwner: from
> https://github.com/hpi-swa/vivide/tree/master/repository/Vivide.package/Morph.extension/instance
> but should work in Squeak 4.6 without Vivide.)

That looks like a more workable layoutpolicy. Thanks.

Stephan

Best,
Marcel