Inkboard CVS updates
I have committed a number of fixes to the Inkboard CVS http://sourceforge.net/projects/inkboard that address crashes related to buffer overflows. Instructions for building and running Inkboard can be found in my request for Inkboard testers that was posted to this list.
Inkboard should now be much more stable than it previously was, sans conditions like invalid Jabber usernames or passwords. (I haven't gotten around to debugging those yet; I've been chasing down another bug, which is described below.)
In a session between two peers Alice and Bob, if Alice sends a star, spiral, or ellipse, it will show up correctly on Bob's canvas, and (almost) any manipulations that Alice makes will be correctly replicated on Bob's canvas. However, if Bob manipulates the star, spiral, or ellipse in any way, the changes will not be correctly replicated on Alice's canvas. Additionally, Bob will not see the object as a star, spiral, or ellipse -- he will only see it as a path. I think these two problems are related, and since I'm not sure where to start with addressing the first problem, I've been focusing on the second, in the hope that it will cure the first :) I don't think this is a case of missing information: if Bob saves the document, exits, and then reopens it, any star, spiral, or ellipse will be correctly recognized as such, and not just a path. I think there's just something that Inkboard is just not triggering correctly. If anyone has any ideas on where to look or what to look for, I'd greatly appreciate them.
Another, smaller bug: gradient editing is not replicated properly. Pressing "add" will replicate the changes, but the gradient objects themselves fall out of sync.
Finally, just some thoughts about the near-future integration with Inkscape:
Ideally, I'd like to begin merging Inkscape with Inkboard only when all of the bugs have been ironed out of the Inkboard code. That's rather unrealistic, though, especially since the act of merging may expose new bugs anyway! :) So it may be a good idea to create a new branch in the Inkscape codebase specifically for integration with Inkboard, and then merge branches when an acceptable level of robustness is achieved.
-- David
Quick followup:
The Inkboard code is located in [source root]/src/ and [srcroot]/src/dialogs under the names inkboard.cpp and InkboardMsg.cpp. It's not in [srcroot]/src/inkboard. I'm not sure what the latter directory was initially created for, but there's no useful Inkboard code in it.
- David
On Thursday 30 June 2005 09:14 pm, David Yip wrote:
I have committed a number of fixes to the Inkboard CVS http://sourceforge.net/projects/inkboard that address crashes related to buffer overflows. Instructions for building and running Inkboard can be found in my request for Inkboard testers that was posted to this list.
Inkboard should now be much more stable than it previously was, sans conditions like invalid Jabber usernames or passwords. (I haven't gotten around to debugging those yet; I've been chasing down another bug, which is described below.)
In a session between two peers Alice and Bob, if Alice sends a star, spiral, or ellipse, it will show up correctly on Bob's canvas, and (almost) any manipulations that Alice makes will be correctly replicated on Bob's canvas. However, if Bob manipulates the star, spiral, or ellipse in any way, the changes will not be correctly replicated on Alice's canvas. Additionally, Bob will not see the object as a star, spiral, or ellipse -- he will only see it as a path. I think these two problems are related, and since I'm not sure where to start with addressing the first problem, I've been focusing on the second, in the hope that it will cure the first :) I don't think this is a case of missing information: if Bob saves the document, exits, and then reopens it, any star, spiral, or ellipse will be correctly recognized as such, and not just a path. I think there's just something that Inkboard is just not triggering correctly. If anyone has any ideas on where to look or what to look for, I'd greatly appreciate them.
Another, smaller bug: gradient editing is not replicated properly. Pressing "add" will replicate the changes, but the gradient objects themselves fall out of sync.
Finally, just some thoughts about the near-future integration with Inkscape:
Ideally, I'd like to begin merging Inkscape with Inkboard only when all of the bugs have been ironed out of the Inkboard code. That's rather unrealistic, though, especially since the act of merging may expose new bugs anyway! :) So it may be a good idea to create a new branch in the Inkscape codebase specifically for integration with Inkboard, and then merge branches when an acceptable level of robustness is achieved.
-- David
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
David Yip wrote:
Finally, just some thoughts about the near-future integration with Inkscape:
Ideally, I'd like to begin merging Inkscape with Inkboard only when all of the bugs have been ironed out of the Inkboard code. That's rather unrealistic, though, especially since the act of merging may expose new bugs anyway! :) So it may be a good idea to create a new branch in the Inkscape codebase specifically for integration with Inkboard, and then merge branches when an acceptable level of robustness is achieved.
Well, being a separate branch is almost like being in a different repository. I think that a better option would to be add the Jabber functionality as a configure option, which defaults to off. This way it is easy for people to add, but most people won't compile it in. I can help you set this up when you're ready to add the code in.
--Ted
PS - I think the star/spiral stuff might be a namespace issue. You might be only getting parameters in the svg: namespace, not the sodipodi: and inkscape: namespaces.
Quoting Ted Gould <ted@...11...>:
PS - I think the star/spiral stuff might be a namespace issue. You might be only getting parameters in the svg: namespace, not the sodipodi: and inkscape: namespaces.
Dunno. It requires extra work to discriminate by namespace with our current XML API. I have a hard time imagining the inkboard folks doing that.
I suspect the element and its sodipodi:type attribute might be getting transmitted separately.
i.e. the remote client ends up getting a bare svg:path, and immediately creates an SPPath object. The sodipodi:type attribute which would have instructed it to create an SPEllipse or whatever might not arrive until it's too late.
Just a guess though.
-mental
participants (3)
-
unknown＠example.com -
David Yip -
Ted Gould