Feel free to use this representaion instead:
{#ComposableSpec. #add:. {{#ComposableSpec. #add:. {#(#model #browseModel).
#layout:. {#FrameLayoutSpec. #fractions:offsets:. (0@0) corner: ((1/5)@1).
(0@0) corner: (0@0)}}. #add:. {#(#model #sendersModel). #layout:.
{#FrameLayoutSpec. #fractions:offsets:. ((1/5)@0) corner: ((2/5)@1). (4@0)
corner: (0@0)}}. #add:. {#(#model #implementorsModel). #layout:.
{#FrameLayoutSpec. #fractions:offsets:. ((2/5)@0) corner: ((3/5)@1). (4@0)
corner: (0@0)}}. #add:. {#(#model #versionsModel). #layout:. {#FrameLayoutSpec.
#fractions:offsets:. ((3/5)@0) corner: ((4/5)@1). (4@0) corner: (0@0)}}. #add:.
{#(#model #dropListModel). #layout:. {#FrameLayoutSpec. #fractions:offsets:.
((4/5)@0) corner: (1@1). (4@0) corner: (0@0)}}. #checkSplitters}. #layout:.
{#FrameLayoutSpec. #fractions:offsets:. (0@0) corner: (1@0). (0@0) corner:
(0@25)}}}
Goodluck
Ben
On Oct 12, 2012, at 1:49 PM, Henrik Sperre Johansen wrote:
> On 11.10.2012 23:11, Benjamin wrote:
>> On Oct 11, 2012, at 11:04 PM, Pavel Krivanek wrote:
>>
>>> Unfortunately it is not only about a layer between Morphic and Spec.
>>> Whole Spec design is greatly conforming to Morphic. Check out Spec
>>> definitions, they look almost like transcription of Morphic calls
>>>
>>> MethodToolbar class >> defaultSpec
>>> <spec>
>>> ^ { #Panel.
>>> #changeTableLayout.
>>> #listDirection:. #rightToLeft.
>>> #addMorph:. {#model. #browseModel.}.
>>> #addMorph:. {#model. #sendersModel.}.
>>> #addMorph:. {#model. #implementorsModel.}.
>>> #addMorph:. {#model. #versionModel. }.
>>> #addMorph:. {#model. #dropListModel.}.
>>> #hResizing:. #spaceFill.
>>> #vResizing:. #shrinkWrap. }
>> This is because this method is out dated, it shold be now
>>
>> ^ SpecLayout composed
>> newRow:[: r |
>> r
>> add: #browseModel;
>> add: #sendersModel;
>> add: #implementorsModel;
>> add: #versionsModel;
>> add: #dropListModel ]
>> height: 25
>>
> And this seems even worse, tbh.
> No longer does it seem to be a literal array which some interpreter
> translates into an abstract model (One bad thing about the first version, as
> Pavel pointed out, it wasn't very abstract), nor is it a pure DSL for
> creating abstract models, but some weird amalgam of the two.
>
> Now, I DO like creating my interface by hand in a DSL (which can then be
> instantiated in myriad ways), and such a thing seem to me to be needed
> anyways for the datamodel of a literal array representation interpreter, so
> why not start with that, and add the parser of a literal array syntax for
> specifying the same DSL later on?
>
> Not saying you need to reinvent ToolBuilder, but the underlying idea
> certainly wasn't as bad an idea as some seem to think :)
>
> Cheers,
> Henry
>
