20 Oct
2012
20 Oct
'12
7:43 p.m.
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:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
<btc(a)openInWorld.com>
wrote:
<2012-10-20-BTC-iec61970cim-browser.png><2012-10-20-BTC-iec61970cim-Terminals&ConnectivyNodes.png>_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev