20 Jan
2010
20 Jan
'10
6:46 p.m.
Hi all,
another case of DIY from me, so probably to be handled with care
(although it should be cleaner than the last bit of code I sent to the
list).
All my insistance on updating in the other thread is because,
fundamentally I wanted to allow a menu item/button/whatever in pane
#source to trigger the update in pane #dest. Note that 'browser
transmit to: #dest; from: #source' does not achieve this when in
#source you do an update. The one-liner below does. Place it in the
menu item/button/whatever of #source whenever you want to do the
update. (Assuming browser is the instance of GLMTabulator/
GLMFinder/... that you are using).
(browser paneNamed: #mpanel) presentations do: [:pres | pres update].
Doru, any chance of adding this to the API for browsers?
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
20 Jan
20 Jan
8:35 p.m.
Hi,
another case of DIY from me, so probably to be handled
with care
(although it should be cleaner than the last bit of code I sent to
the list).
All my insistance on updating in the other thread is because,
fundamentally I wanted to allow a menu item/button/whatever in pane
#source to trigger the update in pane #dest. Note that 'browser
transmit to: #dest; from: #source' does not achieve this when in
#source you do an update. The one-liner below does. Place it in the
menu item/button/whatever of #source whenever you want to do the
update. (Assuming browser is the instance of GLMTabulator/
GLMFinder/... that you are using).
(browser paneNamed: #mpanel) presentations do: [:pres | pres update].
Doru, any chance of adding this to the API for browsers?
Not really :).
This breaks the encapsulation between panes, as in our model, panes
should only talk with each other via transmissions. Maybe there will
be another mechanism for this, but I first need to learn more about
when exactly this is needed and why it is not possible to do it via an
existing mechanism.
Cheers,
Doru
--
www.tudorgirba.com
"Being happy is a matter of choice."
8:55 p.m.
On 20 Jan 2010, at 16:35, Tudor Girba wrote:
OK, then consider my case, AspectMaps (screenshot below for clarity).
- All the buttons make some change to the model that is being
displayed in the mondrian panel
- idem for some menu items on 'aspects in project' (e.g. changing the
color of a displayed aspect)
So for that I do my update trick. Can I do this cleanly with
transmissions? If so, how?
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Doru, any chance of adding this to the API for browsers?
Not really :).
This breaks the encapsulation between panes, as in our model, panes
should only talk with each other via transmissions. Maybe there will
be another mechanism for this, but I first need to learn more about
when exactly this is needed and why it is not possible to do it via
an existing mechanism.
10:19 p.m.
Hi,
Why is it not possible to have a single transmission from all the
buttons to the mondrian pane and decide the visualization based on all
provided input?
Cheers,
Doru
On 20 Jan 2010, at 20:55, Johan Fabry wrote:
On 20 Jan 2010, at 16:35, Tudor Girba wrote:
OK, then consider my case, AspectMaps (screenshot below for clarity).
- All the buttons make some change to the model that is being
displayed in the mondrian panel
- idem for some menu items on 'aspects in project' (e.g. changing
the color of a displayed aspect)
So for that I do my update trick. Can I do this cleanly with
transmissions? If so, how?
<AMnow.tiff>
--
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
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Doru, any chance of adding this to the API for browsers?
Not really :).
This breaks the encapsulation between panes, as in our model, panes
should only talk with each other via transmissions. Maybe there
will be another mechanism for this, but I first need to learn more
about when exactly this is needed and why it is not possible to do
it via an existing mechanism.
21 Jan
21 Jan
2:11 a.m.
I'd love to. How?
Seriously. It has never been made clear to me how I myself can send a
transmission from a button or menu item to a pane such that it
refreshes itself.
On 20 Jan 2010, at 18:19, Tudor Girba wrote:
Hi,
Why is it not possible to have a single transmission from all the
buttons to the mondrian pane and decide the visualization based on
all provided input?
Cheers,
Doru
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
8:29 a.m.
Hi,
The first parameter of an action is the presentation. And the
presentation has access to its pane. So, the preferred way is for the
presentation to only talk with its pane and then let transmissions
deal with links between panes. So, you can do:
a somePresentation
act: [:p :entity | (p pane portNamed: #somePort) value: entity
something] on: $x entitled: 'Update'
or shorter:
a somePresentation
update: #somePort on: $x entitled: 'Update' with: [:p :entity |
entity something]
So, I guess that the buttons in your case are part of an ActionList
that is placed in one pane. So, you could populate 6 different ports
in that pane and then have one transmission from all ports to the
mondrian pane (entity port).
Is this better?
Cheers,
Doru
On 21 Jan 2010, at 02:11, Johan Fabry wrote:
I'd love to. How?
Seriously. It has never been made clear to me how I myself can send
a transmission from a button or menu item to a pane such that it
refreshes itself.
On 20 Jan 2010, at 18:19, Tudor Girba wrote:
--
www.tudorgirba.com
"Be rather willing to give than demanding to get."
Hi,
Why is it not possible to have a single transmission from all the
buttons to the mondrian pane and decide the visualization based on
all provided input?
Cheers,
Doru
--
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
22 Jan
22 Jan
7:28 p.m.
Your first option does not work :-( portNamed: is not implemented. So
I tried the following variant, intending the #mpanel to update itself
but nothing happens :-(
browser transmit to: #buttons;
andShow:[ :a |
(a actionList)
act: [:p :entity | entity dooFooTransform. (p pane port: #mpanel)
value: entity ] entitled: 'DoFooTransform';
...
On 21 Jan 2010, at 04:29, Tudor Girba wrote:
Hi,
The first parameter of an action is the presentation. And the
presentation has access to its pane. So, the preferred way is for
the presentation to only talk with its pane and then let
transmissions deal with links between panes. So, you can do:
a somePresentation
act: [:p :entity | (p pane portNamed: #somePort) value: entity
something] on: $x entitled: 'Update'
or shorter:
a somePresentation
update: #somePort on: $x entitled: 'Update' with: [:p :entity |
entity something]
So, I guess that the buttons in your case are part of an ActionList
that is placed in one pane. So, you could populate 6 different ports
in that pane and then have one transmission from all ports to the
mondrian pane (entity port).
Is this better?
Cheers,
Doru
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
9:15 p.m.
Hi Johan,
On 22 Jan 2010, at 19:28, Johan Fabry wrote:
Your first option does not work :-( portNamed: is not
implemented.
Indeed, it is port:, not portNamed:
So I tried the following variant, intending the
#mpanel to update
itself but nothing happens :-(
Wait, #mpanel is the name of the port that you just updated. You need
to have a transmission that origins in that port, and if you have it,
it should trigger. Does it not happen like that?
Cheers,
Doru
browser transmit to: #buttons;
andShow:[ :a |
(a actionList)
act: [:p :entity | entity dooFooTransform. (p pane port: #mpanel)
value: entity ] entitled: 'DoFooTransform';
...
On 21 Jan 2010, at 04:29, Tudor Girba wrote:
--
www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot
be done."
Hi,
The first parameter of an action is the presentation. And the
presentation has access to its pane. So, the preferred way is for
the presentation to only talk with its pane and then let
transmissions deal with links between panes. So, you can do:
a somePresentation
act: [:p :entity | (p pane portNamed: #somePort) value: entity
something] on: $x entitled: 'Update'
or shorter:
a somePresentation
update: #somePort on: $x entitled: 'Update' with: [:p :entity |
entity something]
So, I guess that the buttons in your case are part of an ActionList
that is placed in one pane. So, you could populate 6 different
ports in that pane and then have one transmission from all ports to
the mondrian pane (entity port).
Is this better?
Cheers,
Doru
--
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
5218
days inactive
5220
days old
7 comments
2 participants
participants (2)
-
Johan Fabry -
Tudor Girba