Trust me, even with the nicest formatting, it's not something that you want to read, or to write...
Here the formatting is bad because this code is generated by the SpecLayout object. Ben On Oct 12, 2012, at 2:40 PM, H. Hirzel wrote: > What about proper formatting? :-) > > --Hannes > > On 10/12/12, Benjamin <[email protected]> wrote: >> 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 >>> >> >> >> >
