would be nice to be able to delete a model using the UI

> it is.
> right click on a model,  Utilities>>delete.
>
>
> On May 2, 2010, at 17:14 , stephane ducasse wrote:
>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> ---
> Jannik Laval
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> 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:
>
>> it is.
>> right click on a model,  Utilities>>delete.
>>
>>
>> On May 2, 2010, at 17:14 , stephane ducasse wrote:
>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> ---
>> Jannik Laval
>>
>> _______________________________________________
>> 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

> 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:
>
>> 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:
>>
>>> it is.
>>> right click on a model,  Utilities>>delete.
>>>
>>>
>>> On May 2, 2010, at 17:14 , stephane ducasse wrote:
>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> ---
>>> Jannik Laval
>>>
>>> _______________________________________________
>>> 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
>
> ---
> Jannik Laval
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Indeed, I wanted to do that for couple of weeks. It is fixed now:
>
> Name: Moose-Finder-tg.196
> Author: tg
> Time: 2 May 2010, 6:21:29 pm
> UUID: d781114c-8075-4f88-96ff-2c6750de6ae4
> Ancestors: Moose-Finder-cyrille_delaunay.195
>
> selecting a model in moose panel is now again done through simple click
>
>
> Cheers,
> Doru
>
>
>
> On 2 May 2010, at 17:51, Laval Jannik wrote:
>
>> 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:
>>
>>> 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:
>>>
>>>> it is.
>>>> right click on a model,  Utilities>>delete.
>>>>
>>>>
>>>> On May 2, 2010, at 17:14 , stephane ducasse wrote:
>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> ---
>>>> Jannik Laval
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> ---
>> Jannik Laval
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Every successful trip needs a suitable vehicle."
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> 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:
>
>> it is.
>> right click on a model,  Utilities>>delete.
>>
>>
>> On May 2, 2010, at 17:14 , stephane ducasse wrote:
>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> ---
>> Jannik Laval
>>
>> _______________________________________________
>> 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

> Hi,
>
> The problem of not being able to remove the pane from the right hand side is a deeper one in the model of Glamour. That won't be easily fixable :(.
>
> Cheers,
> Doru
>
>
> On 2 May 2010, at 17:47, Stéphane Ducasse wrote:
>
>> 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

>
> 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:
>
>> Hi,
>>
>> The problem of not being able to remove the pane from the right  
>> hand side is a deeper one in the model of Glamour. That won't be  
>> easily fixable :(.
>>
>> Cheers,
>> Doru
>>
>>
>> On 2 May 2010, at 17:47, Stéphane Ducasse wrote:
>>
>>> 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
>
> --
> Johan Fabry
> [hidden email] - http://dcc.uchile.cl/~jfabry
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Hi Johan,
>
> I am not with you on this one :).
>
> The current problem would not be solvable with what you want.
>
> Also, maybe I missed something, but what exactly is wrong with the current way of doing update?
>
> Cheers,
> Doru
>
>
> On 3 May 2010, at 19:07, Johan Fabry wrote:
>
>>
>> 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 ...

>
> 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:
>
>> Hi Johan,
>>
>> I am not with you on this one :).
>>
>> The current problem would not be solvable with what you want.
>>
>> Also, maybe I missed something, but what exactly is wrong with the  
>> current way of doing update?
>>
>> Cheers,
>> Doru
>>
>>
>> On 3 May 2010, at 19:07, Johan Fabry wrote:
>>
>>>
>>> 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 ...
>
> --
> Johan Fabry
> [hidden email] - http://dcc.uchile.cl/~jfabry
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> 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:
>
>>
>> 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:
>>
>>> Hi Johan,
>>>
>>> I am not with you on this one :).
>>>
>>> The current problem would not be solvable with what you want.
>>>
>>> Also, maybe I missed something, but what exactly is wrong with the  
>>> current way of doing update?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> On 3 May 2010, at 19:07, Johan Fabry wrote:
>>>
>>>>
>>>> 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 ...
>>
>> --
>> Johan Fabry
>> [hidden email] - http://dcc.uchile.cl/~jfabry
>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "There are no old things, there are only old ways of looking at them."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> 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:
>
>>
>> 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:
>>
>>> Hi Johan,
>>>
>>> I am not with you on this one :).
>>>
>>> The current problem would not be solvable with what you want.
>>>
>>> Also, maybe I missed something, but what exactly is wrong with the current way of doing update?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> On 3 May 2010, at 19:07, Johan Fabry wrote:
>>>
>>>>
>>>> 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 ...
>>
>> --
>> Johan Fabry
>> [hidden email] - http://dcc.uchile.cl/~jfabry
>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "There are no old things, there are only old ways of looking at them."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Hi Doru, all,
>
> there was a router problem that has been solved, so now the page  
> should be accessible. Please try again.
>
> The contents of the mondrianPane depends on the projects pane, that  
> selects the model to be visualized. However the other panes also  
> modify the model, and when this happens the mondrianPane needs to be  
> refreshed. Modifications also happen through clicking on buttons or  
> context menus, and I don’t know how to trigger a transmission from  
> there.
>
> On 05 May 2010, at 03:55, Tudor Girba wrote:
>
>> 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:
>>
>>>
>>> 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:
>>>
>>>> Hi Johan,
>>>>
>>>> I am not with you on this one :).
>>>>
>>>> The current problem would not be solvable with what you want.
>>>>
>>>> Also, maybe I missed something, but what exactly is wrong with  
>>>> the current way of doing update?
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> On 3 May 2010, at 19:07, Johan Fabry wrote:
>>>>
>>>>>
>>>>> 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 ...
>>>
>>> --
>>> Johan Fabry
>>> [hidden email] - http://dcc.uchile.cl/~jfabry
>>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "There are no old things, there are only old ways of looking at  
>> them."
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Johan Fabry
> [hidden email] - http://dcc.uchile.cl/~jfabry
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Doru, thanks a lot for this clarification. I was able to  
> significantly clean up the Glamour part of AspectMaps, squashing  
> some nasty side-effects on the way! See below for more details ...
>
> On 05 May 2010, at 15:53, Tudor Girba wrote:
>
>> 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.
>
> Yes, agree that the buttons do things related to the mondrian  
> presentation. However I dont like the idea of having these buttons  
> as menu items because of ease of use. More clicks required to get to  
> a menu item, plus the buttons are more visible. That's the 'raison  
> d'etre' of toolbars, no?

>> 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.
>
> OK. So what I am doing now for the #buttons pane is
>
> (a actionList) title: 'Structural Zoom';
> populate: #selection
> on: $3
> entitled: 'Enabled Aspects'
> with: [:p :entity | <do the work required for the button and return  
> a new object>]
> populate: #selection
> on: $4
> entitled: 'Multiple Aspects'
> with: [:p :entity | <do the work required for the button and return  
> a new object>]
> et cetera ...
>
> - I have the shortcut as a nonsensical number ($1 to $6) because  
> command shortcuts on buttons dont seem to work :-( (So does it make  
> sense to have populate:on:with: ?)

> --
> Johan Fabry
> [hidden email] - http://dcc.uchile.cl/~jfabry
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev