Hi all,
I'm hearing some rumblings that Google will be running their Summer of Code project again this year, and want to put out a proposal for discussion about how we should handle it this year.
SoC has been great for bringing new ideas to Inkscape from a number of sources, yet often the newly written code needs follow up work to sand rough corners or to make it fit more correctly within our architecture. However, between SoC mentoring during the summers, and release work at other parts of the year, core developers haven't really had a good solid amount of time to focus on this digestion. There is concern that another summer's worth of code would put us further behind in this regard.
Of course, given the major benefits that have accrued from our past involvement, it would be a shame to have to sit it out!
But I think there is a compromise which will solve this, if we set two criteria for this year's involvement:
1. All Inkscape GSoC projects this year must be implemented as extensions, with no changes required to Inkscape's core
2. All mentoring be done by developers who will not be focusing on the 0.47 codebase refactoring efforts. (In particular, developers with good extension development experience.) We will limit the number of candidates we accept to the number of mentors available.
I think this approach will prove valuable in a few different ways. First, extension writing is likely going to be a much easier learning curve for students than learning to build and work within inkscape's codebase. Second, it keeps their code distinct and discrete from inkscape's codebase, avoiding any increase in 'entropy' in our core code. Third, it will help add value to our extension community, and give them resources to do achieve things that would have had trouble competing against core codebase feature priorities.
Please let me know what are your thoughts on this proposal? If you support it and have written extensions before, would you also be willing to be a mentor?
Bryce
Bryce Harrington wrote:
- All Inkscape GSoC projects this year must be implemented as extensions, with no changes required to Inkscape's core
I agree whole-heartedly with the premise. I was recently expressing my feelings that the need for the codebase to be in good shape for GSoC has discouraged us from doing serious refactoring. But is condition 1 really feasible? Seems like a very limiting condition. Will it implementing projects as extensions really allow developers to bang away at major refactoring? Or will we still feel the need to hold off, because any major breakage will still cause problems with extensions? What percentage of past completed projects were extensions?
Aaron Spike
On Sun, Feb 24, 2008 at 06:29:21AM -0600, Aaron Spike wrote:
Bryce Harrington wrote:
- All Inkscape GSoC projects this year must be implemented as extensions, with no changes required to Inkscape's core
I agree whole-heartedly with the premise. I was recently expressing my feelings that the need for the codebase to be in good shape for GSoC has discouraged us from doing serious refactoring. But is condition 1 really feasible? Seems like a very limiting condition. Will it implementing projects as extensions really allow developers to bang away at major refactoring? Or will we still feel the need to hold off, because any major breakage will still cause problems with extensions?
I was thinking we'd ask that they develop against the 0.46.x release, which would avoid these issues.
Bryce
Bryce Harrington wrote:
On Sun, Feb 24, 2008 at 06:29:21AM -0600, Aaron Spike wrote:
Bryce Harrington wrote:
- All Inkscape GSoC projects this year must be implemented as extensions, with no changes required to Inkscape's core
I agree whole-heartedly with the premise. I was recently expressing my feelings that the need for the codebase to be in good shape for GSoC has discouraged us from doing serious refactoring. But is condition 1 really feasible? Seems like a very limiting condition. Will it implementing projects as extensions really allow developers to bang away at major refactoring? Or will we still feel the need to hold off, because any major breakage will still cause problems with extensions?
I was thinking we'd ask that they develop against the 0.46.x release, which would avoid these issues.
0.46!?!? That's so old.
Perhaps we could encourage students to take on refactoring tasks as projects. I really can't see the wisdom in making artificial restrictions. Decisions on a case by case basis seems best. That said, the refactoring that needs to be done is very important for moving forward. And it is best to make it a priority.
Aaron Spike
I'd have thought that kills a lot of potential. How about we just make them use branches rather than head and are more selective about when it gets checked back into head? Its probably also a function of the number of them, maybe we should take less so that we dont tie up as many devs and cause as much churn? Half the idea is to get them working in a project environment too, which isolating them to extensions wont do either.
just my 2c
Sim
On Sun, Feb 24, 2008 at 2:18 AM, Bryce Harrington <bryce@...961...> wrote:
Hi all,
I'm hearing some rumblings that Google will be running their Summer of Code project again this year, and want to put out a proposal for discussion about how we should handle it this year.
SoC has been great for bringing new ideas to Inkscape from a number of sources, yet often the newly written code needs follow up work to sand rough corners or to make it fit more correctly within our architecture. However, between SoC mentoring during the summers, and release work at other parts of the year, core developers haven't really had a good solid amount of time to focus on this digestion. There is concern that another summer's worth of code would put us further behind in this regard.
Of course, given the major benefits that have accrued from our past involvement, it would be a shame to have to sit it out!
But I think there is a compromise which will solve this, if we set two criteria for this year's involvement:
All Inkscape GSoC projects this year must be implemented as extensions, with no changes required to Inkscape's core
All mentoring be done by developers who will not be focusing on the 0.47 codebase refactoring efforts. (In particular, developers with good extension development experience.) We will limit the number of candidates we accept to the number of mentors available.
I think this approach will prove valuable in a few different ways. First, extension writing is likely going to be a much easier learning curve for students than learning to build and work within inkscape's codebase. Second, it keeps their code distinct and discrete from inkscape's codebase, avoiding any increase in 'entropy' in our core code. Third, it will help add value to our extension community, and give them resources to do achieve things that would have had trouble competing against core codebase feature priorities.
Please let me know what are your thoughts on this proposal? If you support it and have written extensions before, would you also be willing to be a mentor?
Bryce
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, Feb 24, 2008 at 09:30:00AM -0500, john cliff wrote:
I'd have thought that kills a lot of potential. How about we just make them use branches rather than head and are more selective about when it gets checked back into head? Its probably also a function of the number of them, maybe we should take less so that we dont tie up as many devs and cause as much churn?
It does impose some constraints, but I think it's a better option than sitting out SoC entirely this year. And constraints can sometimes have benefits - like doing B&W photography, it can eliminate a lot of complexity and let you focus on what really matters in your work.
We've certainly encouraged SoC'ers to use branches in the past. In this case it wouldn't help - it delays the added integration work, but doesn't let us avoid it. Indeed, given that our refactoring work is likely to move files around in the tree, eliminate some APIs and add others, the integration could become even more work than usual, and the more it's delayed the more work it becomes.
For similar reasons, while reducing the number of SoC projects may help, I think we maximize our benefit by having no inkscape-core SoC projects. A related idea would be to have the SoC projects be focused on the cleanup and refactoring work; I'm undecided on this - refactoring can require a depth of experience with the codebase that a fresh person may not have, but on the other hand if well directed a smart enthusiastic student could help steamroll through the work.
Half the idea is to get them working in a project environment too, which isolating them to extensions wont do either.
I agree that it's beneficial to give them a good project environment experience, but I don't think this will be isolating. Indeed, if all the projects are doing extension work, then they will be able to collaborate, share notes, code, and ideas and build up an inkscape extensions sub-community.
Obviously, it will be critical that we have good mentors who can help build this environment, and I'd consider this as a strong pre-requisite.
Bryce
well... I am thinking about sending an application for SoC this year. ( yeah, I am an engineering student at university) I am not sure yet what will be my proposal of work, but I am thinking mostly about 2 things:
* User-Friendly (non-advanced) UI for filter effects The current filters dialog is a direct mapping of the SVG internals. It would be nice to have a set of prebuild filter effects with a high level abstraction so that the filters would make more sense for newbies. The current (0.46) filters dialog would become the advanced portion of filter settings UI.
* Implementation of SVG Fonts I am a lot interested on seeing this working on Inkscape. SVG fonts seem to be a lot important for document semantics, localization and acessibility.
I guess that only the first idea could possibly be implemented using extensions, but not the SVG Fonts, of course.
Juca
On Sun, 2008-02-24 at 14:28 -0800, Bryce Harrington wrote:
On Sun, Feb 24, 2008 at 09:30:00AM -0500, john cliff wrote:
I'd have thought that kills a lot of potential. How about we just make them use branches rather than head and are more selective about when it gets checked back into head? Its probably also a function of the number of them, maybe we should take less so that we dont tie up as many devs and cause as much churn?
It does impose some constraints, but I think it's a better option than sitting out SoC entirely this year. And constraints can sometimes have benefits - like doing B&W photography, it can eliminate a lot of complexity and let you focus on what really matters in your work.
We've certainly encouraged SoC'ers to use branches in the past. In this case it wouldn't help - it delays the added integration work, but doesn't let us avoid it. Indeed, given that our refactoring work is likely to move files around in the tree, eliminate some APIs and add others, the integration could become even more work than usual, and the more it's delayed the more work it becomes.
For similar reasons, while reducing the number of SoC projects may help, I think we maximize our benefit by having no inkscape-core SoC projects. A related idea would be to have the SoC projects be focused on the cleanup and refactoring work; I'm undecided on this - refactoring can require a depth of experience with the codebase that a fresh person may not have, but on the other hand if well directed a smart enthusiastic student could help steamroll through the work.
Half the idea is to get them working in a project environment too, which isolating them to extensions wont do either.
I agree that it's beneficial to give them a good project environment experience, but I don't think this will be isolating. Indeed, if all the projects are doing extension work, then they will be able to collaborate, share notes, code, and ideas and build up an inkscape extensions sub-community.
Obviously, it will be critical that we have good mentors who can help build this environment, and I'd consider this as a strong pre-requisite.
Bryce
How about this rule:
1.) Newbies to Inkscape must submit proposal with the infrastructure using the extension system
2.) Established developers who have either SVN commit access or 2 substantial patches can submit a proposal in any area.
The above approach takes into account the two possible types of submitter to GSoC, but also sets the bar high for deeper work...
Jon
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
That sounds like a reasonable compromise
On Sun, Feb 24, 2008 at 7:49 PM, Jon Phillips <jon@...235...> wrote:
On Sun, 2008-02-24 at 14:28 -0800, Bryce Harrington wrote:
On Sun, Feb 24, 2008 at 09:30:00AM -0500, john cliff wrote:
I'd have thought that kills a lot of potential. How about we just make
them
use branches rather than head and are more selective about when it
gets
checked back into head? Its probably also a function of the number of
them,
maybe we should take less so that we dont tie up as many devs and
cause as
much churn?
It does impose some constraints, but I think it's a better option than sitting out SoC entirely this year. And constraints can sometimes have benefits - like doing B&W photography, it can eliminate a lot of complexity and let you focus on what really matters in your work.
We've certainly encouraged SoC'ers to use branches in the past. In this case it wouldn't help - it delays the added integration work, but
doesn't
let us avoid it. Indeed, given that our refactoring work is likely to move files around in the tree, eliminate some APIs and add others, the integration could become even more work than usual, and the more it's delayed the more work it becomes.
For similar reasons, while reducing the number of SoC projects may help, I think we maximize our benefit by having no inkscape-core SoC projects. A related idea would be to have the SoC projects be focused on the cleanup and refactoring work; I'm undecided on this - refactoring can require a depth of experience with the codebase that a fresh person may not have, but on the other hand if well directed a smart enthusiastic student could help steamroll through the work.
Half the idea is to get them working in a project environment too,
which
isolating them to extensions wont do either.
I agree that it's beneficial to give them a good project environment experience, but I don't think this will be isolating. Indeed, if all the projects are doing extension work, then they will be able to collaborate, share notes, code, and ideas and build up an inkscape extensions sub-community.
Obviously, it will be critical that we have good mentors who can help build this environment, and I'd consider this as a strong pre-requisite.
Bryce
How about this rule:
1.) Newbies to Inkscape must submit proposal with the infrastructure using the extension system
2.) Established developers who have either SVN commit access or 2 substantial patches can submit a proposal in any area.
The above approach takes into account the two possible types of submitter to GSoC, but also sets the bar high for deeper work...
Jon
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-- Jon Phillips
San Francisco, CA CHINA PH +86 1-360-282-8624 jon@...235... http://www.rejon.org
MSN, AIM, Yahoo Chat, Skype: kidproto Jabber Chat: rejon@...896... IRC: rejon@...897...
Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) Creative Commons (www.creativecommons.org) San Francisco Art Institute (www.sfai.edu)
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Jon Phillips Sent: maandag 25 februari 2008 1:50 To: Bryce Harrington Cc: inkscape-devel@lists.sourceforge.net; john cliff Subject: Re: [Inkscape-devel] Inkscape / GSoC '08 proposal
On Sun, 2008-02-24 at 14:28 -0800, Bryce Harrington wrote:
On Sun, Feb 24, 2008 at 09:30:00AM -0500, john cliff wrote:
I'd have thought that kills a lot of potential. How about we just make them use branches rather than head and are more
selective about
when it gets checked back into head? Its probably also a
function
of the number of them, maybe we should take less so that
we dont tie
up as many devs and cause as much churn?
It does impose some constraints, but I think it's a better
option than
sitting out SoC entirely this year. And constraints can sometimes have benefits - like doing B&W photography, it can
eliminate a lot of
complexity and let you focus on what really matters in your work.
We've certainly encouraged SoC'ers to use branches in the past. In this case it wouldn't help - it delays the added
integration work, but
doesn't let us avoid it. Indeed, given that our
refactoring work is
likely to move files around in the tree, eliminate some
APIs and add
others, the integration could become even more work than usual, and the more it's delayed the more work it becomes.
For similar reasons, while reducing the number of SoC projects may help, I think we maximize our benefit by having no
inkscape-core SoC
projects. A related idea would be to have the SoC projects
be focused
on the cleanup and refactoring work; I'm undecided on this - refactoring can require a depth of experience with the
codebase that a
fresh person may not have, but on the other hand if well directed a smart enthusiastic student could help steamroll through the work.
Half the idea is to get them working in a project
environment too,
which isolating them to extensions wont do either.
I agree that it's beneficial to give them a good project
environment
experience, but I don't think this will be isolating.
Indeed, if all
the projects are doing extension work, then they will be able to collaborate, share notes, code, and ideas and build up an inkscape extensions sub-community.
Obviously, it will be critical that we have good mentors
who can help
build this environment, and I'd consider this as a strong pre-requisite.
Bryce
How about this rule:
1.) Newbies to Inkscape must submit proposal with the infrastructure using the extension system
2.) Established developers who have either SVN commit access or 2 substantial patches can submit a proposal in any area.
The above approach takes into account the two possible types of submitter to GSoC, but also sets the bar high for deeper work...
To be honest, I find the 'extensions only' very limiting, so I like this compromise. Maybe incorrect, but I read the 'extensions only' as: python scripts only. I understand that new developers need time to get used to Inkscape's codebase, but devs like me can (and, personally, want to) go much much deeper.
Probably the time for gsoc's projects is really to short to do anything substantial and bugproof it aswell. Working in a separate branch is very nice, and I recommend it to all gsoccers. However, less people will use that branch to check for bugs and useability issues. For example, my LPE work was largely unnoted when it was a branch, except for a handful of people testing and commenting (thanks you guys!). But a lot of bugs were still unnoted and only became apparant a long time after gsoc had ended. In short: I am against keeping gsoc projects in branch until their end, they should be merged in and get some user attention before it.
What might be a good idea: have the first part of gsoc in branches. Then release 0.47, then merge gsoc into trunk for 0.48. This leaves very little time for 0.47 development though...
In any case, my GSoC'08 ideas for my own application could be: -1- LPE plugins (note the word LPE in front. I really first want plugins only for LPE, not tools, not other things, just LPE. It's because I have no experience with any plugin system coding, and I already have a good idea of what API must be available for LPE plugins. So, although it sounds exciting to have pluginable code, don't expect too much !) -2- Since refactoring was brought up: I'd be happy to work on 2geom integration. -3- Improved node editing: multiple paths, mask/clip on-canvas (already done ;), ... easiest
Sorry if this mail reads like a long rambling, Regards, Johan
In any case, my GSoC'08 ideas for my own application could be: -1- LPE plugins (note the word LPE in front. I really first want plugins only for LPE, not tools, not other things, just LPE. It's because I have no experience with any plugin system coding, and I already have a good idea of what API must be available for LPE plugins. So, although it sounds exciting to have pluginable code, don't expect too much !) -2- Since refactoring was brought up: I'd be happy to work on 2geom integration. -3- Improved node editing: multiple paths, mask/clip on-canvas (already done ;), ... easiest
If anyone is looking for a small simple project that would make great impact they should think about working with me on the simple animation plan; although I've not had a lot of time to work on it other than reading inkscape codebase, I do believe the plan to be a solid starting point.
On Tue, Feb 26, 2008 at 3:15 AM, <J.B.C.Engelen@...1578...> wrote:
-3- Improved node editing: multiple paths
if you get there before me, make sure to talk to me first - I have added some groundwork for that but didn't have time to actually finish it
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: dinsdag 26 februari 2008 21:55 To: Engelen, J.B.C. (Johan) Cc: jon@...235...; bryce@...1798...; inkscape-devel@lists.sourceforge.net; john.cliff@...400... Subject: Re: [Inkscape-devel] Inkscape / GSoC '08 proposal
On Tue, Feb 26, 2008 at 3:15 AM, <J.B.C.Engelen@...1578...> wrote:
-3- Improved node editing: multiple paths
if you get there before me, make sure to talk to me first - I have added some groundwork for that but didn't have time to actually finish it
I know :-) Actually, I'll just let you finish it. Seems too small a thing for a whole GSoC anyway.
Cheers, Johan
On Tue, Feb 26, 2008 at 09:15:53AM +0100, J.B.C.Engelen@...1578... wrote:
Behalf Of Jon Phillips
How about this rule:
1.) Newbies to Inkscape must submit proposal with the infrastructure using the extension system
2.) Established developers who have either SVN commit access or 2 substantial patches can submit a proposal in any area.
To be honest, I find the 'extensions only' very limiting, so I like this compromise. Maybe incorrect, but I read the 'extensions only' as: python scripts only. I understand that new developers need time to get used to Inkscape's codebase, but devs like me can (and, personally, want to) go much much deeper.
Well, for past participants who would like to spend their summer working again on Inkscape, I certainly wouldn't want to impose a restriction that would prevent this from happening.
For #2, I think it would fit within our underlying motivation for GSoC if proposals to work on inkscape-core for the summer fit within our refactoring/code-cleanup plans. So for instance:
* Fix bugs reported in LP against the code they worked on last summer * Rearchitect code to fit better within the overall Inkscape framework * Extracts shareable code from Inkscape into a library
Bryce
On Tue, 2008-02-26 at 13:12 -0800, Bryce Harrington wrote:
On Tue, Feb 26, 2008 at 09:15:53AM +0100, J.B.C.Engelen@...1578... wrote:
Behalf Of Jon Phillips
How about this rule:
1.) Newbies to Inkscape must submit proposal with the infrastructure using the extension system
2.) Established developers who have either SVN commit access or 2 substantial patches can submit a proposal in any area.
To be honest, I find the 'extensions only' very limiting, so I like this compromise. Maybe incorrect, but I read the 'extensions only' as: python scripts only. I understand that new developers need time to get used to Inkscape's codebase, but devs like me can (and, personally, want to) go much much deeper.
Well, for past participants who would like to spend their summer working again on Inkscape, I certainly wouldn't want to impose a restriction that would prevent this from happening.
For #2, I think it would fit within our underlying motivation for GSoC if proposals to work on inkscape-core for the summer fit within our refactoring/code-cleanup plans. So for instance:
- Fix bugs reported in LP against the code they worked on last summer
- Rearchitect code to fit better within the overall Inkscape framework
- Extracts shareable code from Inkscape into a library
Bryce
That's sounds like a great plan that keeps the project on target and focused gSoc'rs
:) Jon
On Tue, 2008-02-26 at 09:15 +0100, J.B.C.Engelen@...1578... wrote:
To be honest, I find the 'extensions only' very limiting, so I like this compromise. Maybe incorrect, but I read the 'extensions only' as: python scripts only. I understand that new developers need time to get used to Inkscape's codebase, but devs like me can (and, personally, want to) go much much deeper.
I don't think that this means things have to be python. There are many non-python extensions. Some good examples would be the wmf importer, pdf (in and out) and all the bitmap tools.
In any case, my GSoC'08 ideas for my own application could be: -1- LPE plugins (note the word LPE in front. I really first want plugins only for LPE, not tools, not other things, just LPE. It's because I have no experience with any plugin system coding, and I already have a good idea of what API must be available for LPE plugins. So, although it sounds exciting to have pluginable code, don't expect too much !)
I would rather rephrase this: "integrate LPE into the current extensions system".
This should involve making a subclass of Inkscape::Extension::Extension for live path effects and adding the appropriate functions into the prototype of Inkscape::Extension::Implementation::Implementation so that implementations can be built. Also, porting the current LPEs to be subclasses of Implementation. Oh, and making the parameters do the local stuff.
--Ted
On Sun, Feb 24, 2008 at 2:18 AM, Bryce Harrington <bryce@...961...> wrote:
- All Inkscape GSoC projects this year must be implemented as extensions, with no changes required to Inkscape's core
I think this only makes sense after Johan implements his tools-as-plugins idea.
And in any case, we must make exemption for people willing to implement missing SVG support, such as SVG fonts.
Also, although we didn't have such students before (or at least, not successful ones), if someone comes up with a well-researched plan to improve the consistency and usability of the UI without going too deep into the core architecture, I think we should approve that as well.
In other words, I think this is best decided on a case-per-case basis :)
bulia byak wrote:
On Sun, Feb 24, 2008 at 2:18 AM, Bryce Harrington <bryce@...961...> wrote:
- All Inkscape GSoC projects this year must be implemented as extensions, with no changes required to Inkscape's core
I think this only makes sense after Johan implements his tools-as-plugins idea.
And in any case, we must make exemption for people willing to implement missing SVG support, such as SVG fonts.
Also, although we didn't have such students before (or at least, not successful ones), if someone comes up with a well-researched plan to improve the consistency and usability of the UI without going too deep into the core architecture, I think we should approve that as well.
In other words, I think this is best decided on a case-per-case basis :)
I really like this approach the best.
-Josh
On Sat, 2008-02-23 at 23:18 -0800, Bryce Harrington wrote:
But I think there is a compromise which will solve this, if we set two criteria for this year's involvement:
- All Inkscape GSoC projects this year must be implemented as extensions, with no changes required to Inkscape's core
Agreed.
- All mentoring be done by developers who will not be focusing on the 0.47 codebase refactoring efforts. (In particular, developers with good extension development experience.) We will limit the number of candidates we accept to the number of mentors available.
I think it should depend on the individual mentor. I think almost everyone should have some kind of hand in the refactoring, so by definition that would give us no mentors. Also, it would depend on the time that each mentor has to give.
Now, I think that this is a good time to discuss ideas for projects, and I'll dump my Tomboy note :)
* Extension to spell check whole document. Perhaps grammar check also. This extension should go through all of the text boxes, separate text and comments and allow the user to correct the problems. While we have the spell checking in the text dialog, it's a pain to go through as a "final proof" and ensure that all your text is sane. * Run diff tools on the XML document created by scripts so that only the diffs are merged into the tree. Currently the scripting interface basically sends an XML file, and takes the returned XML file at face values. What would be better is if the scripting interface detected the change in the document, and only applied those to the tree. There are some good algorithms for this from the folks that did Union. It would increase the speed of execution for the scripts and reduce the amount of data that they throw on the undo stack. * KML/SVG exchange scripts. I have mentors for these already committed. Seriously, good people. This is a high visibility project, probably get you friends at Google :) * Openstreetmaps Import. Currently OSM generates a set of XML data, transforms it via XSLT into SVG and then renders it in Inkscape. I'd like to see an import extension that allows you to specify the data you want, pulls it from OSM, and then imports it into Inkscape. This would be useful for people making a maps.
Okay, those are my ideas :)
--Ted
On Sun, 2008-02-24 at 11:53 -0800, Ted Gould wrote:
On Sat, 2008-02-23 at 23:18 -0800, Bryce Harrington wrote:
But I think there is a compromise which will solve this, if we set two criteria for this year's involvement:
- All Inkscape GSoC projects this year must be implemented as extensions, with no changes required to Inkscape's core
Agreed.
- All mentoring be done by developers who will not be focusing on the 0.47 codebase refactoring efforts. (In particular, developers with good extension development experience.) We will limit the number of candidates we accept to the number of mentors available.
I think it should depend on the individual mentor. I think almost everyone should have some kind of hand in the refactoring, so by definition that would give us no mentors. Also, it would depend on the time that each mentor has to give.
Now, I think that this is a good time to discuss ideas for projects, and I'll dump my Tomboy note :)
* Extension to spell check whole document. Perhaps grammar check also. This extension should go through all of the text boxes, separate text and comments and allow the user to correct the problems. While we have the spell checking in the text dialog, it's a pain to go through as a "final proof" and ensure that all your text is sane. * Run diff tools on the XML document created by scripts so that only the diffs are merged into the tree. Currently the scripting interface basically sends an XML file, and takes the returned XML file at face values. What would be better is if the scripting interface detected the change in the document, and only applied those to the tree. There are some good algorithms for this from the folks that did Union. It would increase the speed of execution for the scripts and reduce the amount of data that they throw on the undo stack. * KML/SVG exchange scripts. I have mentors for these already committed. Seriously, good people. This is a high visibility project, probably get you friends at Google :)
Yeah, intro me to them, and I'll intro to my friends who are working on KML stuff :)
* Openstreetmaps Import. Currently OSM generates a set of XML data, transforms it via XSLT into SVG and then renders it in Inkscape. I'd like to see an import extension that allows you to specify the data you want, pulls it from OSM, and then imports it into Inkscape. This would be useful for people making a maps.
Totally useful!
Jon
Okay, those are my ideas :)
--Ted
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
* Run diff tools on the XML document created by scripts so that only the diffs are merged into the tree. Currently the scripting interface basically sends an XML file, and takes the returned XML file at face values. What would be better is if the scripting interface detected the change in the document, and only applied those to the tree. There are some good algorithms for this from the folks that did Union. It would increase the speed of execution for the scripts and reduce the amount of data that they throw on the undo stack.
I'd like to see extensions which have hooks instead of passing data in such large quantities around. First of all a DOM which modifies the inkscape document from the outside would be most useful to implement. firstly is the class of extension which should be an attribute:
1) File Save extension, an exporter, to take the entire document and output a string or binary data ready for a file. 2) File Load extension, an importer, to take a file and return svg ready for inkscapes reading. 3) A generator, to take variables and data and create a group containing svg as generated and return the xml element via DOM. 4) An object editor, to take a selection of objects and modify the objects in some way, talking directing with the inkscape DOM to replace them. 5) An attribute editor, to take a selection of any object and modify an attribute of those objects (such as align, colour or animaition) 6) UI extension, to add in some fashion to the GUI interface to add functionality and call perhaps other parts of the extension in the first 5 types.
Thoughts?
Best Regards, Martin Owens
On Mon, 2008-02-25 at 01:11 -0500, Martin Owens wrote:
Thoughts?
Patch? ;)
I think that it's always been our goal to provide a richer extensions interface for scripting languages. We've made progress on various fronts, but it's not done yet. I don't think that it's probably a reasonable amount of effort to expect a student to get done in a SoC project though.
--Ted
I think that it's always been our goal to provide a richer extensions interface for scripting languages. We've made progress on various fronts, but it's not done yet. I don't think that it's probably a reasonable amount of effort to expect a student to get done in a SoC project though.
Oh I totally agree, I'm suggesting documentation for the way we should head and think about exptentsions. what is the point of a feature if everone has alternate views on it's inception.
Patch? ;)
36 hour day please and a free course in C++.
* Openstreetmaps Import. Currently OSM generates a set of XML data, transforms it via XSLT into SVG and then renders it in Inkscape. I'd like to see an import extension that allows you to specify the data you want, pulls it from OSM, and then imports it into Inkscape. This would be useful for people making a maps.
It's true what they say: Great minds think alike! I was thinking of that idea just last week, and I was planning to put in a blueprint at some stage.
Joel
On Sun, 2008-02-24 at 11:53 -0800, Ted Gould wrote:
On Sat, 2008-02-23 at 23:18 -0800, Bryce Harrington wrote:
But I think there is a compromise which will solve this, if we set two criteria for this year's involvement:
- All Inkscape GSoC projects this year must be implemented as extensions, with no changes required to Inkscape's core
Agreed.
- All mentoring be done by developers who will not be focusing on the 0.47 codebase refactoring efforts. (In particular, developers with good extension development experience.) We will limit the number of candidates we accept to the number of mentors available.
I think it should depend on the individual mentor. I think almost everyone should have some kind of hand in the refactoring, so by definition that would give us no mentors. Also, it would depend on the time that each mentor has to give.
Now, I think that this is a good time to discuss ideas for projects, and I'll dump my Tomboy note :)
* Extension to spell check whole document. Perhaps grammar check also. This extension should go through all of the text boxes, separate text and comments and allow the user to correct the problems. While we have the spell checking in the text dialog, it's a pain to go through as a "final proof" and ensure that all your text is sane. * Run diff tools on the XML document created by scripts so that only the diffs are merged into the tree. Currently the scripting interface basically sends an XML file, and takes the returned XML file at face values. What would be better is if the scripting interface detected the change in the document, and only applied those to the tree. There are some good algorithms for this from the folks that did Union. It would increase the speed of execution for the scripts and reduce the amount of data that they throw on the undo stack. * KML/SVG exchange scripts. I have mentors for these already committed. Seriously, good people. This is a high visibility project, probably get you friends at Google :) * Openstreetmaps Import. Currently OSM generates a set of XML data, transforms it via XSLT into SVG and then renders it in Inkscape. I'd like to see an import extension that allows you to specify the data you want, pulls it from OSM, and then imports it into Inkscape. This would be useful for people making a maps.Okay, those are my ideas :)
--Ted
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (11)
-
unknown＠example.com -
Aaron Spike -
Bryce Harrington -
bulia byak -
Felipe Sanches -
Joel Holdsworth -
john cliff -
Jon Phillips -
Josh Andler -
Martin Owens -
Ted Gould