Smalltalk › Frameworks & Tools › Moose

GLMRoassal2Presentation

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Usman Bhatti

GLMRoassal2Presentation

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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

abergel

Re: GLMRoassal2Presentation

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 <[hidden email]> 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
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Ben Coman

Re: GLMRoassal2Presentation

In reply to this post by Usman Bhatti

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
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Usman Bhatti

Re: GLMRoassal2Presentation

On Mon, Mar 24, 2014 at 1:49 PM, Ben Coman <[hidden email]> 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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Tudor Girba-2

Re: GLMRoassal2Presentation

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 <[hidden email]> wrote:

On Mon, Mar 24, 2014 at 1:49 PM, Ben Coman <[hidden email]> 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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Ben Coman

Re: GLMRoassal2Presentation

In reply to this post by Usman Bhatti

Usman Bhatti wrote:

On Mon, Mar 24, 2014 at 1:49 PM, Ben Coman <[hidden email]> 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

I agree - as they say... "different strokes for different folks." Mondrian was definitely good for me to start with (even prior to Roassal) but at that time it seemed that Mondrian was more suited for fast adhoc scripting to generate results than for developing an application. Roassal came along at just the right time for me to open up a lot more flexibility.

To my way of thinking, ROMondrianView is an artifact of developing New-Mondrian-On-Roassal while Old-Mondrian was still in the image. Perhaps it is now worthwhile considering if ROMondrianView now becomes MondrianView and be split out from Roassal so you can say "Mondrian uses Roassal" rather than "Roassal is composed of Mondrian et al". This would put users like GraphET** and others that come along to be on a level footing with Mondrian.

** Does GraphET use raw Roassal or Mondrian API?

cheers -ben

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Ben Coman

Re: GLMRoassal2Presentation

In reply to this post by Tudor Girba-2

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 <[hidden email]> wrote:

On Mon, Mar 24, 2014 at 1:49 PM, Ben Coman <[hidden email]> 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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--

www.tudorgirba.com

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
  

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Tudor Girba-2

Re: GLMRoassal2Presentation

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 <[hidden email]> 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 <[hidden email]> wrote:

On Mon, Mar 24, 2014 at 1:49 PM, Ben Coman <[hidden email]> 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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--

www.tudorgirba.com

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
  
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev