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 >> > > >
