Smalltalk › Frameworks & Tools › Moose

more rubberbanding & interactions on ROView

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Ben Coman

more rubberbanding & interactions on ROView

With the recent integration of RORubberBand, I have then gone to use it
in my application. What arises is that while the implementation works
well within a single script in ROExample, it is not so well when the
creation of elements is more spread out in different parts of the code,
since these different parts do not have access to the same instance of
RORubberBand. So some further thoughts on rubberbanding for discussion...

1. Since the rubberband operation is between elements, perhaps this
should not be stored inside individual ROElements but more globally in
ROView. That is, perhaps ROView would have its own interactions.

2. Currently to avoid the MNUs due to the target filter condition
processing edges and elements with nil or unsuitable model, in
(RORubebrBand>>initializeElement:) I used (candidateTarget
getInteraction: self ifPresent:) where it is the 'self' that ensures
that source/target elements being compared are applicable to a
particular RORubberband. It is that 'self' that is hard to distribute
to elements that are created from different parts of the code. Perhaps
this mechanism could be replaced by tagging RORubberBand defined in
different elements with a common symbol eg #rubberband1

Or tag the elements associated with a particular rubberbanding are just
tagged the same as the RORubberBand instance stored in the ROView.

3. Perhaps not bother with trying to ensure no exceptions occur in the
execution of the target filter condition, and just mask them out.
Rather than interrupting the program with a MNU, targets elements are
simply excluded if the filter.

What are your thoughts?

cheers -ben

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

RoassalMethodComparison.xls (47K) Download Attachment

abergel

Re: more rubberbanding & interactions on ROView

Hi Ben,

I think that the best to describe your situation is to provide a test that raise this MNU.
The test should use the scenario you would like to see working.
This will help us get our effort focused.

Cheers,
Alexandre

On Oct 18, 2012, at 10:58 PM, Ben Coman <[hidden email]> wrote:

> With the recent integration of RORubberBand, I have then gone to use it in my application. What arises is that while the implementation works well within a single script in ROExample, it is not so well when the creation of elements is more spread out in different parts of the code, since these different parts do not have access to the same instance of RORubberBand. So some further thoughts on rubberbanding for discussion...
>
> 1. Since the rubberband operation is between elements, perhaps this should not be stored inside individual ROElements but more globally in ROView. That is, perhaps ROView would have its own interactions.
>
> 2. Currently to avoid the MNUs due to the target filter condition processing edges and elements with nil or unsuitable model, in (RORubebrBand>>initializeElement:) I used (candidateTarget getInteraction: self ifPresent:) where it is the 'self' that ensures that source/target elements being compared are applicable to a particular RORubberband. It is that 'self' that is hard to distribute to elements that are created from different parts of the code. Perhaps this mechanism could be replaced by tagging RORubberBand defined in different elements with a common symbol eg #rubberband1
>
> Or tag the elements associated with a particular rubberbanding are just tagged the same as the RORubberBand instance stored in the ROView.
>
> 3. Perhaps not bother with trying to ensure no exceptions occur in the execution of the target filter condition, and just mask them out. Rather than interrupting the program with a MNU, targets elements are simply excluded if the filter.
>
> What are your thoughts?
>
> cheers -ben
> <RoassalMethodComparison.xls>_______________________________________________
> 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: more rubberbanding & interactions on ROView

Alexandre,

As a broader scenario from that specific MNU, what I can provide is a snapshot of my project. It is the same one I showed you a few months ago, but converted from the original Mondrian to use the lower-level API of Roassal. In the attached screen shot you can see nested ROEements, each labeled as: ModelClassname "instance identifier". The green-circles are instances of ConnectivityNode and the black-circles are instances of Terminal. ConnectivityNode is a container that holds terminals, as shown by the edges between them. Just for background info, also attached is a cutout from the IEC61970 UML diagram showing relationship of Terminals to ConnectivityNode.

So what I need is to be able to draw edges _only_ from Terminals to ConnectivityNodes (and "maybe" the reverse direction as well). The models of the ROElements come from many different classes, and any conditional block to evaluate acceptance of a drop needs to take account of accessors being different between each class. How is the best way for the Roassal architecture to provide this functionality?

It might be useful (for me :) ) if you could download and have a look at the running project. Browse to "http://files.openinworld.com/ENG8002" and then if you happen to have 7zip on you system, download "20120922-moose47-LEETRICAL.7z" at 19MB or otherwise download "20120922- moose47-LEETRICAL.zip" at 29MB. Vanessa might also like a look.

cheers -ben

Alexandre Bergel wrote:

Hi Ben,

I think that the best to describe your situation is to provide a test that raise this MNU.
The test should use the scenario you would like to see working.
This will help us get our effort focused. 

Cheers,
Alexandre


On Oct 18, 2012, at 10:58 PM, Ben Coman [hidden email] wrote:

1. Since the rubberband operation is between elements, perhaps this should not be stored inside individual ROElements but more globally in ROView. That is, perhaps ROView would have its own interactions.

2. Currently to avoid the MNUs due to the target filter condition processing edges and elements with nil or unsuitable model, in (RORubebrBand>>initializeElement:) I used (candidateTarget getInteraction: self ifPresent:) where it is the 'self' that ensures that source/target elements being compared are applicable to a particular RORubberband. It is that 'self' that is hard to distribute to elements that are created from different parts of the code. Perhaps this mechanism could be replaced by tagging RORubberBand defined in different elements with a common symbol eg #rubberband1

Or tag the elements associated with a particular rubberbanding are just tagged the same as the RORubberBand instance stored in the ROView.

3. Perhaps not bother with trying to ensure no exceptions occur in the execution of the target filter condition, and just mask them out. Rather than interrupting the program with a MNU, targets elements are simply excluded if the filter.

What are your thoughts?

cheers -ben
<RoassalMethodComparison.xls>_______________________________________________
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

2012-10-20-BTC-iec61970cim-browser.png (69K) Download Attachment

2012-10-20-BTC-iec61970cim-Terminals&ConnectivyNodes.png (60K) Download Attachment

abergel

Re: more rubberbanding & interactions on ROView

Hi!

It is nice to see all the enhancements put in place :-)

> So what I need is to be able to draw edges _only_ from Terminals to ConnectivityNodes (and "maybe" the reverse direction as well). The models of the ROElements come from many different classes, and any conditional block to evaluate acceptance of a drop needs to take account of accessors being different between each class. How is the best way for the Roassal architecture to provide this functionality?

You have initiated the support for drag and drop. We should continue.
I am a bit confused still. I have problem to exactly spot what is the behavior you wish to have.

> It might be useful (for me :) ) if you could download and have a look at the running project. Browse to "http://files.openinworld.com/ENG8002" and then if you happen to have 7zip on you system, download "20120922-moose47-LEETRICAL.7z" at 19MB or otherwise download "20120922- moose47-LEETRICAL.zip" at 29MB. Vanessa might also like a look.

I am having a look at it. Looks good! Maybe you could add an info buttons, find, zoom ?

Cheers,
Alexandre

>
> Alexandre Bergel wrote:
>> Hi Ben,
>>
>> I think that the best to describe your situation is to provide a test that raise this MNU.
>> The test should use the scenario you would like to see working.
>> This will help us get our effort focused.
>>
>> Cheers,
>> Alexandre
>>
>>
>> On Oct 18, 2012, at 10:58 PM, Ben Coman
>> <[hidden email]>
>> wrote:
>>
>>
>>
>>> With the recent integration of RORubberBand, I have then gone to use it in my application. What arises is that while the implementation works well within a single script in ROExample, it is not so well when the creation of elements is more spread out in different parts of the code, since these different parts do not have access to the same instance of RORubberBand. So some further thoughts on rubberbanding for discussion...
>>>
>>> 1. Since the rubberband operation is between elements, perhaps this should not be stored inside individual ROElements but more globally in ROView. That is, perhaps ROView would have its own interactions.
>>>
>>> 2. Currently to avoid the MNUs due to the target filter condition processing edges and elements with nil or unsuitable model, in (RORubebrBand>>initializeElement:) I used (candidateTarget getInteraction: self ifPresent:) where it is the 'self' that ensures that source/target elements being compared are applicable to a particular RORubberband. It is that 'self' that is hard to distribute to elements that are created from different parts of the code. Perhaps this mechanism could be replaced by tagging RORubberBand defined in different elements with a common symbol eg #rubberband1
>>>
>>> Or tag the elements associated with a particular rubberbanding are just tagged the same as the RORubberBand instance stored in the ROView.
>>>
>>> 3. Perhaps not bother with trying to ensure no exceptions occur in the execution of the target filter condition, and just mask them out. Rather than interrupting the program with a MNU, targets elements are simply excluded if the filter.
>>>
>>> What are your thoughts?
>>>
>>> cheers -ben
>>> <RoassalMethodComparison.xls>_______________________________________________
>>> Moose-dev mailing list
>>>
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>>
>>
>>
>>
>
> <2012-10-20-BTC-iec61970cim-browser.png><2012-10-20-BTC-iec61970cim-Terminals&ConnectivyNodes.png>_______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Ben Coman

Re: more rubberbanding & interactions on ROView

Alexandre Bergel wrote:

Hi!

It is nice to see all the enhancements put in place :-)

So what I need is to be able to draw edges _only_ from Terminals to ConnectivityNodes (and "maybe" the reverse direction as well).  The models of the ROElements come from many different classes, and any conditional block to evaluate acceptance of a drop needs to take account of accessors being different between each class.  How is the best way for the Roassal architecture to provide this functionality?


You have initiated the support for drag and drop. We should continue.
I am a bit confused still. I have problem to exactly spot what is the behavior you wish to have.

If from the same location you download the "20120503" version, you will see the functionality of what I had previously working. Click the <Open IEC CIM Browser> button, select an item and in the [Instance Model Full View] pane drag a new edge from a black circle (Terminals) to a green circle (ConnectivityNode). That is my specific require. The following discussion is just trying to think the feature more generally about the feature.

In "20120503" you can see how the rubberband definition is split into (EpcimTerminal>>addSubViewTo:) and (EpcimConnectivityNode>>addSubViewTo:) . However that implementation was a bit too invasive by digging bits into the rendering loop. I like better the way we've started implementing RORubebrBand, except this needs to allow for the user definition split between different parts of the codebase rather than requiring a single script like ROExample>>rubberband.

However I'm not sure that there should be two classes RORubberbandDrag & RORubberbandDrop. You have mentioned the similarity with standard drag&drop. An application may want to have rubberband or drag&drop between more than one different pairs of elements or model classes, so perhaps keeping the source/target definition paired makes this easier to keep track of.

Just some random ideas...
1a. RODragDrop sourceModel: Terminal targetModel: ConnectivityNode; rubberBandShape: ROLine.
1b. RODragDrop sourceModel: Terminal targetModel: ConnectivityNode; moveSource.
1c. RODragDrop sourceModels: #(Terminal AnotherClass) target: ConnectivityNode; rubberBandShape: ROOrthoVerticalLineShape.
2. RODragDrop modelDragAccessor: #uiDragFromTerminal modelDropAccessor: #uiDropOnConnectivityNode:
3. RODragDrop elementDragAccessor: [ :source | etc ] elementDropAccessor: #uiDropOnConnectivityNode: ; moveSource

cheers -ben

It might be useful (for me :) ) if you could download and have a look at the running project.  Browse to "http://files.openinworld.com/ENG8002" and then if you happen to have 7zip on you system, download   "20120922-moose47-LEETRICAL.7z"   at 19MB or otherwise download  "20120922- moose47-LEETRICAL.zip"   at 29MB.  Vanessa might also like a look.


I am having a look at it. Looks good! Maybe you could add an info buttons, find, zoom ?

Cheers,
Alexandre

Alexandre Bergel wrote:

Hi Ben,

