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:
I deliberately do not test the interaction with the Morphic framework.
You're right. Ideally some tests should have become yellow by this
change.
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.
Ok, so at the end
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.
I am checking...
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…
>
> 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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.