One thing that we can't release without is workable snapping. Since more and more people start talking about releasing, I thought I'd ask for an update.
Overall, it seems to me that this area, which was actively worked upon a few months ago, has been abandoned since and is now in some semi-working state. At the very least, the freeze-when-dragging-many-objects bug MUST be fixed. There are many other snapping bugs and RFEs, and there's probably some work that was left unfinished.
Carl, is there any chance you will address the freeze bug in the near future? What about other bugs?
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?
Of course, any insights on the situation, or better yet, help with coding will be much appreciated from anyone.
Thanks!
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
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
participants (2)
-
bulia byak -
Mathieu Dimanche