I think that the best to describe your situation is to provide a test that raise this MNU.
The test should use the scenario you would like to see working.
This will help us get our effort focused. 

Cheers,
Alexandre


On Oct 18, 2012, at 10:58 PM, Ben Coman 
[hidden email]
 wrote:

Or tag the elements associated with a particular rubberbanding are just tagged the same as the RORubberBand instance stored in the ROView.

What are your thoughts?

cheers -ben
<RoassalMethodComparison.xls>_______________________________________________
Moose-dev mailing list

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

<2012-10-20-BTC-iec61970cim-browser.png><2012-10-20-BTC-iec61970cim-Terminals&ConnectivyNodes.png>_______________________________________________
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

Ben Coman

Re: more rubberbanding & interactions on ROView

In reply to this post by abergel

Alexandre Bergel wrote:

Hi!

It is nice to see all the enhancements put in place :-)

So what I need is to be able to draw edges _only_ from Terminals to ConnectivityNodes (and "maybe" the reverse direction as well).  The models of the ROElements come from many different classes, and any conditional block to evaluate acceptance of a drop needs to take account of accessors being different between each class.  How is the best way for the Roassal architecture to provide this functionality?


You have initiated the support for drag and drop. We should continue.
I am a bit confused still. I have problem to exactly spot what is the behavior you wish to have.

It might be useful (for me :) ) if you could download and have a look at the running project.  Browse to "http://files.openinworld.com/ENG8002" and then if you happen to have 7zip on you system, download   "20120922-moose47-LEETRICAL.7z"   at 19MB or otherwise download  "20120922- moose47-LEETRICAL.zip"   at 29MB.  Vanessa might also like a look.


I am having a look at it. Looks good! Maybe you could add an info buttons, find, zoom ?

Yes I plan for those. There are some other areas of my project that demand my attention before I add them. I hav tried zooming before, but since the element sizes are generally drive by the size of text, which doesn't zoom well, I am looking forward to that hopefully being better with Athens. Its great that you've had a look. So now I can describe a couple of other enhancements that would be useful to me.

1. Notice how the ROBorders all bunch up at the left hand side. Perhaps ROBorder could take an offset to ensure a certain gap. This might also provide for having a double-line-border just by ROElement having two ROBorders with a small offset between.

2. In the [Instance Model Full View] tab in the bottom-left pane, when the model scales up, some of the elements with nested children will be so large that they be larger than the canvas, so that there is no view background to grab to pan the view. That is, trying to pan the view by dragging would end up just moving one element. One common feature of other graphics applications that I have found immensely useful is using a held-spacebar to go into a whole-view-pan-mode. This mode is usually indicated by the cursor changing to a hand. This may become a critical feature with a large model.

cheers -ben

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

abergel

Re: more rubberbanding & interactions on ROView

> Yes I plan for those. There are some other areas of my project that demand my attention before I add them. I hav tried zooming before, but since the element sizes are generally drive by the size of text, which doesn't zoom well, I am looking forward to that hopefully being better with Athens. Its great that you've had a look. So now I can describe a couple of other enhancements that would be useful to me.

Roassal works with Athens. In the Roassal repository, there is a package for Athens. Download it and use the athens platform using ROPlatform (class side).

> 1. Notice how the ROBorders all bunch up at the left hand side. Perhaps ROBorder could take an offset to ensure a certain gap. This might also provide for having a double-line-border just by ROElement having two ROBorders with a small offset between.

Why not translating the element a bit?

> 2. In the [Instance Model Full View] tab in the bottom-left pane, when the model scales up, some of the elements with nested children will be so large that they be larger than the canvas, so that there is no view background to grab to pan the view. That is, trying to pan the view by dragging would end up just moving one element. One common feature of other graphics applications that I have found immensely useful is using a held-spacebar to go into a whole-view-pan-mode. This mode is usually indicated by the cursor changing to a hand. This may become a critical feature with a large model.

I see what you mean. An easy thing to do right now, is to use a find button. I am planning to have a small viewer of what is currently seen.
I know Usman has been working on a scroll bar.

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

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