- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Glamour vs Spec (was: towards moose in the pharo ide (gtinspector / gtdebugger))

by Tudor Girba

Hi Alex, On Thu, Jan 2, 2014 at 3:05 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > I think that one example Stef has in mind, is the following: > > GLMCompositePresentation new > with: [ :a | > a list > display: [ :input | 1 to: input ]; > act: [ :list | self halt ] entitled: 'Plip' ]; > openOn: 42 > > what is âaâ ? How one should know that âaâ answer to #list ? And that the > result understand #display: and #act: Removing block, could be something like: > > GLMCompositePresentation new > add: (ListPresenter new > display: [ :input | 1 to: input ] â¦ ) > "with:" is a pattern that you can implement on Object actually so that you can continue cascading an object without using a separate local variable. I prefer this construct specifically when prototyping. "a" is just a variable name :). Especially when used in conjunction with "with:", you can read it as a sentence: "composite presentation with a list ...". The same goes when reading in the context of a transmission:. browser transmit from: #x; to: #y; andShow: [:a | a list ... ] ==> "browser transmit That is all. Of course, you can also do it the way you say it. And it can be even more explicit: composite := GLMCompositePresentation new. list := GLMListPresentation new. composite add: list. Is this better? Perhaps, if you see this code only once. But, let's look at it from a different perspective. If you use Glamour, you will likely end up with many browsers. So, you want to have the code fluent, and you might also want to recognize the code when you see it. It's much like we did for Roassal/Mondrian. In Moose, the "view" variable is pretty much reserved for visualization builders, and when we see methods called *On: we know they refer to visualizations. This is a pattern that emerged. I see the Glamour API in the same way. Cheers, Doru > Alexandre > > > On Jan 2, 2014, at 10:40 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi Stef, > > > > Glamour does not overuse blocks any more than any caller to cull: does > it. And if you look closely now, you will see that the amount of arguments > have decreased significantly (you do not have to repeat the objects that > are passed in by the transmission for every block). But, blocks are not > essential in Glamour (and especially, if it really is a problem, we can > enforce the arguments). I just showed how you can simply not use blocks at > all for specifying widgets. So, my argument is that this "blocks worry" > isn't truly justified. And I also showed how Spec takes a similar approach > for scripting, but you do not see Spec as having the same problem. > > > > I am a bit troubled by your remark that the component model is not plain > Smalltalk. The component model has nothing to do with the blocks and it is > formed by plain objects: > > http://www.themoosebook.org/book/internals/glamour/architecture > > > > Could you explain? > > > > (please note that I am not picking up a fight - I would just want to > understand how people see these things) > > > > Doru > > > > > > > > > > On Thu, Jan 2, 2014 at 2:13 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > Doru > > > > You know well that Glamour has a component model that it not plain > smalltalk model. So why are you telling me I do not know what? > > Now you also know that Glamour overuse blocks with multiple optional > block arguments where the order is important. > > So I do not undersand why you are saying that. > > > > Stef > > > >> > >> 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" > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 2, 2014

Graph-ET Examples on Facebook

by Daniel Aviv Notario

Hi! Weâve just put online some example about GraphET. GraphET is about drawing charts, graphs and histograms. It is built on top of Roassal, to let the user enjoy all the different interaction with the visualization. GraphET may be loaded using the following incantation: Gofer new smalltalkhubUser: 'ObjectProfile' project: 'GraphET'; package: 'ConfigurationOfGraphET'; load. (Smalltalk at: #ConfigurationOfGraphET) loadDevelopment https://www.facebook.com/media/set/?set=a.566523986767536.1073741839.340543… Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 2, 2014

[Issue tracker] Help needed for reviews

by Marcus Denker

Hello, We have some issues ready that nevertheless need to be reviewed by humans: https://pharo.fogbugz.com/f/filters/45/Review We know that they do not make tests fail and even pass some code critic tests. But else? -> do they fix the problem? -> Is this a change that we can risk to do after code freeze? -> is the change good? Marcus

Jan. 2, 2014

Re: [Pharo-dev] Glamour vs Spec (was: towards moose in the pharo ide (gtinspector / gtdebugger))

by Tudor Girba

Hi Stef, On Thu, Jan 2, 2014 at 3:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On 02 Jan 2014, at 14:40, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Stef, > > Glamour does not overuse blocks any more than any caller to cull: does it. > And if you look closely now, you will see that the amount of arguments have > decreased significantly > > > good to know > > (you do not have to repeat the objects that are passed in by the > transmission for every block). But, blocks are not essential in Glamour > (and especially, if it really is a problem, we can enforce the arguments). > I just showed how you can simply not use blocks at all for specifying > widgets. So, my argument is that this "blocks worry" isn't truly justified. > And I also showed how Spec takes a similar approach for scripting, but you > do not see Spec as having the same problem. > > > I hope that we will remove the block from spec too. Because with a ui > builder you do not want to generate script but plain data. > Perhaps for Spec, this is an issue because you typically might end up with many widgets that you have to manipulate. However, for Glamour, you have usually much less precisely because it is higher level. I am a bit troubled by your remark that the component model is not plain > Smalltalk. The component model has nothing to do with the blocks and it is > formed by plain objects: > http://www.themoosebook.org/book/internals/glamour/architecture > > > In Smalltalk I have objects and messages not ports/connectors and > propagation. > Hmm, I think there is a misunderstanding somewhere. Glamour does not extend or modify the language. Pane, Port and Transmission are just plain objects that happen to describe the domain better. I think the discussion should be if the model actually describes the domain of browsers properly or not, and how we can improve it (there are several places that could be improved). I think that saying "Glamour is not Smalltalk" is misleading. There are many similar models in Smalltalk. Let's pick one: Announcement. They also link objects and propagate events. Are these different in essence? They are not. Cheers, Doru > Could you explain? > > (please note that I am not picking up a fight > > > ok > > - I would just want to understand how people see these things) > > Doru > > > > > On Thu, Jan 2, 2014 at 2:13 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Doru >> >> You know well that Glamour has a component model that it not plain >> smalltalk model. So why are you telling me I do not know what? >> Now you also know that Glamour overuse blocks with multiple optional >> block arguments where the order is important. >> So I do not undersand why you are saying that. >> >> Stef >> >> >> 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" >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 2, 2014

Re: [Pharo-dev] Glamour vs Spec (was: towards moose in the pharo ide (gtinspector / gtdebugger))

by StÃ©phane Ducasse

On 02 Jan 2014, at 14:40, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Stef, > > Glamour does not overuse blocks any more than any caller to cull: does it. And if you look closely now, you will see that the amount of arguments have decreased significantly good to know > (you do not have to repeat the objects that are passed in by the transmission for every block). But, blocks are not essential in Glamour (and especially, if it really is a problem, we can enforce the arguments). I just showed how you can simply not use blocks at all for specifying widgets. So, my argument is that this "blocks worry" isn't truly justified. And I also showed how Spec takes a similar approach for scripting, but you do not see Spec as having the same problem. I hope that we will remove the block from spec too. Because with a ui builder you do not want to generate script but plain data. > > I am a bit troubled by your remark that the component model is not plain Smalltalk. The component model has nothing to do with the blocks and it is formed by plain objects: > http://www.themoosebook.org/book/internals/glamour/architecture In Smalltalk I have objects and messages not ports/connectors and propagation. > Could you explain? > > (please note that I am not picking up a fight ok > - I would just want to understand how people see these things) > > Doru > > > > > On Thu, Jan 2, 2014 at 2:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Doru > > You know well that Glamour has a component model that it not plain smalltalk model. So why are you telling me I do not know what? > Now you also know that Glamour overuse blocks with multiple optional block arguments where the order is important. > So I do not undersand why you are saying that. > > Stef > >> >> 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" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Jan. 2, 2014

Re: [Pharo-dev] Glamour vs Spec (was: towards moose in the pharo ide (gtinspector / gtdebugger))

by Alexandre Bergel

I think that one example Stef has in mind, is the following: GLMCompositePresentation new with: [ :a | a list display: [ :input | 1 to: input ]; act: [ :list | self halt ] entitled: 'Plip' ]; openOn: 42 what is âaâ ? How one should know that âaâ answer to #list ? And that the result understand #display: and #act: Removing block, could be something like: GLMCompositePresentation new add: (ListPresenter new display: [ :input | 1 to: input ] â¦ ) Alexandre On Jan 2, 2014, at 10:40 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Stef, > > Glamour does not overuse blocks any more than any caller to cull: does it. And if you look closely now, you will see that the amount of arguments have decreased significantly (you do not have to repeat the objects that are passed in by the transmission for every block). But, blocks are not essential in Glamour (and especially, if it really is a problem, we can enforce the arguments). I just showed how you can simply not use blocks at all for specifying widgets. So, my argument is that this "blocks worry" isn't truly justified. And I also showed how Spec takes a similar approach for scripting, but you do not see Spec as having the same problem. > > I am a bit troubled by your remark that the component model is not plain Smalltalk. The component model has nothing to do with the blocks and it is formed by plain objects: > http://www.themoosebook.org/book/internals/glamour/architecture > > Could you explain? > > (please note that I am not picking up a fight - I would just want to understand how people see these things) > > Doru > > > > > On Thu, Jan 2, 2014 at 2:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Doru > > You know well that Glamour has a component model that it not plain smalltalk model. So why are you telling me I do not know what? > Now you also know that Glamour overuse blocks with multiple optional block arguments where the order is important. > So I do not undersand why you are saying that. > > Stef > >> >> 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" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 2, 2014

Re: [Pharo-dev] Glamour vs Spec (was: towards moose in the pharo ide (gtinspector / gtdebugger))

by Tudor Girba

Hi Stef, Glamour does not overuse blocks any more than any caller to cull: does it. And if you look closely now, you will see that the amount of arguments have decreased significantly (you do not have to repeat the objects that are passed in by the transmission for every block). But, blocks are not essential in Glamour (and especially, if it really is a problem, we can enforce the arguments). I just showed how you can simply not use blocks at all for specifying widgets. So, my argument is that this "blocks worry" isn't truly justified. And I also showed how Spec takes a similar approach for scripting, but you do not see Spec as having the same problem. I am a bit troubled by your remark that the component model is not plain Smalltalk. The component model has nothing to do with the blocks and it is formed by plain objects: http://www.themoosebook.org/book/internals/glamour/architecture Could you explain? (please note that I am not picking up a fight - I would just want to understand how people see these things) Doru On Thu, Jan 2, 2014 at 2:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Doru > > You know well that Glamour has a component model that it not plain > smalltalk model. So why are you telling me I do not know what? > Now you also know that Glamour overuse blocks with multiple optional block > arguments where the order is important. > So I do not undersand why you are saying that. > > Stef > > > 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" > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 2, 2014

Re: [Pharo-dev] Glamour vs Spec (was: towards moose in the pharo ide (gtinspector / gtdebugger))

by StÃ©phane Ducasse

Doru You know well that Glamour has a component model that it not plain smalltalk model. So why are you telling me I do not know what? Now you also know that Glamour overuse blocks with multiple optional block arguments where the order is important. So I do not undersand why you are saying that. Stef > > 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"

Jan. 2, 2014

Re: [Pharo-dev] Thank you for Pharo

by Marcus Denker

On 02 Jan 2014, at 11:49, Volkert Barr <volkert(a)nivoba.de> wrote: > > On 01.01.2014, at 19:26, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >>> I understand that community support is needed, and yes i am willing to help. As a first step i can offer my help to test pharo features, help to write test cases, write some example code snippets, open bug reports. But i am not sure what Pharo features or libraries i should put my focus on. Any suggestions where to dig in? >> >> Excellent! >> Thanks. I suggest that you focus on what you like or what you want to learn and do it step by step. >> Stef >> > I would like to understand ui and graphics programming in Pharo. I have found different ui related libraries, but not really understand how > they all relate to each other, what their purposes and what will be "part of" future Pharo Versions and what not. > This is not that easy. For example, some of these things are not libraries but just âSystemCategories full of random stuffâ. > Spec Specifying UIs, layer on top of Morphic (but the goal is to be in depended) > Glamour >From Moose > UIManager Random package, not nice. Needs love. > Polymorph Partly new widgets, partly a builder (programmatically) for UIs, partly lots of overrides for morhic â> needs to be moved to Morphic base, Morphic Widgets, overrides need to be move to the other packages We need to see if the builder parts are needed considering Spec. > FreeType Fonts > Keymapping Keyboard shorcut support > Multilingual Lots of random stuff for I18N support. > Morphic a big mess... > Graphics Random classes related to Graphics. The Canvas is strangely in Morphic, though. needs cleanup and thought. What is basic Graphics? What is Morhic? What is backward compatibility? What can be removed? > Balloon Old 2D stuff, incomplete. There is a backend for Athens that uses it, which is handy for debugging. In the long run â> remove > Athens New 2D Vector API, with backend for Cairo (and Ballon for debugging) right now. This is the future. > NBOpenGL OpenGL bindings. We want in the long run to render Athens directly with thisâ¦ (very long run).

Jan. 2, 2014

Re: [Pharo-dev] Thank you for Pharo

by StÃ©phane Ducasse

On 02 Jan 2014, at 11:48, Volkert Barr <volkert(a)nivoba.de> wrote: > > On 01.01.2014, at 19:26, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >>> I understand that community support is needed, and yes i am willing to help. As a first step i can offer my help to test pharo features, help to write test cases, write some example code snippets, open bug reports. But i am not sure what Pharo features or libraries i should put my focus on. Any suggestions where to dig in? >> >> Excellent! >> Thanks. I suggest that you focus on what you like or what you want to learn and do it step by step. >> Stef >> > I would like to understand ui and graphics programming in Pharo. I have found different ui related libraries, but not really understand how > they all relate to each other, what their purposes and what will be "part of" future Pharo Versions and what not. > > Spec > Glamour > UIManager > Polymorph > FreeType > Keymapping > Multilingual > Morphic > Graphics > Balloon > Athens > NBOpenGL You are mixing a lot of things that are not related. Spec is a way to build widgets and applications (like in VisualWorks) UiManager is just a way to manage image with or without ui + a facade that one day should disappear. Polymorph is an extension of Morph that we are slowly absorbing into Morph. Multilngual I let you guess but this is about multi language support :) Graphics is the low level system to manage bitmaps and others. NBOpenGL is an API to call openGL Athens is an API read the Pharo vision document to understand what it means. Stef

Jan. 2, 2014