As mentioned previously in this thread, details of fundraising are typically discussed *after* a proper estimate is developed.
If this is a serious discussion (which I believe it is) then the following actions are up next:
1. Identify the programmers, testers, documenters and users who will participate. (Participants can assume multiple roles)
2. The programmers collaborate to create & share the requirements and constraints
3. The testers specify & share the testing and signoff requirements, based on output of #2
4. All participants specify documentation requirements to meet needs of both the users and the future developers/maintainers
5. Estimate the cost & delivery schedule
6. Design the fundraising campaign (which is another separate effort)
if you're going to raise funds from the public then you can't be code cowboys about this, no matter if you believe this is a relatively small effort.
Performing the above steps and publishing the results helps build momentum for public monetary support and creates tremendous public confidence.
it also gives the tech media something to report regularly building up to the fundraising start date. Use the machine wisely, publicity never hurts!
Assuming that remote collaboration results require more time than face-to-face sprints, we can shoot for 30 to 60 days for #1-5, 30 days maximum for #6, so max 90 days till fundraising.
My skills aren't in programming, but if you would like me to I can help with project development & fundraising. If there are others more connected to Inkscape than I who would like to step up for this work, please do!
- Susan
Hey Susan,
This is a great list.
I'd like to put myself forward for both design and programming. Publishing updates and making videos showing progress also available.
We should secure some space/resource for testers too.
All the best, Martin Owens
On Sat, 2013-11-30 at 13:39 -0600, Susan Spencer wrote:
As mentioned previously in this thread, details of fundraising are typically
discussed *after* a proper estimate is developed.
If this is a serious discussion (which I believe it is) then the following actions are up next:
- Identify the programmers, testers, documenters and users
who will participate. (Participants can assume multiple roles)
- The programmers collaborate to create & share the
requirements and constraints
- The testers specify & share the testing and signoff
requirements, based on output of #2
- All participants specify documentation requirements to meet
needs of both the users and the future developers/maintainers
Estimate the cost & delivery schedule
Design the fundraising campaign (which is another separate effort)
if you're going to raise funds from the public then you can't be code cowboys about this, no matter if you believe this is a relatively small effort.
Performing the above steps and publishing the results helps build momentum for public monetary support and creates tremendous public confidence.
it also gives the tech media something to report regularly building up to the fundraising start date. Use the machine wisely, publicity never hurts!
Assuming that remote collaboration results require more time than face-to-face sprints, we can shoot for 30 to 60 days for #1-5, 30 days maximum for #6,
so max 90 days till fundraising.
My skills aren't in programming, but if you would like me to I can help with project development & fundraising. If there are others more connected to Inkscape than I who would like to step up for this work, please do!
- Susan
The participant leads from this thread are: 1. Dick Bulterman http://homepages.cwi.nl/~dcab/addresses.html (head of Distributed and Interactive Systems at Centrum Wiskunde & Informatica (CWI)http://www.cwi.nl/, 2. Martin Owens (dev & fund raising 3. Rei Kagatsuki (dev & fund raising) 4. HadiM (fund raising)
Any other suggestions or volunteers?
On Sat, Nov 30, 2013 at 1:47 PM, Martin Owens <doctormo@...400...> wrote:
Hey Susan,
This is a great list.
I'd like to put myself forward for both design and programming. Publishing updates and making videos showing progress also available.
We should secure some space/resource for testers too.
All the best, Martin Owens
On Sat, 2013-11-30 at 13:39 -0600, Susan Spencer wrote:
As mentioned previously in this thread, details of fundraising are typically
discussed *after* a proper estimate is developed.
If this is a serious discussion (which I believe it is) then the following actions are up next:
- Identify the programmers, testers, documenters and users
who will participate. (Participants can assume multiple roles)
- The programmers collaborate to create & share the
requirements and constraints
- The testers specify & share the testing and signoff
requirements, based on output of #2
- All participants specify documentation requirements to meet
needs of both the users and the future developers/maintainers
Estimate the cost & delivery schedule
Design the fundraising campaign (which is another separate effort)
if you're going to raise funds from the public then you can't be code cowboys about this, no matter if you believe this is a relatively small effort.
Performing the above steps and publishing the results helps build momentum for public monetary support and creates tremendous public confidence.
it also gives the tech media something to report regularly building up to the fundraising start date. Use the machine wisely, publicity never hurts!
Assuming that remote collaboration results require more time than face-to-face sprints, we can shoot for 30 to 60 days for #1-5, 30 days maximum for #6,
so max 90 days till fundraising.
My skills aren't in programming, but if you would like me to I can help with project development & fundraising. If there are others more connected to Inkscape than I who would like to step up for this work, please do!
- Susan
I could help in testing, design and some develop.
El sáb, 30-11-2013 a las 14:22 -0600, Susan Spencer escribió:
The participant leads from this thread are:
- Dick Bulterman (head of Distributed and Interactive Systems at
Centrum Wiskunde & Informatica (CWI) , 2. Martin Owens (dev & fund raising
- Rei Kagatsuki (dev & fund raising)
- HadiM (fund raising)
Any other suggestions or volunteers?
On Sat, Nov 30, 2013 at 1:47 PM, Martin Owens <doctormo@...400...> wrote: Hey Susan,
This is a great list. I'd like to put myself forward for both design and programming. Publishing updates and making videos showing progress also available. We should secure some space/resource for testers too. All the best, Martin Owens On Sat, 2013-11-30 at 13:39 -0600, Susan Spencer wrote: > As mentioned previously in this thread, > details of fundraising are typically > > discussed *after* a proper estimate is > developed. > > > If this is a serious discussion (which I believe it is) > then the following actions are up next: > > > 1. Identify the programmers, testers, documenters and users > who will participate. (Participants can assume multiple roles) > > > 2. The programmers collaborate to create & share the > requirements and constraints > > > 3. The testers specify & share the testing and signoff > requirements, based on output of #2 > > > 4. All participants specify documentation requirements to meet > needs of both the users and the future developers/maintainers > > > 5. Estimate the cost & delivery schedule > > > 6. Design the fundraising campaign (which is another separate effort) > > > > > if you're going to raise funds from the public then > you can't be code cowboys about this, no matter > if you believe this is a relatively small effort. > > > Performing the above steps and publishing the results > helps build momentum for public monetary support > and creates tremendous public confidence. > > > it also gives the tech media something to report > regularly building up to the fundraising > start date. Use the machine wisely, publicity never hurts! > > > Assuming that remote collaboration results require > more time than face-to-face sprints, > we can shoot for 30 to 60 days for #1-5, > 30 days maximum for #6, > > so max 90 days till fundraising. > > > My skills aren't in programming, > but if you would like me to I can help with > project development & fundraising. > If there are others more connected to Inkscape than I > who would like to step up for this work, please do! > > > > > - Susan > > > > > > > > > >
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
So the most likely team to identify remaining work for connector & layout tools is:
Michael Wybrow Peter Moulder Krystof Kosinski Sebastian Goette
On Sat, Nov 30, 2013 at 6:44 PM, Jabiertxo Arraiza Cenoz < jabier.arraiza@...2893...> wrote:
I could help in testing, design and some develop.
El sáb, 30-11-2013 a las 14:22 -0600, Susan Spencer escribió:
The participant leads from this thread are:
- Dick Bulterman (head of Distributed and Interactive Systems at
Centrum Wiskunde & Informatica (CWI) , 2. Martin Owens (dev & fund raising
- Rei Kagatsuki (dev & fund raising)
- HadiM (fund raising)
Any other suggestions or volunteers?
On Sat, Nov 30, 2013 at 1:47 PM, Martin Owens <doctormo@...400...> wrote: Hey Susan,
This is a great list. I'd like to put myself forward for both design and programming. Publishing updates and making videos showing progress also available. We should secure some space/resource for testers too. All the best, Martin Owens On Sat, 2013-11-30 at 13:39 -0600, Susan Spencer wrote: > As mentioned previously in this thread, > details of fundraising are typically > > discussed *after* a proper estimate is > developed. > > > If this is a serious discussion (which I believe it is) > then the following actions are up next: > > > 1. Identify the programmers, testers, documenters and users > who will participate. (Participants can assume multiple roles) > > > 2. The programmers collaborate to create & share the > requirements and constraints > > > 3. The testers specify & share the testing and signoff > requirements, based on output of #2 > > > 4. All participants specify documentation requirements to meet > needs of both the users and the future developers/maintainers > > > 5. Estimate the cost & delivery schedule > > > 6. Design the fundraising campaign (which is another separate effort) > > > > > if you're going to raise funds from the public then > you can't be code cowboys about this, no matter > if you believe this is a relatively small effort. > > > Performing the above steps and publishing the results > helps build momentum for public monetary support > and creates tremendous public confidence. > > > it also gives the tech media something to report > regularly building up to the fundraising > start date. Use the machine wisely, publicity never hurts! > > > Assuming that remote collaboration results require > more time than face-to-face sprints, > we can shoot for 30 to 60 days for #1-5, > 30 days maximum for #6, > > so max 90 days till fundraising. > > > My skills aren't in programming, > but if you would like me to I can help with > project development & fundraising. > If there are others more connected to Inkscape than I > who would like to step up for this work, please do! > > > > > - Susan > > > > > > > > > >
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clk...
_______________________________________________ Inkscape-devel mailing
list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I have not been able to find email addressses for Michael Wybrow, Peter Moulder, Kryztov Kosinski, and Sebastian Goette
If anyone has this info can you please forward to me, or contact them yourself and have them contact me.
This would be greatly appreciated. Thanks!
On Sat, Nov 30, 2013 at 11:03 PM, Susan Spencer <susan.spencer@...400...>wrote:
So the most likely team to identify remaining work for connector & layout tools is:
Michael Wybrow Peter Moulder Krystof Kosinski Sebastian Goette
On Sat, Nov 30, 2013 at 6:44 PM, Jabiertxo Arraiza Cenoz < jabier.arraiza@...2893...> wrote:
I could help in testing, design and some develop.
El sáb, 30-11-2013 a las 14:22 -0600, Susan Spencer escribió:
The participant leads from this thread are:
- Dick Bulterman (head of Distributed and Interactive Systems at
Centrum Wiskunde & Informatica (CWI) , 2. Martin Owens (dev & fund raising
- Rei Kagatsuki (dev & fund raising)
- HadiM (fund raising)
Any other suggestions or volunteers?
On Sat, Nov 30, 2013 at 1:47 PM, Martin Owens <doctormo@...400...> wrote: Hey Susan,
This is a great list. I'd like to put myself forward for both design and programming. Publishing updates and making videos showing progress also available. We should secure some space/resource for testers too. All the best, Martin Owens On Sat, 2013-11-30 at 13:39 -0600, Susan Spencer wrote: > As mentioned previously in this thread, > details of fundraising are typically > > discussed *after* a proper estimate is > developed. > > > If this is a serious discussion (which I believe it is) > then the following actions are up next: > > > 1. Identify the programmers, testers, documenters and users > who will participate. (Participants can assume multiple roles) > > > 2. The programmers collaborate to create & share the > requirements and constraints > > > 3. The testers specify & share the testing and signoff > requirements, based on output of #2 > > > 4. All participants specify documentation requirements to meet > needs of both the users and the future developers/maintainers > > > 5. Estimate the cost & delivery schedule > > > 6. Design the fundraising campaign (which is another separate effort) > > > > > if you're going to raise funds from the public then > you can't be code cowboys about this, no matter > if you believe this is a relatively small effort. > > > Performing the above steps and publishing the results > helps build momentum for public monetary support > and creates tremendous public confidence. > > > it also gives the tech media something to report > regularly building up to the fundraising > start date. Use the machine wisely, publicity never hurts! > > > Assuming that remote collaboration results require > more time than face-to-face sprints, > we can shoot for 30 to 60 days for #1-5, > 30 days maximum for #6, > > so max 90 days till fundraising. > > > My skills aren't in programming, > but if you would like me to I can help with > project development & fundraising. > If there are others more connected to Inkscape than I > who would like to step up for this work, please do! > > > > > - Susan > > > > > > > > > >
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clk...
_______________________________________________ Inkscape-devel mailing
list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
The LGM hackfest is a possibility if we request it. They were just letting us know that it's an option.
On Sun, Dec 1, 2013 at 4:33 PM, Susan Spencer <susan.spencer@...400...>wrote:
I have not been able to find email addressses for Michael Wybrow, Peter Moulder, Kryztov Kosinski, and Sebastian Goette
If anyone has this info can you please forward to me, or contact them yourself and have them contact me.
This would be greatly appreciated. Thanks!
On Sat, Nov 30, 2013 at 11:03 PM, Susan Spencer <susan.spencer@...400...>wrote:
So the most likely team to identify remaining work for connector & layout tools is:
Michael Wybrow Peter Moulder Krystof Kosinski Sebastian Goette
On Sat, Nov 30, 2013 at 6:44 PM, Jabiertxo Arraiza Cenoz < jabier.arraiza@...2893...> wrote:
I could help in testing, design and some develop.
El sáb, 30-11-2013 a las 14:22 -0600, Susan Spencer escribió:
The participant leads from this thread are:
- Dick Bulterman (head of Distributed and Interactive Systems at
Centrum Wiskunde & Informatica (CWI) , 2. Martin Owens (dev & fund raising
- Rei Kagatsuki (dev & fund raising)
- HadiM (fund raising)
Any other suggestions or volunteers?
On Sat, Nov 30, 2013 at 1:47 PM, Martin Owens <doctormo@...400...> wrote: Hey Susan,
This is a great list. I'd like to put myself forward for both design and programming. Publishing updates and making videos showing progress also available. We should secure some space/resource for testers too. All the best, Martin Owens On Sat, 2013-11-30 at 13:39 -0600, Susan Spencer wrote: > As mentioned previously in this thread, > details of fundraising are typically > > discussed *after* a proper estimate is > developed. > > > If this is a serious discussion (which I believe it is) > then the following actions are up next: > > > 1. Identify the programmers, testers, documenters and users > who will participate. (Participants can assume multiple roles) > > > 2. The programmers collaborate to create & share the > requirements and constraints > > > 3. The testers specify & share the testing and signoff > requirements, based on output of #2 > > > 4. All participants specify documentation requirements to meet > needs of both the users and the future developers/maintainers > > > 5. Estimate the cost & delivery schedule > > > 6. Design the fundraising campaign (which is another separate effort) > > > > > if you're going to raise funds from the public then > you can't be code cowboys about this, no matter > if you believe this is a relatively small effort. > > > Performing the above steps and publishing the results > helps build momentum for public monetary support > and creates tremendous public confidence. > > > it also gives the tech media something to report > regularly building up to the fundraising > start date. Use the machine wisely, publicity never hurts! > > > Assuming that remote collaboration results require > more time than face-to-face sprints, > we can shoot for 30 to 60 days for #1-5, > 30 days maximum for #6, > > so max 90 days till fundraising. > > > My skills aren't in programming, > but if you would like me to I can help with > project development & fundraising. > If there are others more connected to Inkscape than I > who would like to step up for this work, please do! > > > > > - Susan > > > > > > > > > >
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clk...
_______________________________________________ Inkscape-devel mailing
list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, 2013-12-01 at 16:37 -0600, Susan Spencer wrote:
The LGM hackfest is a possibility if we request it. They were just letting us know that it's an option.
We're also going to need to sponsor people to go. If the interested developers are far away.
This is something I believe SFC will pay for if needed.
Martin,
On Sun, Dec 1, 2013 at 3:11 PM, Martin Owens <doctormo@...400...> wrote:
This is something I believe SFC will pay for if needed.
Which again is something that the board would need to vote on for SFC to release funds. For those wondering, this is the type of thing the board has typically been in favor of (funding to make a hackfest happen).
Cheers, Josh
On Sun, Dec 01, 2013 at 03:40:44PM -0800, Josh Andler wrote:
On Sun, Dec 1, 2013 at 3:11 PM, Martin Owens <doctormo@...400...> wrote:
This is something I believe SFC will pay for if needed.
Which again is something that the board would need to vote on for SFC to release funds. For those wondering, this is the type of thing the board has typically been in favor of (funding to make a hackfest happen).
Yes, that's correct.
Bryce
Yes, thanks Susan for expressing in a nice clear form what I was going to write in a waffly and hard to parse way. To stay in form I'm going to add some more waffle now:
The hardest part of writing software is the design, and typically that doesn't parallelise well. It really does take a signle person with a vision to make it work: much of the success of inkscape is down to the strong vision of bbyak around the UI. I think if we want to go ahead with SMIL (and I think that this is a great idea and one that mental and I have been kicking around for the better part of a decade :) we need to work out how the user interface is going to work. That means lots of neat, clear drawings of the interactions, precise specification of how specific example tasks are performed, and a careful reading of the SMIL spec to see how it would actually work. Adding animation is a lot harder than adding a timeline view and a few extra tool buttons.
Perhaps the first step is to understand how all the existing animation software works and where it falls down.
I think we would also need a fairly complete rewrite of the rendering pipeline to deal with animation and more complex canvas editting. (@tweenk?)
Are there any tasks which would get us closer to smil support but have direct pay off in themself? Generally big rewrite from scratch type projects fail, it is much better to work out where you want to go, and then take small, safe steps in that direction. One obvious step would be to work more on the connector and layout tools and make them better than (or at least match) omnigraffle. Last I looked the layout updating was very clunky and inefficient without any live updating. Fix this first and you'll be closer to animation and you'll have an immediate payoff.
I think the complaining about the board is ill-placed: they want inkscape to succeed as much as anyone here; but they also have been around a long time and have seen a lot of free software projects fail. I have no doubt that if we had a good design and project plan they would get behind it in a flash, but we're talking about multiple programmer years of work and they are being conservative with very good reason. njh
On Sat, Nov 30, 2013 at 02:47:21PM -0500, Martin Owens wrote:
Hey Susan,
This is a great list.
I'd like to put myself forward for both design and programming. Publishing updates and making videos showing progress also available.
We should secure some space/resource for testers too.
All the best, Martin Owens
On Sat, 2013-11-30 at 13:39 -0600, Susan Spencer wrote:
As mentioned previously in this thread, details of fundraising are typically
discussed *after* a proper estimate is developed.
If this is a serious discussion (which I believe it is) then the following actions are up next:
- Identify the programmers, testers, documenters and users
who will participate. (Participants can assume multiple roles)
- The programmers collaborate to create & share the
requirements and constraints
- The testers specify & share the testing and signoff
requirements, based on output of #2
- All participants specify documentation requirements to meet
needs of both the users and the future developers/maintainers
Estimate the cost & delivery schedule
Design the fundraising campaign (which is another separate effort)
if you're going to raise funds from the public then you can't be code cowboys about this, no matter if you believe this is a relatively small effort.
Performing the above steps and publishing the results helps build momentum for public monetary support and creates tremendous public confidence.
it also gives the tech media something to report regularly building up to the fundraising start date. Use the machine wisely, publicity never hurts!
Assuming that remote collaboration results require more time than face-to-face sprints, we can shoot for 30 to 60 days for #1-5, 30 days maximum for #6,
so max 90 days till fundraising.
My skills aren't in programming, but if you would like me to I can help with project development & fundraising. If there are others more connected to Inkscape than I who would like to step up for this work, please do!
- Susan
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, 2013-12-01 at 07:33 +1100, Nathan Hurst wrote:
they want inkscape to succeed as much as anyone here; but they also have been around a long time and have seen a lot of free software projects fail.
You're not wrong Nathan, but there is a caveat. Negative thinking sucks the energy out of the preparations for action. I have no doubt that every person here wants Inkscape to succeed, but leaders have to have a special kind of blindness that hides some of their opinion in exchange for giving hope to others.
I have no doubt that if we had a good design and project plan they would get behind it in a flash, but we're talking about multiple programmer years of work and they are being conservative with very good reason.
Ah design and project planning, truly the volunteer's volunteer ;-)
I don't mind if the project is SMIL, javascript, connectors or a better extensions system. Lots of things to do. What say you to a design off with me perhaps over IRC?
Martin,
Summarization of Nathan's suggestions:
1. Improve connector & layout tools (required_before_further_SMIL_development/biggest_result_for_least_effort) Question: Does this need to be done, independent of adding SMIL functionality?
2. Rewrite rendering pipeline Question: Does this need to be done, independent of adding SMIL functionality?
3. Determine if there is an appropriate existing timeline-based animation tool to incorporate code More details here: http://wiki.inkscape.org/wiki/index.php/Animation-(Timeline)#User_interface_...
4. Develop animation feature list (required_before_GUI design/requires_SMIL_spec_review) More details here: http://wiki.inkscape.org/wiki/index.php/Animation-(Timeline)#User_interface_...
5. Develop detailed, consistent GUI design More details here: http://wiki.inkscape.org/wiki/index.php/Animation-(Timeline)#User_interface_...
It may be best to break these out into separate projects, and seek some corporate funding (best submitted before Dec. 31) for #1 & #2.
On Sat, Nov 30, 2013 at 3:08 PM, Susan Spencer <susan.spencer@...400...>wrote:
Summarization of Nathan's suggestions:
- Improve connector & layout tools
(required_before_further_SMIL_development/biggest_result_for_least_effort) Question: Does this need to be done, independent of adding SMIL functionality?
- Rewrite rendering pipeline Question: Does this need to be done, independent of adding SMIL
functionality?
- Determine if there is an appropriate existing timeline-based animation
tool to incorporate code More details here: http://wiki.inkscape.org/wiki/index.php/Animation-(Timeline)#User_interface_...
- Develop animation feature list (required_before_GUI
design/requires_SMIL_spec_review) More details here: http://wiki.inkscape.org/wiki/index.php/Animation-(Timeline)#User_interface_...
- Develop detailed, consistent GUI design More details here:
http://wiki.inkscape.org/wiki/index.php/Animation-(Timeline)#User_interface_...
On Sat, 2013-11-30 at 15:42 -0600, Susan Spencer wrote:
It may be best to break these out into separate projects, and seek some corporate funding (best submitted before Dec. 31) for #1 & #2.
Who are the best people to ask for funding for connector work?
Likewise who would support improving inkscape's rendering pipeline?
There's a lot of ton companies that use Inkscape. From Google, RedHat and others. mo from RedHat was going to ask their budgeting department if they could spend the equivalent money they save from not buying Adobe on Free Software graphics projects. Maybe worth chasing up on that lead?
Martin,
Who has submitted requests for funding in the past? Can anyone provide examples in this area? Is there currently an official process?
I'd rather build on previous work than go charging in uninformed.
On Sat, Nov 30, 2013 at 4:00 PM, Martin Owens <doctormo@...400...> wrote:
On Sat, 2013-11-30 at 15:42 -0600, Susan Spencer wrote:
It may be best to break these out into separate projects, and seek some corporate funding (best submitted before Dec. 31) for #1 & #2.
Who are the best people to ask for funding for connector work?
Likewise who would support improving inkscape's rendering pipeline?
There's a lot of ton companies that use Inkscape. From Google, RedHat and others. mo from RedHat was going to ask their budgeting department if they could spend the equivalent money they save from not buying Adobe on Free Software graphics projects. Maybe worth chasing up on that lead?
Martin,
Who are the developers for connector tools? We can start discussion to develop an estimate and get that to the SFC.
I'm assuming that developing an estimate on rendering rewrite will take some time. Is this correct?
On Sat, Nov 30, 2013 at 4:10 PM, Susan Spencer <susan.spencer@...400...>wrote:
Who has submitted requests for funding in the past? Can anyone provide examples in this area? Is there currently an official process?
I'd rather build on previous work than go charging in uninformed.
On Sat, Nov 30, 2013 at 4:00 PM, Martin Owens <doctormo@...400...> wrote:
On Sat, 2013-11-30 at 15:42 -0600, Susan Spencer wrote:
It may be best to break these out into separate projects, and seek some corporate funding (best submitted before Dec. 31) for #1 & #2.
Who are the best people to ask for funding for connector work?
Likewise who would support improving inkscape's rendering pipeline?
There's a lot of ton companies that use Inkscape. From Google, RedHat and others. mo from RedHat was going to ask their budgeting department if they could spend the equivalent money they save from not buying Adobe on Free Software graphics projects. Maybe worth chasing up on that lead?
Martin,
On Sat, 2013-11-30 at 16:24 -0600, Susan Spencer wrote:
Who are the developers for connector tools? We can start discussion to develop an estimate and get that to the SFC.
Ah stats, I can help with that.
It looks like Markus Engel and Johan Engelen both did the most recent work and it was quite big. Followed by myself, Alex Valavanis and Jon Crus earlier this year. John Public did quite a few changes too.
I wrote a script to produce two outputs; first sorted by who last worked on the given code and second who had the biggest impact on the code by line (I've mapped the names for convenience):
./who-worked-on libavoid/connector.cpp libavoid/connector.h sp-conn-end-pair.cpp sp-conn-end.cpp widgets/connector-toolbar.h widgets/connector-toolbar.cpp connection-pool.h conn-avoid-ref.cpp pixmaps/cursor-connector.xpm sp-conn-end-pair.h conn-avoid-ref.h ui/tools/connector-tool.cpp ui/tools/connector-tool.h sp-conn-end.h
DATELAST NAME (LINE COUNT) 20131112 Markus Engel (255) 20131027 Johan Engelen (88) 20131013 Kris De Gussem (9) 20131009 Nicolas Dufour (1) 20130915 Matthew Petroff (8) 20130331 Martin Owens (80) 20130314 Alex Valavanis (31) 20130113 Jon Cruz (76) 20120508 John Public (478) 20110625 IdeasMan42 (7) 20110227 The Adib (5) 20101229 Arcadie Cracan (2700) 20101117 Chris Morgan (4) 20101026 Michael Wybrow (410) 20100816 Diederik van Lierop (34) 20100714 Abhishek Sharma (3) 20090806 Maximilian Albert (5) 20090630 Josh Andler (1) 20090622 Bulia Byak (35) 20081205 Joshua Blocher (7) 20081031 Ted Gould (22) 20080705 Peter Moulder (4) 20080131 Bryce Harington (11) 20070310 Mental Guy (1480) 20060825 Jonathan Phillips (4) 20060718 Tim Dwyer (1) 20060519 Mderezynski (74) 20060503 Carl Hetherington (1) 20060215 Ralf Stephan (32)
On Sat, Nov 30, 2013 at 04:24:00PM -0600, Susan Spencer wrote:
Who are the developers for connector tools?
Michael Wybrow and Peter Moulder are the best contacts (being the original author and his mentor).
We can start discussion to develop an estimate and get that to the SFC.
Yep, that's an excellent idea.
I'm assuming that developing an estimate on rendering rewrite will take some time. Is this correct?
It's possible that Krzysztof Kosinski or his summer of code student would have a fairly good idea of what is involved for this.
njh
On Sun, 2013-12-01 at 10:47 +1100, Nathan Hurst wrote:
On Sat, Nov 30, 2013 at 04:24:00PM -0600, Susan Spencer wrote:
Who are the developers for connector tools?
Michael Wybrow and Peter Moulder are the best contacts (being the original author and his mentor).
Sebastian Götte worked on refactoring the connector code to allow alternative routing back-ends for his 2013 GSoC project.[1] His interest mainly lies in using Inkscape for CAD purposes. The code has not yet been merged with trunk.
Some members of the SVG working group are very interested in connectors. I put together a proposal that was well received by the group.[2] Any connector work should keep this in mind.
Tav
[1] https://bazaar.launchpad.net/~h-e-6/inkscape/connector-wip/files [2] http://tavmjong.free.fr/SVG/CONNECTORS/index.xhtml
2013/12/1 Nathan Hurst <njh@...1927...>:
I'm assuming that developing an estimate on rendering rewrite will take some time. Is this correct?
It's possible that Krzysztof Kosinski or his summer of code student would have a fairly good idea of what is involved for this.
The current rendering pipeline is in fact fairly well suited to animation, because it goes out of its way to only compute / draw the things which are necessary. If we are sticking to Cairo, it only needs some optimization and minor additions.
A fairly big rewrite would be required if we wanted to support pluggable renderers. For instance, we could try adding alternative renderers based on Skia, Mozilla Azure, OpenVG or OpenGL (Cairo's OpenGL backend will not give us maximum performance, because the Cairo API does not correspond very well to how OpenGL works) or implementing some export formats in this way.
Note that I do not know enough OpenGL right now to implement an SVG renderer in it, or much OpenGL at all, though I could perhaps propose this as my Master's thesis in CS.
Regards, Krzysztof
On Tue, Dec 03, 2013 at 02:59:22PM +0100, Krzysztof Kosi??ski wrote:
The current rendering pipeline is in fact fairly well suited to animation, because it goes out of its way to only compute / draw the things which are necessary. If we are sticking to Cairo, it only needs some optimization and minor additions.
That's good to hear, you've done well :) So getting specific on canvas editing and animation would be a good intermediate goal.
A fairly big rewrite would be required if we wanted to support pluggable renderers. For instance, we could try adding alternative renderers based on Skia, Mozilla Azure, OpenVG or OpenGL (Cairo's OpenGL backend will not give us maximum performance, because the Cairo API does not correspond very well to how OpenGL works) or implementing some export formats in this way.
I would avoid skia, my experience is that opengl is much faster when used with care.
Note that I do not know enough OpenGL right now to implement an SVG renderer in it, or much OpenGL at all, though I could perhaps propose this as my Master's thesis in CS.
That sounds like a good project. If you are interested in this, ping me, I've done a little bit of work on vector renderers on opengl.
njh
On Wed, Dec 04, 2013 at 12:32:51PM +1100, Nathan Hurst wrote:
On Tue, Dec 03, 2013 at 02:59:22PM +0100, Krzysztof Kosi??ski wrote:
The current rendering pipeline is in fact fairly well suited to animation, because it goes out of its way to only compute / draw the things which are necessary. If we are sticking to Cairo, it only needs some optimization and minor additions.
That's good to hear, you've done well :) So getting specific on canvas editing and animation would be a good intermediate goal.
A fairly big rewrite would be required if we wanted to support pluggable renderers. For instance, we could try adding alternative renderers based on Skia, Mozilla Azure, OpenVG or OpenGL (Cairo's OpenGL backend will not give us maximum performance, because the Cairo API does not correspond very well to how OpenGL works) or implementing some export formats in this way.
I would avoid skia, my experience is that opengl is much faster when used with care.
Interesting, do you have more details about this, or papers? I'm presently working on comparisons of skia vs. cairo-gl performance for work, so any definitive studies done here showing one way or the other would be handy.
Note that I do not know enough OpenGL right now to implement an SVG renderer in it, or much OpenGL at all, though I could perhaps propose this as my Master's thesis in CS.
That sounds like a good project. If you are interested in this, ping me, I've done a little bit of work on vector renderers on opengl.
This is a topic that interests me as well, for work. If there's any links to papers or interesting examples to share, I'd appreciate.
Bryce
On Tue, 2013-12-03 at 18:04 -0800, Bryce Harrington wrote:
On Wed, Dec 04, 2013 at 12:32:51PM +1100, Nathan Hurst wrote:
On Tue, Dec 03, 2013 at 02:59:22PM +0100, Krzysztof Kosi??ski wrote:
The current rendering pipeline is in fact fairly well suited to animation, because it goes out of its way to only compute / draw the things which are necessary. If we are sticking to Cairo, it only needs some optimization and minor additions.
That's good to hear, you've done well :) So getting specific on canvas editing and animation would be a good intermediate goal.
A fairly big rewrite would be required if we wanted to support pluggable renderers. For instance, we could try adding alternative renderers based on Skia, Mozilla Azure, OpenVG or OpenGL (Cairo's OpenGL backend will not give us maximum performance, because the Cairo API does not correspond very well to how OpenGL works) or implementing some export formats in this way.
I would avoid skia, my experience is that opengl is much faster when used with care.
Interesting, do you have more details about this, or papers? I'm presently working on comparisons of skia vs. cairo-gl performance for work, so any definitive studies done here showing one way or the other would be handy.
Note that I do not know enough OpenGL right now to implement an SVG renderer in it, or much OpenGL at all, though I could perhaps propose this as my Master's thesis in CS.
That sounds like a good project. If you are interested in this, ping me, I've done a little bit of work on vector renderers on opengl.
This is a topic that interests me as well, for work. If there's any links to papers or interesting examples to share, I'd appreciate.
Nvidia has an OpenGL extension that supports SVG directly.[1] They were interested in getting this into the OpenGL standard. I don't know the current state of this but it might be interesting in the future. I was asked by an Nvidia rep if Inkscape was interested in this but I told him probably not if it was limited to just Nvidia GPUs. I also recommended that he talk to the Cairo folks.
Tav
[1] https://developer.nvidia.com/gpu-accelerated-path-rendering
2013/12/4 Tavmjong Bah <tavmjong@...8...>:
Nvidia has an OpenGL extension that supports SVG directly.[1] They were interested in getting this into the OpenGL standard. I don't know the current state of this but it might be interesting in the future. I was asked by an Nvidia rep if Inkscape was interested in this but I told him probably not if it was limited to just Nvidia GPUs. I also recommended that he talk to the Cairo folks.
Tav
[1] https://developer.nvidia.com/gpu-accelerated-path-rendering
I heard about this extension, and it would be a perfect fit, but it's a rather bad idea to rely on this it as long as it's Nvidia-only.
This page has some documentation on rendering fills composed of cubic and quadratic Bezier splines using OpenGL without flattening (the curve is evaluated using a fragment shader): http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html
Once we have a reliable stroke-to-path procedure in 2Geom, we can combine it with the above technique to make a pure OpenGL renderer.
Regards, Krzysztof
participants (8)
-
Bryce Harrington -
Jabiertxo Arraiza Cenoz -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
Nathan Hurst -
Susan Spencer -
Tavmjong Bah