Hello,
Is there any particular reason for GLMRoassal2Presentation working with RTView instead of RTMondrianViewBuilder i.e. in the painting block, we get RTView object instead of the builder.
I am asking this question because the predecessor, GLMRoassalPresentation, used to work with ROMondrianViewBuilder. Now, when we'll move our visualizations to work with Roassal2 in Glamour we'll have to make major modifications to the source code because the level of details with RTView and RTMondrianViewBuilder is not the same.
Usman
Usually you do not want to work only with RTMondrianViewBuilder, but intend be able to mix any builders.
Alexandre
On Mar 24, 2014, at 7:38 AM, Usman Bhatti usman.bhatti@gmail.com wrote:
Hello,
Is there any particular reason for GLMRoassal2Presentation working with RTView instead of RTMondrianViewBuilder i.e. in the painting block, we get RTView object instead of the builder.
I am asking this question because the predecessor, GLMRoassalPresentation, used to work with ROMondrianViewBuilder. Now, when we'll move our visualizations to work with Roassal2 in Glamour we'll have to make major modifications to the source code because the level of details with RTView and RTMondrianViewBuilder is not the same.
Usman _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Usman Bhatti wrote:
Hello,
Is there any particular reason for GLMRoassal2Presentation working with RTView instead of RTMondrianViewBuilder i.e. in the painting block, we get RTView object instead of the builder.
I am asking this question because the predecessor, GLMRoassalPresentation, used to work with ROMondrianViewBuilder. Now, when we'll move our visualizations to work with Roassal2 in Glamour we'll have to make major modifications to the source code because the level of details with RTView and RTMondrianViewBuilder is not the same.
Usman
I've been distracted for a while tackling Pharo 3 bugs leading up to release, but I very pleased to hear of this change. As someone who was using Roassal1 with Glamour sans Mondrian, it was painful and awkward to get a raw ROView without the stuff that Mondrian adds to it. I eventually found a work around that I think got integrated, but it was a bit of a hack.
For a long while, it seemed to me that Roassal did not have an independent identity separate from Mondrian. References to Mondrian and Roassal seemed often used interchangeably. Some mixed concerns were understandable since Roassal was (I believe) initially designed to provide an abstraction layer under the Mondrian API. However as Roassal finds broader use beyond Mondrian, things like GLMRoassalPresentation need to be separated from Mondrian. However perhaps there needs to be a new GLMMondrianPresentation, that won't clash with the old Mondrian since as I understand it that has been removed from the current Moose.
Speaking from what I remember of Roassal1, you could always get a ROMondrianViewBuilder from an ROView, but not the other way around. So where previously you might have... andShow: [ :a | a roassal painting: [ :mondrianViewBuilder | "do mondrian stuff ...."
I guess it now needs to be modified to... andShow: [ :a | a roassal painting: [ :roassalView | | mondrianViewBuilder := ROMondrianViewBuilder on: roassalView. [ "do mondrian stuff...."
or alternatively, perhaps the following would be better... andShow: [ :a | a mondrian painting: [ :mondrianViewBuilder | "do mondrian stuff ...." since this will no longer clash with the original Mondrian.
cheers -ben
On Mon, Mar 24, 2014 at 1:49 PM, Ben Coman btc@openinworld.com wrote:
Usman Bhatti wrote:
Hello,
Is there any particular reason for GLMRoassal2Presentation working with RTView instead of RTMondrianViewBuilder i.e. in the painting block, we get RTView object instead of the builder.
I am asking this question because the predecessor, GLMRoassalPresentation, used to work with ROMondrianViewBuilder. Now, when we'll move our visualizations to work with Roassal2 in Glamour we'll have to make major modifications to the source code because the level of details with RTView and RTMondrianViewBuilder is not the same.
Usman
I've been distracted for a while tackling Pharo 3 bugs leading up to release, but I very pleased to hear of this change. As someone who was using Roassal1 with Glamour sans Mondrian, it was painful and awkward to get a raw ROView without the stuff that Mondrian adds to it. I eventually found a work around that I think got integrated, but it was a bit of a hack. For a long while, it seemed to me that Roassal did not have an independent identity separate from Mondrian. References to Mondrian and Roassal seemed often used interchangeably. Some mixed concerns were understandable since Roassal was (I believe) initially designed to provide an abstraction layer under the Mondrian API. However as Roassal finds broader use beyond Mondrian, things like GLMRoassalPresentation need to be separated from Mondrian. However perhaps there needs to be a new GLMMondrianPresentation, that won't clash with the old Mondrian since as I understand it that has been removed from the current Moose.
Speaking from what I remember of Roassal1, you could always get a ROMondrianViewBuilder from an ROView, but not the other way around.
You could always ask for the under-lying ROView for ROMondrianView with: mondrianBuilder raw.
So where previously you might have... andShow: [ :a | a roassal painting: [ :mondrianViewBuilder | "do mondrian stuff ...."
I guess it now needs to be modified to... andShow: [ :a | a roassal painting: [ :roassalView | | mondrianViewBuilder := ROMondrianViewBuilder on: roassalView. [ "do mondrian stuff...."
Tx for this suggestion, it didn't cross my mind. Yes it is possible in Roassal2 to ask for a particular builder based on a RTView. RTBuilder new view: aRTView.
or alternatively, perhaps the following would be better... andShow: [ :a | a mondrian painting: [ :mondrianViewBuilder | "do mondrian stuff ...." since this will no longer clash with the original Mondrian.
For me both abstractions are good but mondrian builder is better for new comers because you don't start with Roassal doing a lot of stuff by hand (Roassal stuff). It occurs only when you start integrating some minute details.
BTW, I think it would be better to find a name for RoassalView (as Mondrian represents ROMondrianView) because currently when explaining Roassal, we say Roassal is the name of the tool that allows creating visualizations and it is composed of Mondrian and.... Roassal (the low-level things we can do with ROView). So, for me, a name is needed to describe the latter.
regards.
Usman
cheers -ben
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
GLMRoassalPresentation supports a custom builder via the initializeWith: block. However, this is rarely needed given that you can obtain the raw ROView from the Mondrian builder instance. Take a look at:
GLMRoassalPresentation>>roassalDirect "self new roassalDirect openOn: (1 to: 20)"
^ GLMWrapper new with: [ :browser | browser show: [ :a | a roassal initializeView: [ ROView new @ RODraggable ] ; painting: [ :view :numbers | numbers do: [ :number | view add: (ROElement spriteOn: number) + ROLabel ]. ROTreeLayout on: view elements ] ] ]
GLMRoassal2Presentation works similarly. The only difference is that in the GLMRoassal2Presentation, the default view is RTView. However, please keep in mind that Roassal2 does not have quite the same behavior as Roassal.
I was actually hoping that we get a unified way of handling builders. For example, right now to make ROView be interchangeable with ROMondrianViewBuilder, we extend ROView with applyLayout. Alex, would you have time to look into this?
Cheers, Doru
On Mon, Mar 24, 2014 at 2:12 PM, Usman Bhatti usman.bhatti@gmail.comwrote:
On Mon, Mar 24, 2014 at 1:49 PM, Ben Coman btc@openinworld.com wrote:
Usman Bhatti wrote:
Hello,
Is there any particular reason for GLMRoassal2Presentation working with RTView instead of RTMondrianViewBuilder i.e. in the painting block, we get RTView object instead of the builder.
I am asking this question because the predecessor, GLMRoassalPresentation, used to work with ROMondrianViewBuilder. Now, when we'll move our visualizations to work with Roassal2 in Glamour we'll have to make major modifications to the source code because the level of details with RTView and RTMondrianViewBuilder is not the same.
Usman
I've been distracted for a while tackling Pharo 3 bugs leading up to release, but I very pleased to hear of this change. As someone who was using Roassal1 with Glamour sans Mondrian, it was painful and awkward to get a raw ROView without the stuff that Mondrian adds to it. I eventually found a work around that I think got integrated, but it was a bit of a hack. For a long while, it seemed to me that Roassal did not have an independent identity separate from Mondrian. References to Mondrian and Roassal seemed often used interchangeably. Some mixed concerns were understandable since Roassal was (I believe) initially designed to provide an abstraction layer under the Mondrian API. However as Roassal finds broader use beyond Mondrian, things like GLMRoassalPresentation need to be separated from Mondrian. However perhaps there needs to be a new GLMMondrianPresentation, that won't clash with the old Mondrian since as I understand it that has been removed from the current Moose.
Speaking from what I remember of Roassal1, you could always get a ROMondrianViewBuilder from an ROView, but not the other way around.
You could always ask for the under-lying ROView for ROMondrianView with: mondrianBuilder raw.
So where previously you might have... andShow: [ :a | a roassal painting: [ :mondrianViewBuilder | "do mondrian stuff ...."
I guess it now needs to be modified to... andShow: [ :a | a roassal painting: [ :roassalView | | mondrianViewBuilder := ROMondrianViewBuilder on: roassalView. [ "do mondrian stuff...."
Tx for this suggestion, it didn't cross my mind. Yes it is possible in Roassal2 to ask for a particular builder based on a RTView. RTBuilder new view: aRTView.
or alternatively, perhaps the following would be better... andShow: [ :a | a mondrian painting: [ :mondrianViewBuilder | "do mondrian stuff ...." since this will no longer clash with the original Mondrian.
For me both abstractions are good but mondrian builder is better for new comers because you don't start with Roassal doing a lot of stuff by hand (Roassal stuff). It occurs only when you start integrating some minute details.
BTW, I think it would be better to find a name for RoassalView (as Mondrian represents ROMondrianView) because currently when explaining Roassal, we say Roassal is the name of the tool that allows creating visualizations and it is composed of Mondrian and.... Roassal (the low-level things we can do with ROView). So, for me, a name is needed to describe the latter.
regards.
Usman
cheers -ben
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
It is not that subjective, given that it is based on real usage. But, that is not the point. I simply pointed out that it is often more convenient to obtain the raw view directly from the view.
Doru
On Mon, Mar 24, 2014 at 3:29 PM, Ben Coman btc@openinworld.com wrote:
Tudor Girba wrote:
Hi,
GLMRoassalPresentation supports a custom builder via the initializeWith: block.
However, this is rarely needed given that you can obtain the raw ROView from the Mondrian builder instance. Take a look at:
'Rarely' is subjective :) Being able to get the ROView from a the Mondrians 'rawView' instance variable is not sufficient when you want a really honest-to-goodness-fresh-clean-ROView, since Mondrian has already added things like RODraggableWithVelocity. For the application being developed, its the difference between being in control or not. (ROMondrianViewBuilder new raw) ~= (ROView new). cheers -ben
GLMRoassalPresentation>>roassalDirect "self new roassalDirect openOn: (1 to: 20)"
^ GLMWrapper new with: [ :browser | browser show: [ :a | a roassal initializeView: [ ROView new @ RODraggable ] ; painting: [ :view :numbers | numbers do: [ :number | view add: (ROElement spriteOn: number) + ROLabel ]. ROTreeLayout on: view elements ] ] ]
GLMRoassal2Presentation works similarly. The only difference is that in the GLMRoassal2Presentation, the default view is RTView. However, please keep in mind that Roassal2 does not have quite the same behavior as Roassal.
I was actually hoping that we get a unified way of handling builders. For example, right now to make ROView be interchangeable with ROMondrianViewBuilder, we extend ROView with applyLayout. Alex, would you have time to look into this?
Cheers, Doru
On Mon, Mar 24, 2014 at 2:12 PM, Usman Bhatti usman.bhatti@gmail.comwrote:
On Mon, Mar 24, 2014 at 1:49 PM, Ben Coman btc@openinworld.com wrote:
Usman Bhatti wrote:
Hello,
Is there any particular reason for GLMRoassal2Presentation working with RTView instead of RTMondrianViewBuilder i.e. in the painting block, we get RTView object instead of the builder.
I am asking this question because the predecessor, GLMRoassalPresentation, used to work with ROMondrianViewBuilder. Now, when we'll move our visualizations to work with Roassal2 in Glamour we'll have to make major modifications to the source code because the level of details with RTView and RTMondrianViewBuilder is not the same.
Usman
I've been distracted for a while tackling Pharo 3 bugs leading up to release, but I very pleased to hear of this change. As someone who was using Roassal1 with Glamour sans Mondrian, it was painful and awkward to get a raw ROView without the stuff that Mondrian adds to it. I eventually found a work around that I think got integrated, but it was a bit of a hack. For a long while, it seemed to me that Roassal did not have an independent identity separate from Mondrian. References to Mondrian and Roassal seemed often used interchangeably. Some mixed concerns were understandable since Roassal was (I believe) initially designed to provide an abstraction layer under the Mondrian API. However as Roassal finds broader use beyond Mondrian, things like GLMRoassalPresentation need to be separated from Mondrian. However perhaps there needs to be a new GLMMondrianPresentation, that won't clash with the old Mondrian since as I understand it that has been removed from the current Moose.
Speaking from what I remember of Roassal1, you could always get a ROMondrianViewBuilder from an ROView, but not the other way around.
You could always ask for the under-lying ROView for ROMondrianView with: mondrianBuilder raw.
So where previously you might have... andShow: [ :a | a roassal painting: [ :mondrianViewBuilder | "do mondrian stuff ...."
I guess it now needs to be modified to... andShow: [ :a | a roassal painting: [ :roassalView | | mondrianViewBuilder := ROMondrianViewBuilder on: roassalView. [ "do mondrian stuff...."
Tx for this suggestion, it didn't cross my mind. Yes it is possible in Roassal2 to ask for a particular builder based on a RTView. RTBuilder new view: aRTView.
or alternatively, perhaps the following would be better... andShow: [ :a | a mondrian painting: [ :mondrianViewBuilder | "do mondrian stuff ...." since this will no longer clash with the original Mondrian.
For me both abstractions are good but mondrian builder is better for new comers because you don't start with Roassal doing a lot of stuff by hand (Roassal stuff). It occurs only when you start integrating some minute details.
BTW, I think it would be better to find a name for RoassalView (as Mondrian represents ROMondrianView) because currently when explaining Roassal, we say Roassal is the name of the tool that allows creating visualizations and it is composed of Mondrian and.... Roassal (the low-level things we can do with ROView). So, for me, a name is needed to describe the latter.
regards.
Usman
cheers -ben
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
"Every thing has its own flow"
Moose-dev mailing listMoose-dev@iam.unibe.chhttps://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
-
Alexandre Bergel -
Ben Coman -
Tudor Girba -
Usman Bhatti