Re: [Pharo-project] Roassal Survey

Hi,

On Sun, Oct 7, 2012 at 10:54 PM, Alexandre Bergel
<[hidden email]> wrote:
>>> if you check the sender of #mostSpecificParentCommonWith: then you will see that only the Mondrian builder makes use of it. Currently, and outside the Mondrian DSL, you can insert the edge where you actually want, independently of its extremities.
>>
>> Is there a reason for this "freedom" in Roassal?
>
> Simplicity of the code. Currently there is absolutely no optimization or even caches in Roassal.
> I have the feeling that this point will be crucial when we will have to address some scalable situations.

But, this is not an optimization. Storing edges in reasonable places
is about the meaningfulness of the model. Perhaps it makes sense to
have it like it is now in Roassal, but I think there should be an
explicit reason for it. That is because a graph has essentially two
concepts, and if one of them is randomly placed, the model is only 50%
sound :).

Regarding caches, the original Mondrian had no cache either precisely
because we wanted to keep it open. Caches were introduced only very
late in the Pharo version because you wanted to make it faster :). It
is clear that we learnt that hard and extensive caches impose
limitations and I never argued for them.


>>> I am wondering whether this is what we really want. Shouldn't the element/node be aware of its attachpoint, instead of its edges?
>>
>> I think you should have both. There should be a lookup, where the node
>> should have the priority over the edge.
>
>
> Probably yes.

We tried something like this in Mondrian, but the model was not quite
clean. There, even the layout could set the attachment points. It
would be cool to rethink this part.

Cheers,
Doru


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



--
www.tudorgirba.com

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

Moved to moose-dev...

Alexandre Bergel wrote:

Alexandre,  I think this example shows what I was badly hinting at with my "ROElement>>mostSpecificParentCommonWith:" thread.  This used to decide which level within a hierarchy of sub-element edges are stored.  Referring to the first attachement of Cipirian's post "Figure 2(a)", I think in this case the "inner" edges should be stored as part of the "Composite" element, but I think currently they would be stored in the parent of "Composite".
    

if you check the sender of #mostSpecificParentCommonWith: then you will see that only the Mondrian builder makes use of it. Currently, and outside the Mondrian DSL, you can insert the edge where you actually want, independently of its extremities.

  

Also I had been thinking for a while that it would be nice to be able to have AttachPoints rendered - both as permanently-visible and also visible-on-hover-only, so that when I re-implement the edge rubber-banding to interactive draw lines between elements (which I demoed to you a while ago on Mondrian) the user could drop the edge-end onto a specific AttachPoint.
    

This should be easy to do. 
However before to work on this, I have a question about what Roassal currently offers.
In Roassal, lines knows about the attach points, i.e., the class ROLine has a variable called 'attachPoint', intended to hold an instance of ROAttachPoint. It is therefore not the node the is aware of it. It is more flexible in my opinion than what traditional drawing tools offers.

I am wondering whether this is what we really want. Shouldn't the element/node be aware of its attachpoint, instead of its edges?

Cheers,
Alexandre

  

(Without any hard experience to back this) I would think that Elements more than Edges need to know about attachPoints.   Edges holds links to the 'from' and 'to' nodes, so can easily get to them that way anyway.  Elements don't hold edges so the reverse direction is harder. 

btw, when I was experimenting with the ortho shapes for edges and ROAttachPoint for the first time, my immediate reaction was that this was individual instance of a point-of-attachment.  The way the current implementation actually returns a collection of Points I feel is more like a ROAttachPointStrategy.  I was wondering if the Element should hold individual point-of-attachments - for instance if a connecting edge wants "the next unused attachPoint - or if an attachPoint would look different if more than one edge was connected (like splay out a small bit) - but then I don't know if that is the sort of caching that you've indicated in the past can cause problems.

cheers -ben

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