going to 4.0

> Hi,
>
> We should release 4.0. There are just a handful of issues left for  
> 4.0:
> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>
> Except for 293, the others should be doable pretty fast. Is anyone  
> willing to give a hand this week?
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
>
> "We cannot reach the flow of things unless we let go."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Thanks Doru for tacking the initiative. I sincerelly hope to have  
> more time in two months (at the end of the semester).
>
> I addressed 313. But not in a satisfactory way. You suggested to do  
> a figure selection on a mooseUp. This would require to redesign the  
> drag mechanism since a graph element can be dragged without being  
> selected. I also thought about forcing to release the button before  
> doing a drag. But this would seriously hamper the usability.
>
> The solution I used in the Version 408 says that no drag of more  
> than 200 pixels is permitted by a manual mouse drag. I think this is  
> not so bad.
>
> Is Issue 328 still around? Can we do better than the fix you  
> propose? Today Johan had a very similar idea on how to fix it. To  
> properly fix it, the window change notification is required. But is  
> not included in Pharo 1.0.
>
> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>
> Cheers,
> Alexandre
>
>
> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>
>> Hi,
>>
>> We should release 4.0. There are just a handful of issues left for  
>> 4.0:
>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>
>> Except for 293, the others should be doable pretty fast. Is anyone  
>> willing to give a hand this week?
>>
>> Cheers,
>> Doru
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "We cannot reach the flow of things unless we let go."
>>
>>
>>
>> _______________________________________________
>> 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

> There are a couple of problems left. Simple views work well. It also  
> seems to work in Class Blueprint, but there are problems in the  
> System Complexity. I do not understand why, but if the node is not  
> selected, I cannot see it moving while dragging, but when it gets  
> selected it appears at the destination. If the node is selected  
> first, then there is no redraw at all, so you have to do something  
> with the window to see that it moved. It works when it is not yet  
> selected because selecting it forces a redraw. But why is it not  
> redrawn when the coordinates change? And why does it work in the  
> Class Blueprint?
>
> Also, it looks like dragging a nested node without selecting it,  
> causes the edges to not move with the node. When the node is  
> selected, everything works as expected. I did not spot the root of  
> the problem yet, but it should not be critical.

>
>
>> Thanks Doru for tacking the initiative. I sincerelly hope to have  
>> more time in two months (at the end of the semester).
>>
>> I addressed 313. But not in a satisfactory way. You suggested to do  
>> a figure selection on a mooseUp. This would require to redesign the  
>> drag mechanism since a graph element can be dragged without being  
>> selected. I also thought about forcing to release the button before  
>> doing a drag. But this would seriously hamper the usability.
>>
>> The solution I used in the Version 408 says that no drag of more  
>> than 200 pixels is permitted by a manual mouse drag. I think this  
>> is not so bad.
>>
>> Is Issue 328 still around? Can we do better than the fix you  
>> propose? Today Johan had a very similar idea on how to fix it. To  
>> properly fix it, the window change notification is required. But is  
>> not included in Pharo 1.0.
>>
>> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>>
>> Cheers,
>> Alexandre
>>
>>
>> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>>
>>> Hi,
>>>
>>> We should release 4.0. There are just a handful of issues left for  
>>> 4.0:
>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>>
>>> Except for 293, the others should be doable pretty fast. Is anyone  
>>> willing to give a hand this week?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "We cannot reach the flow of things unless we let go."
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> --
> www.tudorgirba.com
>
> "Being happy is a matter of choice."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

>> There are a couple of problems left. Simple views work well. It  
>> also seems to work in Class Blueprint, but there are problems in  
>> the System Complexity. I do not understand why, but if the node is  
>> not selected, I cannot see it moving while dragging, but when it  
>> gets selected it appears at the destination. If the node is  
>> selected first, then there is no redraw at all, so you have to do  
>> something with the window to see that it moved. It works when it is  
>> not yet selected because selecting it forces a redraw. But why is  
>> it not redrawn when the coordinates change? And why does it work in  
>> the Class Blueprint?
>>
>> Also, it looks like dragging a nested node without selecting it,  
>> causes the edges to not move with the node. When the node is  
>> selected, everything works as expected. I did not spot the root of  
>> the problem yet, but it should not be critical.
>
> In Version 410, I force a canvas update when a node is dragged and  
> drop. This update was done anyway in the method setDefaultHandler.  
> In 410, drag and drop updates the canvas without emitting an event.  
> This should solve what I understood from your problem.

> Cheers,
> Alexandre
>
>>
>>
>>> Thanks Doru for tacking the initiative. I sincerelly hope to have  
>>> more time in two months (at the end of the semester).
>>>
>>> I addressed 313. But not in a satisfactory way. You suggested to  
>>> do a figure selection on a mooseUp. This would require to redesign  
>>> the drag mechanism since a graph element can be dragged without  
>>> being selected. I also thought about forcing to release the button  
>>> before doing a drag. But this would seriously hamper the usability.
>>>
>>> The solution I used in the Version 408 says that no drag of more  
>>> than 200 pixels is permitted by a manual mouse drag. I think this  
>>> is not so bad.
>>>
>>> Is Issue 328 still around? Can we do better than the fix you  
>>> propose? Today Johan had a very similar idea on how to fix it. To  
>>> properly fix it, the window change notification is required. But  
>>> is not included in Pharo 1.0.
>>>
>>> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>>>
>>> Cheers,
>>> Alexandre
>>>
>>>
>>> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>>>
>>>> Hi,
>>>>
>>>> We should release 4.0. There are just a handful of issues left  
>>>> for 4.0:
>>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>>>
>>>> Except for 293, the others should be doable pretty fast. Is  
>>>> anyone willing to give a hand this week?
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "We cannot reach the flow of things unless we let go."
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> --
>> www.tudorgirba.com
>>
>> "Being happy is a matter of choice."
>>
>>
>>
>> _______________________________________________
>> 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

> Hi,
>
> On 6 Apr 2010, at 15:35, Alexandre Bergel wrote:
>
>>> Thanks for the fixes, but 408 is not good :). I did not want a redesign of the Drag and drop. That should remain just the same. I just wanted the figure selection to be announced on mouseUp:.
>>
>> All the test remains green and I haven't noticed any difference when using Mondrian. So that's good.
>
> Actually not really :), because there were no tests affected by my moving the selection in mouseUp:
>
>>> There are a couple of problems left. Simple views work well. It also seems to work in Class Blueprint, but there are problems in the System Complexity. I do not understand why, but if the node is not selected, I cannot see it moving while dragging, but when it gets selected it appears at the destination. If the node is selected first, then there is no redraw at all, so you have to do something with the window to see that it moved. It works when it is not yet selected because selecting it forces a redraw. But why is it not redrawn when the coordinates change? And why does it work in the Class Blueprint?
>>>
>>> Also, it looks like dragging a nested node without selecting it, causes the edges to not move with the node. When the node is selected, everything works as expected. I did not spot the root of the problem yet, but it should not be critical.
>>
>> In Version 410, I force a canvas update when a node is dragged and drop. This update was done anyway in the method setDefaultHandler. In 410, drag and drop updates the canvas without emitting an event. This should solve what I understood from your problem.
>
> Hmm, but that should be triggered in translateBy:. The problem seems to appear when bounded is true because I now reverted to bound false and everything works as expected within Mondrian. Also, when bounded is true and you try to drag and drop outside the area some strange things happen in System Complexity. For example, try to drag a complete hierarchy randomly outside the canvas and see what happens.
>
> However, when embedded in Glamour, there still is an update problem, so in the end I left the update window also in draggable. But, I think that something is missing on the Glamour side.
>
>> How can you drag a node without selecting it?
>
> Right. So, now I added a condition to only allow dragging after selecting the node.
>
> It now looks like it is Ok. Could you double check.
>
> Cheers,
> Doru
>
>
>> Cheers,
>> Alexandre
>>
>>>
>>>
>>>> Thanks Doru for tacking the initiative. I sincerelly hope to have more time in two months (at the end of the semester).
>>>>
>>>> I addressed 313. But not in a satisfactory way. You suggested to do a figure selection on a mooseUp. This would require to redesign the drag mechanism since a graph element can be dragged without being selected. I also thought about forcing to release the button before doing a drag. But this would seriously hamper the usability.
>>>>
>>>> The solution I used in the Version 408 says that no drag of more than 200 pixels is permitted by a manual mouse drag. I think this is not so bad.
>>>>
>>>> Is Issue 328 still around? Can we do better than the fix you propose? Today Johan had a very similar idea on how to fix it. To properly fix it, the window change notification is required. But is not included in Pharo 1.0.
>>>>
>>>> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>
>>>> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We should release 4.0. There are just a handful of issues left for 4.0:
>>>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>>>>
>>>>> Except for 293, the others should be doable pretty fast. Is anyone willing to give a hand this week?
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "We cannot reach the flow of things unless we let go."
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Being happy is a matter of choice."
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> --
> www.tudorgirba.com
>
> "It's not how it is, it is how we see it."
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

