6 Apr
2010
6 Apr
'10
3:35 p.m.
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:
--
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 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…
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