![](https://secure.gravatar.com/avatar/f92dcee62bdc0cfdbec5f6e2c611d142.jpg?s=120&d=mm&r=g)
bulia byak a écrit :
Mathieu, I know you were working on some features that were conditional on Carl's work. Can you please give us an update of the current status? What is required to enable your features? Do you think you could help us with the bugs and general cleanup in absence of Carl?
Hi everybody, I just finished a long session of hardwork and took well-earned holidays, parsed the whole 400+ unread messages from the list (at a 100msgs/hour rate, I'm a little bit tired), and now am ready to rejoin the game.
I think I may look at this freeze bug while snapping and correct it if Carl doesn't have the time to do it. I'll wait for him to tell (he proposed to take care of it on 26/04).
As for the visual feedback while snapping, I well remember I was stuck by a big snappingManager-usage-refactoring, involving how snapping really occurs in the whole app (basically, as agreed with Carl, the SnappingManager should be the only one to take final decisions of moving/rotating/etc, that job must _not_ be done by moving or rotating methods as currently done [how could the snappingManager highlight a guide it thinks helped for the snapping if the moveTo method decided another point was to be snapped against another guide ?]). As highlighting requires first to rethink and code the snapping behavior in its wholeness, unwanted snapping issues could popup up, and I'm not sure we are needing that right now, it may be too much work and not enough time to overtest it. For now I have not less than 4 new classes and lots of code, which is obviously a big patch that needs to be well prepared and fully tested. I'd feel safer to procrastinate to after the 0.44 release.
But that means I'm available for bug fixing and smoothing 0.44, I'll wander through blocking issues I could handle.
mtou