Re: [Pharo-dev] Spec & TableLayout

[btc]

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, b...@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