>
> I just noticed and added a new issue http://code.google.com/p/moose-technology/issues/detail?id=358
> for 4.0, consecutive to a recent fix, considerable slow down for the  
> Moose importer.
>
>
> Also what needs to be done for the table widget?
>
>
> On 6 avr. 2010, at 16:36, Tudor Girba wrote:
>
>> Hi,
>>
>> On 6 Apr 2010, at 15:35, Alexandre Bergel wrote:
>>
>>>> Thanks for the fixes, but 408 is not good :). I did not want a  
>>>> redesign of the Drag and drop. That should remain just the same.  
>>>> I just wanted the figure selection to be announced on mouseUp:.
>>>
>>> All the test remains green and I haven't noticed any difference  
>>> when using Mondrian. So that's good.
>>
>> Actually not really :), because there were no tests affected by my  
>> moving the selection in mouseUp:
>>
>>>> There are a couple of problems left. Simple views work well. It  
>>>> also seems to work in Class Blueprint, but there are problems in  
>>>> the System Complexity. I do not understand why, but if the node  
>>>> is not selected, I cannot see it moving while dragging, but when  
>>>> it gets selected it appears at the destination. If the node is  
>>>> selected first, then there is no redraw at all, so you have to do  
>>>> something with the window to see that it moved. It works when it  
>>>> is not yet selected because selecting it forces a redraw. But why  
>>>> is it not redrawn when the coordinates change? And why does it  
>>>> work in the Class Blueprint?
>>>>
>>>> Also, it looks like dragging a nested node without selecting it,  
>>>> causes the edges to not move with the node. When the node is  
>>>> selected, everything works as expected. I did not spot the root  
>>>> of the problem yet, but it should not be critical.
>>>
>>> In Version 410, I force a canvas update when a node is dragged and  
>>> drop. This update was done anyway in the method setDefaultHandler.  
>>> In 410, drag and drop updates the canvas without emitting an  
>>> event. This should solve what I understood from your problem.
>>
>> Hmm, but that should be triggered in translateBy:. The problem  
>> seems to appear when bounded is true because I now reverted to  
>> bound false and everything works as expected within Mondrian. Also,  
>> when bounded is true and you try to drag and drop outside the area  
>> some strange things happen in System Complexity. For example, try  
>> to drag a complete hierarchy randomly outside the canvas and see  
>> what happens.
>>
>> However, when embedded in Glamour, there still is an update  
>> problem, so in the end I left the update window also in draggable.  
>> But, I think that something is missing on the Glamour side.
>>
>>> How can you drag a node without selecting it?
>>
>> Right. So, now I added a condition to only allow dragging after  
>> selecting the node.
>>
>> It now looks like it is Ok. Could you double check.
>>
>> Cheers,
>> Doru
>>
>>
>>> Cheers,
>>> Alexandre
>>>
>>>>
>>>>
>>>>> Thanks Doru for tacking the initiative. I sincerelly hope to  
>>>>> have more time in two months (at the end of the semester).
>>>>>
>>>>> I addressed 313. But not in a satisfactory way. You suggested to  
>>>>> do a figure selection on a mooseUp. This would require to  
>>>>> redesign the drag mechanism since a graph element can be dragged  
>>>>> without being selected. I also thought about forcing to release  
>>>>> the button before doing a drag. But this would seriously hamper  
>>>>> the usability.
>>>>>
>>>>> The solution I used in the Version 408 says that no drag of more  
>>>>> than 200 pixels is permitted by a manual mouse drag. I think  
>>>>> this is not so bad.
>>>>>
>>>>> Is Issue 328 still around? Can we do better than the fix you  
>>>>> propose? Today Johan had a very similar idea on how to fix it.  
>>>>> To properly fix it, the window change notification is required.  
>>>>> But is not included in Pharo 1.0.
>>>>>
>>>>> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>>>>>
>>>>> Cheers,
>>>>> Alexandre
>>>>>
>>>>>
>>>>> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We should release 4.0. There are just a handful of issues left  
>>>>>> for 4.0:
>>>>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>>>>>
>>>>>> Except for 293, the others should be doable pretty fast. Is  
>>>>>> anyone willing to give a hand this week?
>>>>>>
>>>>>> Cheers,
>>>>>> Doru
>>>>>>
>>>>>>
>>>>>> --
>>>>>> www.tudorgirba.com
>>>>>>
>>>>>> "We cannot reach the flow of things unless we let go."
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Being happy is a matter of choice."
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> --
>> www.tudorgirba.com
>>
>> "It's not how it is, it is how we see it."
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Simon
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Ahh, my bad. I fixed it:
>
> Name: Famix-Core-tg.109
> Author: tg
> Time: 6 April 2010, 5:59:26 pm
> UUID: 7875d38f-a694-49a6-9762-dc8a94aa5e38
> Ancestors: Famix-Core-tg.108
>
> added a script to initialize the parent type. Also removed the lazy initialization from the parentType to not cause unneccessary performance penalties
>
>
> Cheers,
> Doru
>
>
>
> On 6 Apr 2010, at 17:09, Simon Denier wrote:
>
>>
>> I just noticed and added a new issue http://code.google.com/p/moose-technology/issues/detail?id=358
>> for 4.0, consecutive to a recent fix, considerable slow down for the Moose importer.
>>
>>
>> Also what needs to be done for the table widget?
>>
>>
>> On 6 avr. 2010, at 16:36, Tudor Girba wrote:
>>
>>> Hi,
>>>
>>> On 6 Apr 2010, at 15:35, Alexandre Bergel wrote:
>>>
>>>>> Thanks for the fixes, but 408 is not good :). I did not want a redesign of the Drag and drop. That should remain just the same. I just wanted the figure selection to be announced on mouseUp:.
>>>>
>>>> All the test remains green and I haven't noticed any difference when using Mondrian. So that's good.
>>>
>>> Actually not really :), because there were no tests affected by my moving the selection in mouseUp:
>>>
>>>>> There are a couple of problems left. Simple views work well. It also seems to work in Class Blueprint, but there are problems in the System Complexity. I do not understand why, but if the node is not selected, I cannot see it moving while dragging, but when it gets selected it appears at the destination. If the node is selected first, then there is no redraw at all, so you have to do something with the window to see that it moved. It works when it is not yet selected because selecting it forces a redraw. But why is it not redrawn when the coordinates change? And why does it work in the Class Blueprint?
>>>>>
>>>>> Also, it looks like dragging a nested node without selecting it, causes the edges to not move with the node. When the node is selected, everything works as expected. I did not spot the root of the problem yet, but it should not be critical.
>>>>
>>>> In Version 410, I force a canvas update when a node is dragged and drop. This update was done anyway in the method setDefaultHandler. In 410, drag and drop updates the canvas without emitting an event. This should solve what I understood from your problem.
>>>
>>> Hmm, but that should be triggered in translateBy:. The problem seems to appear when bounded is true because I now reverted to bound false and everything works as expected within Mondrian. Also, when bounded is true and you try to drag and drop outside the area some strange things happen in System Complexity. For example, try to drag a complete hierarchy randomly outside the canvas and see what happens.
>>>
>>> However, when embedded in Glamour, there still is an update problem, so in the end I left the update window also in draggable. But, I think that something is missing on the Glamour side.
>>>
>>>> How can you drag a node without selecting it?
>>>
>>> Right. So, now I added a condition to only allow dragging after selecting the node.
>>>
>>> It now looks like it is Ok. Could you double check.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>>
>>>>>
>>>>>> Thanks Doru for tacking the initiative. I sincerelly hope to have more time in two months (at the end of the semester).
>>>>>>
>>>>>> I addressed 313. But not in a satisfactory way. You suggested to do a figure selection on a mooseUp. This would require to redesign the drag mechanism since a graph element can be dragged without being selected. I also thought about forcing to release the button before doing a drag. But this would seriously hamper the usability.
>>>>>>
>>>>>> The solution I used in the Version 408 says that no drag of more than 200 pixels is permitted by a manual mouse drag. I think this is not so bad.
>>>>>>
>>>>>> Is Issue 328 still around? Can we do better than the fix you propose? Today Johan had a very similar idea on how to fix it. To properly fix it, the window change notification is required. But is not included in Pharo 1.0.
>>>>>>
>>>>>> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>>>>>>
>>>>>> Cheers,
>>>>>> Alexandre
>>>>>>
>>>>>>
>>>>>> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> We should release 4.0. There are just a handful of issues left for 4.0:
>>>>>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>>>>>>
>>>>>>> Except for 293, the others should be doable pretty fast. Is anyone willing to give a hand this week?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Doru
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> www.tudorgirba.com
>>>>>>>
>>>>>>> "We cannot reach the flow of things unless we let go."
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "Being happy is a matter of choice."
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "It's not how it is, it is how we see it."
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Speaking louder won't make the point worthier."
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> doru what was the problem?
>
> Stef
> On Apr 6, 2010, at 6:00 PM, Tudor Girba wrote:
>
>> Ahh, my bad. I fixed it:
>>
>> Name: Famix-Core-tg.109
>> Author: tg
>> Time: 6 April 2010, 5:59:26 pm
>> UUID: 7875d38f-a694-49a6-9762-dc8a94aa5e38
>> Ancestors: Famix-Core-tg.108
>>
>> added a script to initialize the parent type. Also removed the lazy  
>> initialization from the parentType to not cause unneccessary  
>> performance penalties
>>
>>
>> Cheers,
>> Doru
>>
>>
>>
>> On 6 Apr 2010, at 17:09, Simon Denier wrote:
>>
>>>
>>> I just noticed and added a new issue http://code.google.com/p/moose-technology/issues/detail?id=358
>>> for 4.0, consecutive to a recent fix, considerable slow down for  
>>> the Moose importer.
>>>
>>>
>>> Also what needs to be done for the table widget?
>>>
>>>
>>> On 6 avr. 2010, at 16:36, Tudor Girba wrote:
>>>
>>>> Hi,
>>>>
>>>> On 6 Apr 2010, at 15:35, Alexandre Bergel wrote:
>>>>
>>>>>> Thanks for the fixes, but 408 is not good :). I did not want a  
>>>>>> redesign of the Drag and drop. That should remain just the  
>>>>>> same. I just wanted the figure selection to be announced on  
>>>>>> mouseUp:.
>>>>>
>>>>> All the test remains green and I haven't noticed any difference  
>>>>> when using Mondrian. So that's good.
>>>>
>>>> Actually not really :), because there were no tests affected by  
>>>> my moving the selection in mouseUp:
>>>>
>>>>>> There are a couple of problems left. Simple views work well. It  
>>>>>> also seems to work in Class Blueprint, but there are problems  
>>>>>> in the System Complexity. I do not understand why, but if the  
>>>>>> node is not selected, I cannot see it moving while dragging,  
>>>>>> but when it gets selected it appears at the destination. If the  
>>>>>> node is selected first, then there is no redraw at all, so you  
>>>>>> have to do something with the window to see that it moved. It  
>>>>>> works when it is not yet selected because selecting it forces a  
>>>>>> redraw. But why is it not redrawn when the coordinates change?  
>>>>>> And why does it work in the Class Blueprint?
>>>>>>
>>>>>> Also, it looks like dragging a nested node without selecting  
>>>>>> it, causes the edges to not move with the node. When the node  
>>>>>> is selected, everything works as expected. I did not spot the  
>>>>>> root of the problem yet, but it should not be critical.
>>>>>
>>>>> In Version 410, I force a canvas update when a node is dragged  
>>>>> and drop. This update was done anyway in the method  
>>>>> setDefaultHandler. In 410, drag and drop updates the canvas  
>>>>> without emitting an event. This should solve what I understood  
>>>>> from your problem.
>>>>
>>>> Hmm, but that should be triggered in translateBy:. The problem  
>>>> seems to appear when bounded is true because I now reverted to  
>>>> bound false and everything works as expected within Mondrian.  
>>>> Also, when bounded is true and you try to drag and drop outside  
>>>> the area some strange things happen in System Complexity. For  
>>>> example, try to drag a complete hierarchy randomly outside the  
>>>> canvas and see what happens.
>>>>
>>>> However, when embedded in Glamour, there still is an update  
>>>> problem, so in the end I left the update window also in  
>>>> draggable. But, I think that something is missing on the Glamour  
>>>> side.
>>>>
>>>>> How can you drag a node without selecting it?
>>>>
>>>> Right. So, now I added a condition to only allow dragging after  
>>>> selecting the node.
>>>>
>>>> It now looks like it is Ok. Could you double check.
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>>> Cheers,
>>>>> Alexandre
>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks Doru for tacking the initiative. I sincerelly hope to  
>>>>>>> have more time in two months (at the end of the semester).
>>>>>>>
>>>>>>> I addressed 313. But not in a satisfactory way. You suggested  
>>>>>>> to do a figure selection on a mooseUp. This would require to  
>>>>>>> redesign the drag mechanism since a graph element can be  
>>>>>>> dragged without being selected. I also thought about forcing  
>>>>>>> to release the button before doing a drag. But this would  
>>>>>>> seriously hamper the usability.
>>>>>>>
>>>>>>> The solution I used in the Version 408 says that no drag of  
>>>>>>> more than 200 pixels is permitted by a manual mouse drag. I  
>>>>>>> think this is not so bad.
>>>>>>>
>>>>>>> Is Issue 328 still around? Can we do better than the fix you  
>>>>>>> propose? Today Johan had a very similar idea on how to fix it.  
>>>>>>> To properly fix it, the window change notification is  
>>>>>>> required. But is not included in Pharo 1.0.
>>>>>>>
>>>>>>> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Alexandre
>>>>>>>
>>>>>>>
>>>>>>> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We should release 4.0. There are just a handful of issues  
>>>>>>>> left for 4.0:
>>>>>>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>>>>>>>
>>>>>>>> Except for 293, the others should be doable pretty fast. Is  
>>>>>>>> anyone willing to give a hand this week?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Doru
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> www.tudorgirba.com
>>>>>>>>
>>>>>>>> "We cannot reach the flow of things unless we let go."
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>
>>>>>> --
>>>>>> www.tudorgirba.com
>>>>>>
>>>>>> "Being happy is a matter of choice."
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "It's not how it is, it is how we see it."
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> Simon
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Speaking louder won't make the point worthier."
>>
>> _______________________________________________
>> 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

