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=milesto... > > 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 > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> 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.

> 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.

How can you drag a node without selecting it?

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=milesto... >>> >>> 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 >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Being happy is a matter of choice." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch 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=milesto... >>>>> >>>>> 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 >>>>> Moose-dev(a)iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Being happy is a matter of choice." >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> 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 > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch 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=milesto... >>>>>>> >>>>>>> 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 >>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev(a)iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Being happy is a matter of choice." >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> 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 >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Speaking louder won't make the point worthier." > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev