5 May
2010
5 May
'10
9:53 p.m.
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:
--
www.tudorgirba.com
"One cannot do more than one can do."
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:
--
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:
--
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 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(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