>> In Version 410, I force a canvas update when a node is dragged and  
>> drop. This update was done anyway in the method setDefaultHandler.  
>> In 410, drag and drop updates the canvas without emitting an event.  
>> This should solve what I understood from your problem.
>
> Hmm, but that should be triggered in translateBy:. The problem seems  
> to appear when bounded is true because I now reverted to bound false  
> and everything works as expected within Mondrian. Also, when bounded  
> is true and you try to drag and drop outside the area some strange  
> things happen in System Complexity. For example, try to drag a  
> complete hierarchy randomly outside the canvas and see what happens.
>
> However, when embedded in Glamour, there still is an update problem,  
> so in the end I left the update window also in draggable. But, I  
> think that something is missing on the Glamour side.

>>>
>>>
>>>> Thanks Doru for tacking the initiative. I sincerelly hope to have  
>>>> more time in two months (at the end of the semester).
>>>>
>>>> I addressed 313. But not in a satisfactory way. You suggested to  
>>>> do a figure selection on a mooseUp. This would require to  
>>>> redesign the drag mechanism since a graph element can be dragged  
>>>> without being selected. I also thought about forcing to release  
>>>> the button before doing a drag. But this would seriously hamper  
>>>> the usability.
>>>>
>>>> The solution I used in the Version 408 says that no drag of more  
>>>> than 200 pixels is permitted by a manual mouse drag. I think this  
>>>> is not so bad.
>>>>
>>>> Is Issue 328 still around? Can we do better than the fix you  
>>>> propose? Today Johan had a very similar idea on how to fix it. To  
>>>> properly fix it, the window change notification is required. But  
>>>> is not included in Pharo 1.0.
>>>>
>>>> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>
>>>> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We should release 4.0. There are just a handful of issues left  
>>>>> for 4.0:
>>>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>>>>
>>>>> Except for 293, the others should be doable pretty fast. Is  
>>>>> anyone willing to give a hand this week?
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "We cannot reach the flow of things unless we let go."
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Being happy is a matter of choice."
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> --
> www.tudorgirba.com
>
> "It's not how it is, it is how we see it."
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev