Glamour
Locked
12
12
 
|
Hi everybody,
I'm just discovering Glamour, and after having read examples, I've tested to write my own browser but, as you guessed, it doesn't work and moreover the debugger doesn't help me at all Here is my code : recentSetBrowser | browser | browser := GLMTabulator new. browser column: #one. browser showOn: #one; using: [ browser tree title: 'Tree'; children: [:item :x :level | level > 1 ifTrue: [#()] ifFalse: [item size ]]]. ^browser Here is the example : treeWithChildrenByLevel |browser | browser := GLMTabulator new. browser column: #one; column: [:c | c row: #two; row: #three]. browser showOn: #one; using: [ browser tree title: 'Tree'; children: [:item :x :level | level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]]. browser showOn: #two; from: #one; using: [ browser text title: 'Selection preview' ]. browser showOn: #three; from: #one->#selectionPath; using: [ browser text title: 'Selection path preview']. ^ browser When I run GLMTest1 new recentSetBrowser openOn: #('lapin' 'chapeau') the debugger answer : 'MessageNotUnderstood: SmallInteger>>collect:' ... If someone can help me :) Benjamin Van Ryseghem _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Benjamin,
First of all, welcome :). Second of all, thanks for reminding me that I should update the examples with using the new API, instead of the old one that uses showOn:. I committed a quick update of the treeWithChildrenByLevel to give you an idea of the difference. Coming back to your example, the problem is that the children block does not return a collection, but an integer. If you want to see the children of a node, you need to specify a collection with objects that will appear as children. Ideally, they should be of the same type as the root nodes. Cheers, Doru On 2 Nov 2010, at 19:12, Benjamin wrote: > Hi everybody, > > I'm just discovering Glamour, and after having read examples, I've tested to write my own browser but, as you guessed, it doesn't work and moreover the debugger doesn't help me at all > > > Here is my code : > > recentSetBrowser > | browser | > > browser := GLMTabulator new. > browser column: #one. > browser showOn: #one; using: [ > browser tree > title: 'Tree'; > children: [:item :x :level | > level > 1 ifTrue: [#()] ifFalse: [item size ]]]. > ^browser > > Here is the example : > > treeWithChildrenByLevel > |browser | > > browser := GLMTabulator new. > browser column: #one; column: [:c | c row: #two; row: #three]. > browser showOn: #one; using: [ > browser tree > title: 'Tree'; > children: [:item :x :level | > level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]]. > browser showOn: #two; from: #one; using: [ browser text title: 'Selection preview' ]. > browser showOn: #three; from: #one->#selectionPath; using: [ > browser text title: 'Selection path preview']. > ^ browser > > When I run > GLMTest1 new recentSetBrowser openOn: #('lapin' 'chapeau') > the debugger answer : > 'MessageNotUnderstood: SmallInteger>>collect:' ... > > If someone can help me :) > > > > > > Benjamin Van Ryseghem > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Live like you mean it." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Ok, thank you for your answer :) I'm trying to load Glamour using the code founded on the web page : Gofer new squeaksource: 'Glamour'; package: 'ConfigurationOfGlamour'; load. But it doesn't work, it seems a method is deprecated, and it won't load the code :s It sounds like neewbie talks ... On Nov 2, 2010, at 9:29 PM, Tudor Girba wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Benjamin Van Ryseghem (Pharo)
doru
I asked several guys around here to have a look at Glamour and gives you feedback and to see if we can build some cool tools with glamour. Alain told me that he will have a look too. Now the problem of benjamin is also really interesting in the sense that we could not debug it and find the problem ourselves and that was frustrating: mismatch of block arguments or something like that. This is this aspect of glamour that I would like to see lowered. You see even reading your answer and looking at the code I do not get it. :( then some questions: why children: [:item :x :level | >> level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]]. could not be child: childObject level: level.... I have no idea what is x. So for me there is an overuse of block and blocks have no name contrary to method so we miss a lot of the hidden context. So any solution lowering the amount of blocks would be good may be using methods instead and (in that case having less scripting and more programming api would help). I understand that right now you want to script your browser in a workspace. But when the script gets bigger and gets hosted in a class then not using method is frustrating. so having an API for scripting is one point but it would be good to have the counterpart when we code class because at the end we will code classes. Stef > Hi Benjamin, > > First of all, welcome :). > > Second of all, thanks for reminding me that I should update the examples with using the new API, instead of the old one that uses showOn:. I committed a quick update of the treeWithChildrenByLevel to give you an idea of the difference. > > Coming back to your example, the problem is that the children block does not return a collection, but an integer. If you want to see the children of a node, you need to specify a collection with objects that will appear as children. Ideally, they should be of the same type as the root nodes. > > Cheers, > Doru > > > On 2 Nov 2010, at 19:12, Benjamin wrote: > >> Hi everybody, >> >> I'm just discovering Glamour, and after having read examples, I've tested to write my own browser but, as you guessed, it doesn't work and moreover the debugger doesn't help me at all >> >> >> Here is my code : >> >> recentSetBrowser >> | browser | >> >> browser := GLMTabulator new. >> browser column: #one. >> browser showOn: #one; using: [ >> browser tree >> title: 'Tree'; >> children: [:item :x :level | >> level > 1 ifTrue: [#()] ifFalse: [item size ]]]. >> ^browser >> >> Here is the example : >> >> treeWithChildrenByLevel >> |browser | >> >> browser := GLMTabulator new. >> browser column: #one; column: [:c | c row: #two; row: #three]. >> browser showOn: #one; using: [ >> browser tree >> title: 'Tree'; >> children: [:item :x :level | >> level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]]. >> browser showOn: #two; from: #one; using: [ browser text title: 'Selection preview' ]. >> browser showOn: #three; from: #one->#selectionPath; using: [ >> browser text title: 'Selection path preview']. >> ^ browser >> >> When I run >> GLMTest1 new recentSetBrowser openOn: #('lapin' 'chapeau') >> the debugger answer : >> 'MessageNotUnderstood: SmallInteger>>collect:' ... >> >> If someone can help me :) >> >> >> >> >> >> Benjamin Van Ryseghem >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Live like you mean it." > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Benjamin Van Ryseghem (Pharo)
Hi,
I believe you are trying to load Glamour in a PharoCore 1.2. This is not working at the moment. If you want to play with it, I would suggest to work with 1.1, or simply just take the latest nightly built Moose image: http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/artifact/moose/*zip*/moose.zip Cheers, Doru On 2 Nov 2010, at 23:33, Benjamin wrote: > Ok, thank you for your answer :) > > I'm trying to load Glamour using the code founded on the web page : > > Gofer new > squeaksource: 'Glamour'; > package: 'ConfigurationOfGlamour'; > load. > > > (Smalltalk at: #ConfigurationOfGlamour) perform: #loadDefault > > But it doesn't work, it seems a method is deprecated, and it won't load the code :s > It sounds like neewbie talks ... > > Ben > > > On Nov 2, 2010, at 9:29 PM, Tudor Girba wrote: > >> Hi Benjamin, >> >> First of all, welcome :). >> >> Second of all, thanks for reminding me that I should update the examples with using the new API, instead of the old one that uses showOn:. I committed a quick update of the treeWithChildrenByLevel to give you an idea of the difference. >> >> Coming back to your example, the problem is that the children block does not return a collection, but an integer. If you want to see the children of a node, you need to specify a collection with objects that will appear as children. Ideally, they should be of the same type as the root nodes. >> >> Cheers, >> Doru >> >> >> On 2 Nov 2010, at 19:12, Benjamin wrote: >> >>> Hi everybody, >>> >>> I'm just discovering Glamour, and after having read examples, I've tested to write my own browser but, as you guessed, it doesn't work and moreover the debugger doesn't help me at all >>> >>> >>> Here is my code : >>> >>> recentSetBrowser >>> | browser | >>> >>> browser := GLMTabulator new. >>> browser column: #one. >>> browser showOn: #one; using: [ >>> browser tree >>> title: 'Tree'; >>> children: [:item :x :level | >>> level > 1 ifTrue: [#()] ifFalse: [item size ]]]. >>> ^browser >>> >>> Here is the example : >>> >>> treeWithChildrenByLevel >>> |browser | >>> >>> browser := GLMTabulator new. >>> browser column: #one; column: [:c | c row: #two; row: #three]. >>> browser showOn: #one; using: [ >>> browser tree >>> title: 'Tree'; >>> children: [:item :x :level | >>> level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]]. >>> browser showOn: #two; from: #one; using: [ browser text title: 'Selection preview' ]. >>> browser showOn: #three; from: #one->#selectionPath; using: [ >>> browser text title: 'Selection path preview']. >>> ^ browser >>> >>> When I run >>> GLMTest1 new recentSetBrowser openOn: #('lapin' 'chapeau') >>> the debugger answer : >>> 'MessageNotUnderstood: SmallInteger>>collect:' ... >>> >>> If someone can help me :) >>> >>> >>> >>> >>> >>> Benjamin Van Ryseghem >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Live like you mean it." >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Stéphane Ducasse
Hi Stef,
Thanks for pushing this. I definitely understand these issues, and a solution will follow in the near future. It is just a matter of effort, and until now the main goal was to get things going at the model level. This is now working quite well, so now it's time to focus on the rendering and on the API. The only thing is that the API will only grow from people using it. With Mondrian, we could do it by having it used by a small amount of people. Glamour is a more complicated engine, and getting the right API right is not as straightforward. What you have right now is already the third version. The rest of the comments are inlined. > I asked several guys around here to have a look at Glamour and gives you feedback and to see if we can build some cool tools > with glamour. Alain told me that he will have a look too. > > Now the problem of benjamin is also really interesting in the sense that we could not debug it and find the problem ourselves > and that was frustrating: mismatch of block arguments or something like that. This was a mismatch of the returned type. > This is this aspect of glamour that I would like to see lowered. > You see even reading your answer and looking at the code I do not get it. :( > > then some questions: > > why children: [:item :x :level | >>> level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]]. > > could not be > > child: childObject level: level.... Basically, for every item, we want to know how to build the children collection. When you need to reason about multiple things, you need to pass them as a parameter in the block. Perhaps we can have something like: children: aBlock children: aBlock atLevel: anInteger children: aBlock atLevelHigherThan: anInteger > I have no idea what is x. in this case, the second variable is not used inside the block, so I just marked it with x to document that fact. The object is the presentation object. > So for me there is an overuse of block and blocks have no name contrary to method so we miss a lot of the hidden context. > So any solution lowering the amount of blocks would be good may be using methods instead and (in that case having > less scripting and more programming api would help). The blocks are just a convenience to construct and parameterize your presentations. Of course, this is only one way, and not the only way :). There really isn't anything magic about it. But, as I said, I will follow with another mail in the following days. Doru > I understand that right now you want to script your browser in a workspace. But when the script gets bigger and gets hosted in a class > then not using method is frustrating. so having an API for scripting is one point but it would be good to have the counterpart when we > code class because at the end we will code classes. > > Stef > > > > >> Hi Benjamin, >> >> First of all, welcome :). >> >> Second of all, thanks for reminding me that I should update the examples with using the new API, instead of the old one that uses showOn:. I committed a quick update of the treeWithChildrenByLevel to give you an idea of the difference. >> >> Coming back to your example, the problem is that the children block does not return a collection, but an integer. If you want to see the children of a node, you need to specify a collection with objects that will appear as children. Ideally, they should be of the same type as the root nodes. >> >> Cheers, >> Doru >> >> >> On 2 Nov 2010, at 19:12, Benjamin wrote: >> >>> Hi everybody, >>> >>> I'm just discovering Glamour, and after having read examples, I've tested to write my own browser but, as you guessed, it doesn't work and moreover the debugger doesn't help me at all >>> >>> >>> Here is my code : >>> >>> recentSetBrowser >>> | browser | >>> >>> browser := GLMTabulator new. >>> browser column: #one. >>> browser showOn: #one; using: [ >>> browser tree >>> title: 'Tree'; >>> children: [:item :x :level | >>> level > 1 ifTrue: [#()] ifFalse: [item size ]]]. >>> ^browser >>> >>> Here is the example : >>> >>> treeWithChildrenByLevel >>> |browser | >>> >>> browser := GLMTabulator new. >>> browser column: #one; column: [:c | c row: #two; row: #three]. >>> browser showOn: #one; using: [ >>> browser tree >>> title: 'Tree'; >>> children: [:item :x :level | >>> level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]]. >>> browser showOn: #two; from: #one; using: [ browser text title: 'Selection preview' ]. >>> browser showOn: #three; from: #one->#selectionPath; using: [ >>> browser text title: 'Selection path preview']. >>> ^ browser >>> >>> When I run >>> GLMTest1 new recentSetBrowser openOn: #('lapin' 'chapeau') >>> the debugger answer : >>> 'MessageNotUnderstood: SmallInteger>>collect:' ... >>> >>> If someone can help me :) >>> >>> >>> >>> >>> >>> Benjamin Van Ryseghem >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Live like you mean it." >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Beauty is where we see it." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Stéphane Ducasse
On Nov 3, 2010, at 10:17 AM, Tudor Girba wrote: > Hi Stef, > > Thanks for pushing this. > > I definitely understand these issues, and a solution will follow in the near future. It is just a matter of effort, and until now the main goal was to get things going at the model level. This is now working quite well, so now it's time to focus on the rendering and on the API. good to hear that. > The only thing is that the API will only grow from people using it. With Mondrian, we could do it by having it used by a small amount of people. Glamour is a more complicated engine, and getting the right API right is not as straightforward. What you have right now is already the third version. I imagine > The rest of the comments are inlined. > >> I asked several guys around here to have a look at Glamour and gives you feedback and to see if we can build some cool tools >> with glamour. Alain told me that he will have a look too. >> >> Now the problem of benjamin is also really interesting in the sense that we could not debug it and find the problem ourselves >> and that was frustrating: mismatch of block arguments or something like that. > > This was a mismatch of the returned type. Still the point is how can we make sure that we can debug it because the model is aligned with our mental model. > >> This is this aspect of glamour that I would like to see lowered. >> You see even reading your answer and looking at the code I do not get it. :( >> >> then some questions: >> >> why children: [:item :x :level | >>>> level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]]. >> >> could not be >> >> child: childObject level: level.... > > Basically, for every item, we want to know how to build the children collection. When you need to reason about multiple things, you need to pass them as a parameter in the block. > > Perhaps we can have something like: > > children: aBlock > children: aBlock atLevel: anInteger > children: aBlock atLevelHigherThan: anInteger Yes >> I have no idea what is x. > > in this case, the second variable is not used inside the block, so I just marked it with x to document that fact. The object is the presentation object. This is an hidden assumption and without an example I would have no idea that I should pass 3 arg block. Blocks used at their limits are evil since they do not have names. >> So for me there is an overuse of block and blocks have no name contrary to method so we miss a lot of the hidden context. >> So any solution lowering the amount of blocks would be good may be using methods instead and (in that case having >> less scripting and more programming api would help). > > The blocks are just a convenience to construct and parameterize your presentations. Of course, this is only one way, and not the only way :). There really isn't anything magic about it. But, as I said, I will follow with another mail in the following days. Good. I'm eager to see that. Now consider that your focus should not be on scripting (you have that API) but on how to build classes and use the power of classes to achieve build the same browsers. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Stef,
>>> I asked several guys around here to have a look at Glamour and gives you feedback and to see if we can build some cool tools >>> with glamour. Alain told me that he will have a look too. >>> >>> Now the problem of benjamin is also really interesting in the sense that we could not debug it and find the problem ourselves >>> and that was frustrating: mismatch of block arguments or something like that. >> >> This was a mismatch of the returned type. > > Still the point is how can we make sure that we can debug it because the model is aligned with our mental model. Yes, this is important, but I do not have a good answer here. The same thing happens in Mondrian, and also in Seaside. We would need some interesting Exceptions that would allow us to translate the internal problems into something that the user can understand. This would be a good candidate for a research project :) > >>> I have no idea what is x. >> >> in this case, the second variable is not used inside the block, so I just marked it with x to document that fact. The object is the presentation object. > > This is an hidden assumption and without an example I would have no idea that I should pass 3 arg block. > Blocks used at their limits are evil since they do not have names. It is hidden indeed, and that is why the current API tries to limit the amount of block arguments for 99% of usages to about 2. The case of children: is not quite representative, and I agree that it is rather obscure. >>> So for me there is an overuse of block and blocks have no name contrary to method so we miss a lot of the hidden context. >>> So any solution lowering the amount of blocks would be good may be using methods instead and (in that case having >>> less scripting and more programming api would help). >> >> The blocks are just a convenience to construct and parameterize your presentations. Of course, this is only one way, and not the only way :). There really isn't anything magic about it. But, as I said, I will follow with another mail in the following days. > > Good. > I'm eager to see that. > Now consider that your focus should not be on scripting (you have that API) but on how to build classes and use > the power of classes to achieve build the same browsers. I know :). Cheers, Doru -- www.tudorgirba.com "Some battles are better lost than fought." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
hello, there still are things I do not understand in your examples,
and I hope you could help me because I really want to understand how Glamour works ^^ When you write : t1 transmit to: #three; from: #one -> #selectionPath; what happen ? Because I have looked for implementors of selectionPath, put a self halt in each of them, run your browser, but no halt has been thrown, so I'm confused (again). Moreover, I now know how to show a list, and how to pass the selected items from the list to another column/row, but I wonder how to use the selected item as a parameter for a method and how to get the answer of this method back to be used in another part. I keep hope to understand how it works ^^ Benjamin _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Benjamin,
Great, it looks like you are getting into the details :). Before going forward, please read the short design description: http://www.themoosebook.org/book/internals/glamour/architecture To get an idea of how a browser looks like inside, we also use a special notation: http://www.themoosebook.org/book/internals/glamour/sketching Transmissions connect ports of panes. When you have #one->#selectionPath, you are basically specifying that we refer to the #selectionPath port from the #one port. This is a shortcut that will be deprecated in the future. You will have to explicitly say #to:port:. When you have "transmit to: #one", you transmit to the default input port of a pane which is named #entity. When you have "transmit from: #one", you transmit to the default output port of a pane which is named #selection. The ports can be named in any way you want. You can think of them as instance variables of a pane. It is then up to you to connect the ports correctly. Some of the presentations know how to populate some ports by default. For example: - a list will populate the #selection port with the item selected in the ui - a tree will populate the #selectionPath with a collection holding the items from the selected item to the root of the tree I hope this helps. Please continue to ask questions :) Cheers, Doru On 3 Nov 2010, at 12:59, Benjamin wrote: > hello, there still are things I do not understand in your examples, and I hope you could help me because I really want to understand how Glamour works ^^ > > When you write : > > t1 transmit to: #three; > from: #one -> #selectionPath; > > what happen ? > > Because I have looked for implementors of selectionPath, put a self halt in each of them, run your browser, but no halt has been thrown, so I'm confused (again). > > Moreover, I now know how to show a list, and how to pass the selected items from the list to another column/row, but I wonder how to use the selected item as a parameter for a method and how to get the answer of this method back to be used in another part. > > > I keep hope to understand how it works ^^ > > > > Benjamin > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "We cannot reach the flow of things unless we let go." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba
I like your spirit :)
and this is great to see your questions. Stef On Nov 3, 2010, at 1:04 PM, Benjamin wrote: > hello, there still are things I do not understand in your examples, and I hope you could help me because I really want to understand how Glamour works ^^ > > When you write : > > t1 transmit to: #three; > from: #one -> #selectionPath; > > what happen ? > > Because I have looked for implementors of selectionPath, put a self halt in each of them, run your browser, but no halt has been thrown, so I'm confused (again). > > Moreover, I now know how to show a list, and how to pass the selected items from the list to another column/row, but I wonder how to use the selected item as a parameter for a method and how to get the answer of this method back to be used in another part. > > > I keep hope to understand how it works ^^ > > > > Benjamin > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba
I just succeed to make my first Glamour-designed browser works ^^
Thank you Doru for your advice, I'll read both article and keep asking questions ^^ So prepare yourself ;) Benjamin _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Stéphane Ducasse
Hi guys :)
I'm still trying to understand the magic of Glamour, but as you guess, I've another misunderstood something ... Here is my code : browser transmit to: #three; from: #one; andShow: [:presentation | presentation tree title: 'Tree'; display: [:elt | dictionary := ((Checker wantedClasses:{elt}) compute ). dictionary keys]; children: [:elt :x :level | level > 1 ifTrue: [#()] ifFalse: [ (dictionary at: elt)]]]; format: [:set | self halt]] Here is the example code : browser transmit to: #namespaces; andShow: [ :a | When I run my code i get 'MessageNotUnderstood: GLMTransmission>>format:' I do not know why ... Ben _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi,
you sent #format: to the result of #transmit instead of the #tree because you closed too many blocks before. Doru On 4 Nov 2010, at 12:29, Benjamin wrote: > Hi guys :) > > I'm still trying to understand the magic of Glamour, but as you guess, I've another misunderstood something ... > > > Here is my code : > > browser > transmit to: #three; > from: #one; > andShow: [:presentation | > presentation > tree > title: 'Tree'; > display: [:elt | dictionary := ((Checker wantedClasses:{elt}) compute ). > dictionary keys]; > children: [:elt :x :level | level > 1 > ifTrue: [#()] > ifFalse: [ > (dictionary at: elt)]]]; > format: [:set | self halt]] > > Here is the example code : > browser transmit to: #namespaces; andShow: [ :a | > a tree > display: [ :model | model allNamespaces select: [ :each | each isRoot ] ]; > children: [ :namespace | namespace childScopes ]; > format: [ :namespace | namespace stubFormattedName ] ]. > When I run my code i get 'MessageNotUnderstood: GLMTransmission>>format:' > > I do not know why ... > > > > Ben > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Presenting is storytelling." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Ouups :s
I'll try to open my both eyes before sending a mail now :) Thank you Ben _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Just embrace the debugger :). It told you that the receiver was a Transmission, and you should have wanted a Presentation.
But, asking questions is no problem. Actually, please continue :). Doru On 4 Nov 2010, at 12:45, Benjamin wrote: > Ouups :s > > > I'll try to open my both eyes before sending a mail now :) > > > Thank you > > Ben > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba
no ooooooooooooo
Don't limit yourself show us your errors your errors are coool Glamour API should be better :) Stef On Nov 4, 2010, at 12:50 PM, Benjamin wrote: > Ouups :s > > > I'll try to open my both eyes before sending a mail now :) > > > Thank you > > Ben > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Actually the Glamour API could be considered to be an internal DSL to
describe browsers. I assume that a forth and five iteration are necessary to make it more user friendly. That is the reason why I did not pursue Glamour this May. I thought instead of going for Glamour I can just go through the effort of learning the ToolBuilder builder DSL -- which in the end is not more difficult either. A note aside: Maybe I push the idea of DSL too much here. The question is: where do we talk about an API and where does the DSL idea start? However --- though there are alot examples -- even more example will help and I recently enjoyed trying out some of them in the Moose-Glamour-Image. --Hannes On 11/4/10, Stéphane Ducasse <[hidden email]> wrote: > no ooooooooooooo > > Don't limit yourself show us your errors > > > your errors are coool > > Glamour API should be better :) > > Stef > > On Nov 4, 2010, at 12:50 PM, Benjamin wrote: > >> Ouups :s >> >> >> I'll try to open my both eyes before sending a mail now :) >> >> >> Thank you >> >> Ben >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Stéphane Ducasse
On Nov 4, 2010, at 2:43 PM, Hannes Hirzel wrote: > Actually the Glamour API could be considered to be an internal DSL to > describe browsers. I assume that a forth and five iteration are > necessary to make it more user friendly. That is the reason why I did > not pursue Glamour this May. I thought instead of going for Glamour I > can just go through the effort of learning the ToolBuilder builder DSL > -- which in the end is not more difficult either. but glamour is not comparable with toolbuilder. Now do you have all the polymorph widgets described as toolbuilder spec? Because this is the problem. > A note aside: Maybe I push the idea of DSL too much here. The question > is: where do we talk about an API and where does the DSL idea start? > > However --- though there are alot examples -- even more example will > help and I recently enjoyed trying out some of them in the > Moose-Glamour-Image. > > --Hannes > > On 11/4/10, Stéphane Ducasse <[hidden email]> wrote: >> no ooooooooooooo >> >> Don't limit yourself show us your errors >> >> >> your errors are coool >> >> Glamour API should be better :) >> >> Stef >> >> On Nov 4, 2010, at 12:50 PM, Benjamin wrote: >> >>> Ouups :s >>> >>> >>> I'll try to open my both eyes before sending a mail now :) >>> >>> >>> Thank you >>> >>> Ben >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Hannes Hirzel
Hi,
The Glamour API is intended to be an internal DSL. This is particularly useful for people that do not know Smalltalk :) What parts of the API is not user friendly for you? Regarding the ToolBuilder vs Glamour issue, ToolBuilder is a User Interface framework, while Glamour is a browser engine. To give you an idea, with the ToolBuilder, you place buttons in a window. With Glamour, you define the data flow and the way data is presented at a higher level. Regarding examples, what kind of things are you interested in? Cheers, Doru On 4 Nov 2010, at 14:43, Hannes Hirzel wrote: > Actually the Glamour API could be considered to be an internal DSL to > describe browsers. I assume that a forth and five iteration are > necessary to make it more user friendly. That is the reason why I did > not pursue Glamour this May. I thought instead of going for Glamour I > can just go through the effort of learning the ToolBuilder builder DSL > -- which in the end is not more difficult either. > > A note aside: Maybe I push the idea of DSL too much here. The question > is: where do we talk about an API and where does the DSL idea start? > > However --- though there are alot examples -- even more example will > help and I recently enjoyed trying out some of them in the > Moose-Glamour-Image. > > --Hannes > > On 11/4/10, Stéphane Ducasse <[hidden email]> wrote: >> no ooooooooooooo >> >> Don't limit yourself show us your errors >> >> >> your errors are coool >> >> Glamour API should be better :) >> >> Stef >> >> On Nov 4, 2010, at 12:50 PM, Benjamin wrote: >> >>> Ouups :s >>> >>> >>> I'll try to open my both eyes before sending a mail now :) >>> >>> >>> Thank you >>> >>> Ben >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "It's not how it is, it is how we see it." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |