Hi, On Wed, Jan 1, 2014 at 3:59 PM, Stéphane Ducasse <[email protected]>wrote:
> > On 01 Jan 2014, at 15:02, Stephan Eggermont <[email protected]> wrote: > > > The point I apparently failed to make is that I miss the abstraction > above the widget level. > > With Spec you have the same as in VisualWorks. You have applicationModel and you specify the logic that you can reuse > with plain Smalltalk. Glamour does it with a component model, event and a DSL full of blocks. > Interesting comparison. It sounds to me as if this "component model" is a bad thing and that VW is a gold standard when it comes to describing user interfaces. Also, when you say DSL you refer to the way the Smalltalk API was design to read like sentences, which might sound like it goes against the tradition of Smalltalk. As for blocks, some would go as far as considering them to be plain Smalltalk :). I think a more detailed comparison would be more useful for newcomers. So, here is one. First, the block issue. The funny thing is that if you want to build a dynamic browser with Spec you have to rely on blocks, too. Take a look at an example from Ben: --- m := DynamicComposableModel new. m instantiateModels: #( button ButtonModel list ListModel). m list items: #(1 2 3 4 5). m button label: 'Plip'; action: [ self halt ]. m openWithSpecLayout: (SpecLayout composed newColumn: [: c | c add: #list ; add: #button height: 26 ]; yourself). --- Glamour is actually written in plain Smalltalk, and you can simply use subclassing, too. For example, something like this: GLMCompositePresentation new with: [ :a | a list display: [ :input | 1 to: input ]; act: [ :list | self halt ] entitled: 'Plip' ]; openOn: 42 Could be done like this: "Define a list presentation with an action in distinct classes to make blocks disappear" GLMGenericAction subclass: #MyPlipAction instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'AAA'. GLMListPresentation subclass: #MyListPresentation instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'AAA'. MyListPresentation compile: 'displayValue ^ 1 to: self entity'. MyListPresentation compile: 'actions ^ {MyPlipAction new}'. MyPlipAction compile: 'actOn: aPresentation self halt'. MyPlipAction compile: 'title ^ ''Plip'''. "Use the list" composite := GLMCompositePresentation new. composite add: (MyListPresentation new). composite openOn: 42. I doubt the blocks are an actual issue. Using blocks has the advantage of more compact code, but it is true that it comes with a price: when you store the block you cannot edit its code live while debugging (you actually can do that, too if you take care). The main difference between Spec and Glamour is actually conceptual: the application space. Spec addresses widgets: with Spec you place widgets on a "canvas" and handle the interaction. So, in a sense, this places Spec at the same level as Morphic. Glamour is at a higher level and it is specifically dedicated to supporting browsing workflows. In its current state, it is not useful for laying out widgets, but it can be very concise for expressing browsers. The way this works is via this "component model". Essentially, a browser can be described as a set of components that can pass data to each other. Glamour lets you model that. It so happens that the inspector and the debugger are browsers and can be expressed at that level. It also so happens that most user interfaces that programmers use can be expressed as browsers, too. And Glamour was actually validated for hundreds of various browsers (literally), so it seems it can support a large set of use cases. If you want to learn more about Glamour you can read the chapters from: - http://deepintopharo.org, or - http://www.themoosebook.org/book/internals/glamour If you want to see where Glamour fits within Moose, you can read this post: http://www.humane-assessment.com/blog/moose-custom-analyses-made-easy Doru -- www.tudorgirba.com "Every thing has its own flow"
