Google Summer of Code updates needed
Hi all!
One of the key, oft-proven principles of Open Source development is "Release Early, Release Often". This is important because it makes it easier for other people to help you.
I think for our Google Summer of Code students, it will be vital for their learning about Open Source processes to go through at least a couple releases, so they can see how this works in practice.
I know it's a bit different from what we're trained in school to do; in school you have a due date and you (in theory) work on your assignment in secret from other students, and turn it in at the end. Open Source is very different; it's like you take your half-finished assignment to the clubhouse and trade answers with everyone else, and the more you cross-check with each other, the more likely everyone is to get a perfect score. ;-)
Anyway, with the 0.42 release wrapping up, we're at a point where we're ready to integrate work from the Google Summer of Code students.
Michael, David, Greg, and Matthew, can each of you report in on where you are in your work, how we can help you, and what you might be able to add to CVS within the next week or so?
(Also, if you have any questions about getting access to or using CVS, please just ask and we'll get you set up.)
Thanks, Bryce
Quick update because David is without Internet access for the next few days. He can fill in more when he gets back.
He's about ready to commit but I asked him to make some changes to configure.ac so that it will detect loudmouth, and not compile the whiteboard stuff if it isn't available. He just needs to test that feature before committing.
--Ted
Bryce Harrington wrote:
Hi all!
One of the key, oft-proven principles of Open Source development is "Release Early, Release Often". This is important because it makes it easier for other people to help you.
I think for our Google Summer of Code students, it will be vital for their learning about Open Source processes to go through at least a couple releases, so they can see how this works in practice.
I know it's a bit different from what we're trained in school to do; in school you have a due date and you (in theory) work on your assignment in secret from other students, and turn it in at the end. Open Source is very different; it's like you take your half-finished assignment to the clubhouse and trade answers with everyone else, and the more you cross-check with each other, the more likely everyone is to get a perfect score. ;-)
Anyway, with the 0.42 release wrapping up, we're at a point where we're ready to integrate work from the Google Summer of Code students.
Michael, David, Greg, and Matthew, can each of you report in on where you are in your work, how we can help you, and what you might be able to add to CVS within the next week or so?
(Also, if you have any questions about getting access to or using CVS, please just ask and we'll get you set up.)
Thanks, Bryce
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I'm sure Michael will correct some of this (e.g. the event stuff below: I haven't looked at the code), but here are some notes.
Michael mentioned on jabber that his laptop was being repaired and that the laptop had ~6 days of work not present on any other computer. Update: he's since briefly recovered his laptop long enough to get the work back, but may be without a laptop for some time.
The status earlier this week (Tuesday?) was that there was a connection tool started, based on the pen tool. Michael has committed an icon for it to CVS, but hasn't committed any other changes yet. The new tool makes a knot appear at the centre of a shape when the pointer enters that shape, so that the user to can draw a line from that knot to another knot at the centre of another shape.
Currently, the tool just draws a line, it doesn't actually attach the line to the shapes.
The implementation of this (connector-context.cpp, I believe) listens for mouse-enter events from our canvas. "Enter" here is based on the hit-detection logic: thus if the mouse is in the middle of an unfilled shape, then the canvas doesn't consider you to be "inside" that shape. Thus, Michael ignores mouse-leave events, resulting knot appearance behaviour something like "sloppy focus" in window managers (fvwm).
I didn't think of the following when I spoke to Michael, but I wonder whether this will result in bugs on slow machines if one enters the shape too quickly to get a mouse-enter event delivered. Is there a corresponding bbox-enter event to get around this? Or maybe there shouldn't be a knot in the centre of the [bbox of the] shape, maybe there should be a different indication of which object will get the attachment.
Another issue with the current choice of event is that these events currently aren't delivered if the button is down: thus one can draw the lines to knots only with xfig-style click at start and at end rather than by dragging from start to end.
I believe Michael's next step is to hook up with the existing connector code I did last year: this gets us basic connector functionality for people to play with.
Michael has also continued to work a little on the path-routing code he has outside of inkscape. I could write more on the plan for making that logic available to inkscape, but let's defer that discussion until we get there.
pjrm.
On Fri, 29 Jul 2005, Peter Moulder wrote:
I'm sure Michael will correct some of this (e.g. the event stuff below: I haven't looked at the code), but here are some notes.
Michael mentioned on jabber that his laptop was being repaired and that the laptop had ~6 days of work not present on any other computer. Update: he's since briefly recovered his laptop long enough to get the work back, but may be without a laptop for some time.
Yeah, sorry about the delay. I'm only catching up on the mailing list, etc after the computer problems.
This laptop thing is a real pain. I've visited the service people twice in two days, seemingly had the problem fixed by replacement RAM, only to have it die again. The logic board is now being replaced, so I should get it back in a week and a bit. I've just installed Debian on a machine at home and can now build inkscape here at home, and also on my machine at Uni. As Peter mentioned I got a copy of my workspace off it, so nothing lost there, just a waste of time trying to set up a new work environments.
The status earlier this week (Tuesday?) was that there was a connection tool started, based on the pen tool. Michael has committed an icon for it to CVS, but hasn't committed any other changes yet. The new tool makes a knot appear at the centre of a shape when the pointer enters that shape, so that the user to can draw a line from that knot to another knot at the centre of another shape.
Currently, the tool just draws a line, it doesn't actually attach the line to the shapes.
Yes, I have created a connector tool context, that will be used for interacting with connectors. Connectors will just be paths in SVG, and will be marked up as a connector, in much the same way as a star. I felt a seperate context was the best approach since this won't change the behaviour of any existing tools. This is probably best while the tool matures, but also makes sense since there will likely be different classes of users, some interested, some not interested in the diagramming features of Inkscape.
The tool was based on the pen tool simply because this creates paths. I've found the further I've gone into this that extending the DrawContext, just as the pen tool does, may not have been the best approach, since I haven't really been able to make use of much of it's code, though this was always attempted first. I'll likely pull out the DrawContext dependency later, though this doesn't hurt for now.
The tool uses center connection points. Arbitrary connection points, placable by the user would be desirable too, but I've scoped this initial version as just center points, and we can talk about interfaces for other types when there is an inital version for people to see and comment on.
As mentioned the tool shows these connection points, using entry events from the context's item_handler. And doesn't hide them until they are showed for another shape. The item was to save the context having to display all of these when it was switched into, and also saving the user from selecting both shapes they wanted to connect before drawing the connector. This works fairly well, except yes,
I didn't think of the following when I spoke to Michael, but I wonder whether this will result in bugs on slow machines if one enters the shape too quickly to get a mouse-enter event delivered.
Yes, if you move the mouse really quickly into an unfilled shape the connection point isn't displayed. I don't think this is as big problem as it sounds. I wonder how many diagrams would use completly unfilled shapes. ALso, I'm using the standard Inkscape shape selection mechanism, so this is only as much of a problem as only being able to select unfilled shapes with the mouse by clicking exactly on their stroke. FWIW, it works fine for shapes with completely transparent fills. Is there any real difference?
It's funny really, I chose to use this method since it seemed like the simplest to quicly create a connector context for creating and modifying connectors so I could start looking at desired behaviours from the tools for more complex cases. It's turned out to present many small problems of it's own.
Another issue with the current choice of event is that these events currently aren't delivered if the button is down: thus one can draw the lines to knots only with xfig-style click at start and at end rather than by dragging from start to end.
I wanted users to be able to drag from one connection point to another, or click on one, then move the mouse (with a visibile connector being drawn) then click on a second connection point to create a connector. (They can also just do this on the canvas, creating an unattached connector.) Turns out for the click and drag approach, where the user is moving the mouse with the left button depressed, no entry events are passed to the item_handler. I don't actually understand why this is so, and I've looked pretty deep through the events code. I was going to post seperately, but perhaps someone can anwser it here? (It's not due to a knot being dragged by the mouse cursor, as this was my first thought too.)
I believe Michael's next step is to hook up with the existing connector code I did last year: this gets us basic connector functionality for people to play with.
Ok, this code is very close to working. But I still have to do the stuff for allowing users to reroute connectors within the connector context, i.e. moving an existing connectors end-point to attach to a new shape.
Michael has also continued to work a little on the path-routing code he has outside of inkscape.
Yes, the interface for this has been cleaned up, and put in a namespace of it's own. There is a very small amount of logic that needs to be moved from my own diagram editor into the library, but this is literally a couple of functions that wrap other function calls and this is trivial.
In answer to Bryce's original questions, I should be able to commit the connector context functionality to CVS this week.
In general, I've found work on Inkscape to take a lot longer than expected. This is mostly the steep learning curve of figuring out the Inkscape internals. I guess since I am working at a canvas manipulation level, rather than on some fairly self-contained sub-section of the code, I need to look at more code to work on things. I've found it to take a long time to figure out *how* to do things, but then the actual code to do it is usually simple or at least not too complex. I'm also finding it interesting and fun too!
In terms of some of the other aims of SoC, I've kind of become the official Mac person for Inkscape, and have taken part in many of the community aspects of the project. Since I've been using a Mac as my development environment I have also been working on OSX packaging for the release and associated bugs and fixes. I've therefore been active on the mailing list, working with the bug tracker, and answering questions on #inkscape, etc.
Summer of Code is turning out to be quite a valuable experience, and I'm enjoying being a member of the Inkscape development community.
Cheers, Michael
On Jul 29, 2005, at 7:21 PM, Michael Wybrow wrote:
The tool uses center connection points. Arbitrary connection points, placable by the user would be desirable too, but I've scoped this initial version as just center points, and we can talk about interfaces for other types when there is an inital version for people to see and comment on.
There are a few ways we might want to get this going. I'd imagine that more than one would be implemented.
One way would be to specify a connection point by some offset along a path. The code we have implementing the 'startOffset' attribute on the 'textPath' element.
The concept maps nicely at the higher level, and the function call seems easily usable at the low level.
I think that specifying and detecting the points themselves would be a minimal amount of effort (it's nice when code reuse gives you that). The bulk of the effort would probably be in a) changing the 'someone's pointing at me, where's my connection point' code to handle multiple target points and not just a single, and then in b) actually building up the needed set of points.
Others might implement that, but I wanted to bring the idea up so that if you need to comment any extra areas (or retune some areas) you could have that in mind and just toss in a little here and there as you go. And more importantly so that others can consider this and other possible connection point approaches that should be added later.
On Sat, Jul 30, 2005 at 12:21:58PM +1000, Michael Wybrow wrote:
In answer to Bryce's original questions, I should be able to commit the connector context functionality to CVS this week.
Great, thanks for the update Michael, good to hear the progress going on despite the problems.
In general, I've found work on Inkscape to take a lot longer than expected. This is mostly the steep learning curve of figuring out the Inkscape internals. I guess since I am working at a canvas manipulation level, rather than on some fairly self-contained sub-section of the code, I need to look at more code to work on things. I've found it to take a long time to figure out *how* to do things, but then the actual code to do it is usually simple or at least not too complex. I'm also finding it interesting and fun too!
I know how this is. :-) Yes, it's quite easy with the Inkscape code to get in over your head, and need a lot of time to just sort it out. Fortunately, Peter's a good guy to help steer you through it.
This is also one of the reasons I'm pushing you four to get your code in; this way over the coming weeks as you run into problems, you will be able to ask for help and point people at your checked-in code for them to tinker with.
In terms of some of the other aims of SoC, I've kind of become the official Mac person for Inkscape, and have taken part in many of the community aspects of the project. Since I've been using a Mac as my development environment I have also been working on OSX packaging for the release and associated bugs and fixes. I've therefore been active on the mailing list, working with the bug tracker, and answering questions on #inkscape, etc.
Yes, I noticed! This is excellent because in the past we've always had trouble with OSX due to lack of developers working on that platform.
Summer of Code is turning out to be quite a valuable experience, and I'm enjoying being a member of the Inkscape development community.
Good to hear! I'm really pleased with how the program is going, too.
Bryce
Hi all!
One of the key, oft-proven principles of Open Source development is "Release Early, Release Often". This is important because it makes it easier for other people to help you.
I think for our Google Summer of Code students, it will be vital for their learning about Open Source processes to go through at least a couple releases, so they can see how this works in practice.
I know it's a bit different from what we're trained in school to do; in school you have a due date and you (in theory) work on your assignment in secret from other students, and turn it in at the end. Open Source is very different; it's like you take your half-finished assignment to the clubhouse and trade answers with everyone else, and the more you cross-check with each other, the more likely everyone is to get a perfect score. ;-)
Anyway, with the 0.42 release wrapping up, we're at a point where we're ready to integrate work from the Google Summer of Code students.
Michael, David, Greg, and Matthew, can each of you report in on where you are in your work, how we can help you, and what you might be able to add to CVS within the next week or so?
(Also, if you have any questions about getting access to or using CVS, please just ask and we'll get you set up.)
Thanks, Bryce
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi,
I was making good progress and then the group that funds my PhD research said they would take away funding unless we demonstrate some specific details. Needless to say my evenings are now spent in the lab instead of coding. I was importing most common elements common to dxf and svg, and was starting work on elements that were not common. The deadline is Aug 10th for the funding, so after then I hope to hit SOC hard after the 10th and finish it up. As far as exporting from SVG to DXF, there is some coding but as I understand the finer points of the two formats there is not much more than parsing the data and then saving to a file.
I will try to make some time to release some code that can be tested for the import. However don't hold your breath...
Matt
Matt, just as a suggestion - you might try to break your conversion code into small working increments and write a small test program to incrementally test the conversion algorithms. So at this point your program might only draw the lines, or polygons, ... This way you always have something to show and can post and get feedback on each step - sort of the agile/XP approach. Can sympathize with your PhD situation - been there and survived.
Matt Squires wrote:
Hi all!
One of the key, oft-proven principles of Open Source development is "Release Early, Release Often". This is important because it makes it easier for other people to help you.
I think for our Google Summer of Code students, it will be vital for their learning about Open Source processes to go through at least a couple releases, so they can see how this works in practice.
I know it's a bit different from what we're trained in school to do; in school you have a due date and you (in theory) work on your assignment in secret from other students, and turn it in at the end. Open Source is very different; it's like you take your half-finished assignment to the clubhouse and trade answers with everyone else, and the more you cross-check with each other, the more likely everyone is to get a perfect score. ;-)
Anyway, with the 0.42 release wrapping up, we're at a point where we're ready to integrate work from the Google Summer of Code students.
Michael, David, Greg, and Matthew, can each of you report in on where you are in your work, how we can help you, and what you might be able to add to CVS within the next week or so?
(Also, if you have any questions about getting access to or using CVS, please just ask and we'll get you set up.)
Thanks, Bryce
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi,
I was making good progress and then the group that funds my PhD research said they would take away funding unless we demonstrate some specific details. Needless to say my evenings are now spent in the lab instead of coding. I was importing most common elements common to dxf and svg, and was starting work on elements that were not common. The deadline is Aug 10th for the funding, so after then I hope to hit SOC hard after the 10th and finish it up. As far as exporting from SVG to DXF, there is some coding but as I understand the finer points of the two formats there is not much more than parsing the data and then saving to a file.
I will try to make some time to release some code that can be tested for the import. However don't hold your breath...
Matt
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
participants (7)
-
Bryce Harrington -
John Taber -
Jon A. Cruz -
Matt Squires -
Michael Wybrow -
Peter Moulder -
Ted Gould