it is. right click on a model, Utilities>>delete.
On May 2, 2010, at 17:14 , stephane ducasse wrote:
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@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:
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
thank you Doru,
I try it :)
On May 2, 2010, at 18:35 , Tudor Girba wrote:
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
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
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch 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."
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
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 ...
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow."
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch 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."
Hi Doru,
From what I understood, another side of the problem is how to send #increaseZoom to the MOCanvas by pressing a button in the lower AspectMaps browser pane. I haven't personally had a look at it, but I got this question a number of times already.
Cheers, Alexandre
On 5 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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch 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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Hi,
Ok, it works now.
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.
Cheers, Doru
On 5 May 2010, at 16:21, Johan Fabry wrote:
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"One cannot do more than one can do."
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: ?) - I make sure to always return a new object so that the 'new selection' gets sent to the outside - the mondrian view has a from: #buttons and ignores the value passed, I just use it to trigger the update
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
On 06 May 2010, at 19:39, Alexandre Bergel wrote:
- the mondrian view has a from: #buttons and ignores the value passed, I just use it to trigger the update
You've got to show me that tomorrow.
Now do I need to read this with a nasty tone of voice, with a puzzled tone of voice, or with a surprised tone of voice? :-P
(sorry for the spam, all) -- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Hi Johan,
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?
Completely agree. There is no toolbar just because I do not know how to do it with Morphic. Ideally I would like to have a tab widget like the one in Eclipse with a small toolbar to the right of the tabs.
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: ?)
No much, but this method is offered by GLMPresentation. We should just add one without the on:
- I make sure to always return a new object so that the 'new
selection' gets sent to the outside
- the mondrian view has a from: #buttons and ignores the value
passed, I just use it to trigger the update
That is a good solution at this moment :)
Cheers, Doru
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Be rather willing to give than demanding to get."
-
Alexandre Bergel -
Johan Fabry -
Laval Jannik -
stephane ducasse -
Stéphane Ducasse -
Tudor Girba