Hi all,
a question: I have a tree on a collection of elements, with the following specification:
tags: [:asp | {asp show ifTrue:[MenuIcons smallOkIcon] ifFalse: [MenuIcons smallCancelIcon]}]; act: [:tree | |asp| asp := tree selection. asp show: (asp show not) ] on: $t entitled: 'Toggle On/Off (t)';
Now when the toggle action is performed, the tree should redisplay, as the tag needs to change. (adding a tree update within the act block does not work :-( ) How do I achieve this?
Thanks in advance! -- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Hi Johan,
Update is not supported by Glamour at this time :(. In fact, this is the most important major feature that is missing.
The problem is that "update" has many facets that are not quite obvious, and I did not yet find a good enough solution to accommodate these. It is in my plan to work on it during the winter holidays, but I cannot promise a solution at this moment.
Cheers, Doru
On 12 Dec 2009, at 20:23, Johan Fabry wrote:
Hi all,
a question: I have a tree on a collection of elements, with the following specification:
tags: [:asp | {asp show ifTrue:[MenuIcons smallOkIcon] ifFalse: [MenuIcons smallCancelIcon]}]; act: [:tree | |asp| asp := tree selection. asp show: (asp show not) ] on: $t entitled: 'Toggle On/Off (t)';
Now when the toggle action is performed, the tree should redisplay, as the tag needs to change. (adding a tree update within the act block does not work :-( ) How do I achieve this?
Thanks in advance!
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
"It's not how it is, it is how we see it."
Oops, seems I am a person with tough requirements ;-)
In the mean time a workaround: can I redraw the entire pane from scratch? I am thinking abut what happens e.g. in the Smalltalk browser you implement: when you select a class the categories are drawn, when you select another class the pane does an 'update' to show the categories of the other class.
Suppose I embed my pane as a custom browser in an outer browser, and I pass it the outer browser as a parameter at instantiation time. When I want my pane to redraw I pass some message to the outer browser so it redraws all from scratch. Could I do that? How? (I dont care if there's some flashing, as long as it works I'm happy.)
On 12 Dec 2009, at 20:49, Tudor Girba wrote:
Hi Johan,
Update is not supported by Glamour at this time :(. In fact, this is the most important major feature that is missing.
The problem is that "update" has many facets that are not quite obvious, and I did not yet find a good enough solution to accommodate these. It is in my plan to work on it during the winter holidays, but I cannot promise a 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
Hi Johan,
I do not have enough time to look into this right now, but maybe GLMDynamicPresentation is useful for your goal. This presentation takes as entity a presentation (or a browser, given that a browser is a presentation). Please take a look at GLMExamples class>>browseExamples for an example of how to use this one.
Cheers, Doru
On 13 Dec 2009, at 02:31, Johan Fabry wrote:
Oops, seems I am a person with tough requirements ;-)
In the mean time a workaround: can I redraw the entire pane from scratch? I am thinking abut what happens e.g. in the Smalltalk browser you implement: when you select a class the categories are drawn, when you select another class the pane does an 'update' to show the categories of the other class.
Suppose I embed my pane as a custom browser in an outer browser, and I pass it the outer browser as a parameter at instantiation time. When I want my pane to redraw I pass some message to the outer browser so it redraws all from scratch. Could I do that? How? (I dont care if there's some flashing, as long as it works I'm happy.)
On 12 Dec 2009, at 20:49, Tudor Girba wrote:
Hi Johan,
Update is not supported by Glamour at this time :(. In fact, this is the most important major feature that is missing.
The problem is that "update" has many facets that are not quite obvious, and I did not yet find a good enough solution to accommodate these. It is in my plan to work on it during the winter holidays, but I cannot promise a 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
"Next time you see your life passing by, say 'hi' and get to know her."
Hi Doru,
I'm sorry to say that GLMExamples class>>browseExamples is broken: it only shows an empty list. The reason for this is that it looks for pragmas but these are all in the subclasses. I guess that all this was first a big class that has been split up in different subclasses but the code of this method did not get adapted.
Still, hacking around in the code a bit did not give me insight in my root question. So let me try again: I want to understand what happens when you specify 'browser showOn: #foo; from: #bar' Where is the code that passes the selection event from #foo to #bar so that #bar refreshes itself? If I can hook into that, I can send a fake selection event from a non-existent #foo to my #bar so that #bar refreshes ... being an update of #bar :-)
Give me that and I'll code a primitive update mechanism for you that you can include in a future release of Glamour. As I conversed with Alex today (regarding a Mondrian update mechanism), it does not matter if it is slow or it flickers, at least it is basic functionality. First get it to work and we'll invest in an optimal solution later. We're supposed to be agile, right?
On 14 Dec 2009, at 12:11, Tudor Girba wrote:
Hi Johan,
I do not have enough time to look into this right now, but maybe GLMDynamicPresentation is useful for your goal. This presentation takes as entity a presentation (or a browser, given that a browser is a presentation). Please take a look at GLMExamples class>>browseExamples for an example of how to use this one.
Cheers, Doru
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Hi Johan,
I'm sorry to say that GLMExamples class>>browseExamples is broken: it only shows an empty list. The reason for this is that it looks for pragmas but these are all in the subclasses. I guess that all this was first a big class that has been split up in different subclasses but the code of this method did not get adapted.
browseExamples is in the right place, but you should execute it for subclasses :). I just pointed the place for the code.
Still, hacking around in the code a bit did not give me insight in my root question. So let me try again: I want to understand what happens when you specify 'browser showOn: #foo; from: #bar' Where is the code that passes the selection event from #foo to #bar so that #bar refreshes itself? If I can hook into that, I can send a fake selection event from a non-existent #foo to my #bar so that #bar refreshes ... being an update of #bar :-)
Give me that and I'll code a primitive update mechanism for you that you can include in a future release of Glamour. As I conversed with Alex today (regarding a Mondrian update mechanism), it does not matter if it is slow or it flickers, at least it is basic functionality. First get it to work and we'll invest in an optimal solution later. We're supposed to be agile, right?
It's not quite that straightforward. The propagation of values is given by Transmissions which are first class connectors between Panes. Whenever you have a showOn:;from: you get a Transmission with one target given by showOn: and as many origins as #from:. Every transmission is activated once an origin changes the value.
The problem of update is not the flickering, but is in getting proper semantics for Transmissions. The matter is a bit complicated because the browser should still make sense after an update. Refreshing the whole browser is also not straightforward, because you have to know how to traverse it which depends on the posibly complex graph of Transmissions.
So, as I said, it is not quite straightforward, but you can certainly take a look :).
Cheers, Doru
On 14 Dec 2009, at 12:11, Tudor Girba wrote:
Hi Johan,
I do not have enough time to look into this right now, but maybe GLMDynamicPresentation is useful for your goal. This presentation takes as entity a presentation (or a browser, given that a browser is a presentation). Please take a look at GLMExamples class>>browseExamples for an example of how to use this one.
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
"One cannot do more than one can do."
On 15 Dec 2009, at 07:44, Tudor Girba wrote:
Hi Johan,
I'm sorry to say that GLMExamples class>>browseExamples is broken: it only shows an empty list. The reason for this is that it looks for pragmas but these are all in the subclasses. I guess that all this was first a big class that has been split up in different subclasses but the code of this method did not get adapted.
browseExamples is in the right place, but you should execute it for subclasses :). I just pointed the place for the code.
OK, so how about changing the method comment to "self subclasses do: [:sc | sc browseExamples]" (instead of "self browseExamples")
Still, hacking around in the code a bit did not give me insight in my root question. So let me try again: I want to understand what happens when you specify 'browser showOn: #foo; from: #bar' Where is the code that passes the selection event from #foo to #bar so that #bar refreshes itself? If I can hook into that, I can send a fake selection event from a non-existent #foo to my #bar so that #bar refreshes ... being an update of #bar :-)
Give me that and I'll code a primitive update mechanism for you that you can include in a future release of Glamour. As I conversed with Alex today (regarding a Mondrian update mechanism), it does not matter if it is slow or it flickers, at least it is basic functionality. First get it to work and we'll invest in an optimal solution later. We're supposed to be agile, right?
It's not quite that straightforward. The propagation of values is given by Transmissions which are first class connectors between Panes. Whenever you have a showOn:;from: you get a Transmission with one target given by showOn: and as many origins as #from:. Every transmission is activated once an origin changes the value.
The problem of update is not the flickering, but is in getting proper semantics for Transmissions. The matter is a bit complicated because the browser should still make sense after an update. Refreshing the whole browser is also not straightforward, because you have to know how to traverse it which depends on the posibly complex graph of Transmissions.
Allow me to play devils' advocate: If I am a Pane, an update is a Transmission from me to me, and I activate that when I change, e.g. from within an act: block. No need to do any traversal, I simply update myself.
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
On 15 Dec 2009, at 12:48, Johan Fabry wrote:
It's not quite that straightforward. The propagation of values is given by Transmissions which are first class connectors between Panes. Whenever you have a showOn:;from: you get a Transmission with one target given by showOn: and as many origins as #from:. Every transmission is activated once an origin changes the value.
The problem of update is not the flickering, but is in getting proper semantics for Transmissions. The matter is a bit complicated because the browser should still make sense after an update. Refreshing the whole browser is also not straightforward, because you have to know how to traverse it which depends on the posibly complex graph of Transmissions.
Allow me to play devils' advocate: If I am a Pane, an update is a Transmission from me to me, and I activate that when I change, e.g. from within an act: block. No need to do any traversal, I simply update myself.
Now in the mean time, the less-critiquing-and-more-producing side of me has delivered the following hack. Works just fine for my purpose, nice updating the listed items to reveal their 'show' status.
(the asp argument of the format: block is a simple container with name being a String and show being a Boolean)
browser showOn: #aspects; using: [ |usingBrowser| usingBrowser := browser tree. usingBrowser title: 'Aspects'; format: [:asp | Text string: (asp name, asp show asString) attribute: (TextColor color: asp color).]; act: [:tree | |asp ann| asp := tree selection. asp show: (asp show not). ann := GLMMatchingPresentationsChanged new. ann pane: usingBrowser. ann oldMatchingPresentations: OrderedCollection new. usingBrowser pane announce: ann.] on: $t entitled: 'Toggle On/Off (t)'; ].
Voila :-) Good enough for me. I hope it is of use of some other people as well!
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Hi Johan,
I am glad it worked for you. Just please do not encourage people to do that :) :)
Cheers, Doru
On 15 Dec 2009, at 18:01, Johan Fabry wrote:
On 15 Dec 2009, at 12:48, Johan Fabry wrote:
It's not quite that straightforward. The propagation of values is given by Transmissions which are first class connectors between Panes. Whenever you have a showOn:;from: you get a Transmission with one target given by showOn: and as many origins as #from:. Every transmission is activated once an origin changes the value.
The problem of update is not the flickering, but is in getting proper semantics for Transmissions. The matter is a bit complicated because the browser should still make sense after an update. Refreshing the whole browser is also not straightforward, because you have to know how to traverse it which depends on the posibly complex graph of Transmissions.
Allow me to play devils' advocate: If I am a Pane, an update is a Transmission from me to me, and I activate that when I change, e.g. from within an act: block. No need to do any traversal, I simply update myself.
Now in the mean time, the less-critiquing-and-more-producing side of me has delivered the following hack. Works just fine for my purpose, nice updating the listed items to reveal their 'show' status.
(the asp argument of the format: block is a simple container with name being a String and show being a Boolean)
browser showOn: #aspects; using: [ |usingBrowser| usingBrowser := browser tree. usingBrowser title: 'Aspects'; format: [:asp | Text string: (asp name, asp show asString) attribute: (TextColor color: asp color).]; act: [:tree | |asp ann| asp := tree selection. asp show: (asp show not). ann := GLMMatchingPresentationsChanged new. ann pane: usingBrowser. ann oldMatchingPresentations: OrderedCollection new. usingBrowser pane announce: ann.] on: $t entitled: 'Toggle On/ Off (t)'; ].
Voila :-) Good enough for me. I hope it is of use of some other people as well!
-- 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
"Live like you mean it."
-
Johan Fabry -
Tudor Girba