Benjamin wrote:

This is currently not supported, but now that the adapters are here, it should be easier.

A workaround now would be to implement your own MorphicContainerAdapter
and to have your own bindings

Ben

On 09 Nov 2013, at 19:48, btc@openinworld.com wrote:

How might I get behaviour like TableLayout [1] with Spec.  This is for laying out a variable number of icons in a Command Toolbar, that when the width is reduced the icons wrap around to a second line.

[1] http://pharo.gemtalksystems.com/book/LanguageAndLibraries/GUI/PolymorphTutorial/TableLayout/

cheers -ben

Okay, what would you call such a new class? MorphicTableContainerAdapter ? Will that naming conflict with the new Table/Grid widget you indicated in another thread you were going to work on? Could that be called a Grid rather than a Table? Or do you have another preference for naming MorphicTableContainerAdapter ? e.g. MorphicTabularContainerAdapter, MorphicFlowContainerAdapter or another?

So it seems that that MorphicContainerAdapter is referenced only from MorphicAdapterBindings as #ContainerAdapter, which itself is referenced only from ContainerModel class>>defaultSpec. ContainerModel is referenced as 'type' from SpecLayout>>initialize and SpecLayout class>>composed, with the 'type' of the latter overwriting the former. So that would seem to be the link in point as...
    SpecLayout class>>tableComposed
      ^self new
          type: #TableContainerModel;
            yourself
(Do you have any other naming preferences? e.g. #composedTable or another preference) ?

The other references to ContainerModel from MonticelloRepositoryBrowser, WorkingCopyToolBar, CheckboxExample & DropListExample would seem irrelevant to my cause. However I don't know what to make of SpecIntepreter>>computeSpecFrom: aSymbol selector:.   Will that require any consideration in creating a new MorphicTableContainerAdapter ?

cheers -ben