it is. right click on a model, Utilities>>delete. On May 2, 2010, at 17:14 , stephane ducasse wrote: --- Jannik Laval _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

because of the computation time for the display. Now with the new cache system, we could change that. Jannik On May 2, 2010, at 17:47 , Stéphane Ducasse wrote: --- Jannik Laval _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Yes I found that finally and after the model is still shown on the right. I do not understand why a model is not selected automatically and why we should ddoubleclick on it. Stef On May 2, 2010, at 5:43 PM, Laval Jannik wrote: _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

One way to address this would be a possibility to force a refresh of a given pane from a block of code (so that it can be include in buttons, context menus et cetera). Optionally with a new value to display (an empty collection in this case). I have been asking for something like this before, see thread 'Glamour: cross-pane updating implementation.' So consider this a second use case ;-) I posted some manual update code in that thread, but this was deemed to hackish ... On 03 May 2010, at 07:03, Tudor Girba wrote: -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

That does not surprise me :-) So let me refer to my counter-example: AspectMaps. To have a better idea of AspectMaps in action, please have a look at the webpage http://pleiad.cl/aspectmaps and see the screencasts. The 'Intro' and the 'Remaining features' screencasts explain stuff which is glamour-related, but have a look at the 'structural zoom' screencast as well because it is cool and you will better understand what the buttons do :-) Now, how is this implemented, thinking about panes and transmissions. I have: moose models -> projects pane projects pane -> aspects in projects pane projects pane -> mondrian visualization pane projects pane -> structural zoom buttons pane empty collection -> metrics panes metrics panes -> semi-hidden text field When I click on a structural zoom button (e.g. max in), the mondrian visualization needs to change because the underlying model (coming from the projects pane) has changed. Idem for some contextual menu entries in the aspects in project pane. Idem for when I change a metric in one of the metrics pane. (which updates the text field, which triggers the refresh) So now my hack forces a manual refresh of the mondrian pane in those cases. If you can propose/mock up an alternative solution I would be most happy to learn about it! On 03 May 2010, at 13:42, Tudor Girba wrote: -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi Johan, I am interested in this use case. Unfortunately, the webpage is not available at the moment, so I cannot completely understand the model. It looks to me like the mondrianPane depends on three panes, and you seem to model it via some side-effects. In that case, is it not enough to have a transformation that has three origins and that gets redrawn every time you all the time? Also, if you want to preserve the existing presentation (because of some side-effects), you can also use andShowIfNone: instead of andShow: Is this helpful? Cheers, Doru On 5 May 2010, at 01:32, Johan Fabry wrote: -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

It looks to me like the button actions are actually actions that should belong to the MondrianPresentation. Unfortunately, there is no support for rendering a menu on a presentation (although it would be great to have it), so perhaps a good place would be in a menu on a canvas.

Regarding the triggering of transmissions from actions, the preferred way is to populate a port of the enclosing pane. For that you can directly use: populate: #your_port on: $shortcut entitled: 'Title' with: [:presentation | ... ] Take a look at GLMBasicExample>>updateAction.

You've got to show me that tomorrow.