Thanks Krzysztof, Martin, and Alex for providing feedback on the roadmap sketch I posted earlier.
I've fleshed out the following roadmap draft using this feedback, and extended it for another 5 releases. This assumes roughly 3 months per release.
http://wiki.inkscape.org/wiki/index.php/Roadmap
If anything, I think I've squeezed too much; I'd been hoping to have no more than maybe 3 major items per release. If you see items that could be put off or that would be too difficult to achieve in the near term, let me know so we can bump them down the list. Particularly for 0.92 and 0.93.
Even after squeezing all that stuff in, I've found quite a laundry list of feature requests left. If there are features that you think *must* go in pre-1.0, and you're planning on working on them yourself, please let me know and I'll shuffle things around to ensure it fits.
Beyond that... any and all feedback is welcomed! Come throw some darts!
Bryce
On Wed, 2015-04-08 at 14:07 -0700, Bryce Harrington wrote:
Thanks Krzysztof, Martin, and Alex for providing feedback on the roadmap sketch I posted earlier.
I've fleshed out the following roadmap draft using this feedback, and extended it for another 5 releases. This assumes roughly 3 months per release.
http://wiki.inkscape.org/wiki/index.php/Roadmap
If anything, I think I've squeezed too much; I'd been hoping to have no more than maybe 3 major items per release. If you see items that could be put off or that would be too difficult to achieve in the near term, let me know so we can bump them down the list. Particularly for 0.92 and 0.93.
Even after squeezing all that stuff in, I've found quite a laundry list of feature requests left. If there are features that you think *must* go in pre-1.0, and you're planning on working on them yourself, please let me know and I'll shuffle things around to ensure it fits.
Beyond that... any and all feedback is welcomed! Come throw some darts!
Bryce,
This looks amazing, thanks for working on getting this list in order. It's so easy to see what needs to be worked on first with this.
I'm happy with the priority and the content of these steps.
Martin,
Hi Bryce,
tl;dr: Let's split modularization work over a few releases so we don't create dependency nightmares for downstream users.
Thanks for this. I wonder whether it would make sense to bring some of the modularisation from 1.1 forward to 0.93 (e.g., libcroco should be fairly easy, as soon as the upstream GNOME devs finally accept our changes!) I'd be a bit concerned about having so much in one milestone. Conversely, we can't drop our fork of libgdl until we migrate to Gtk+ 3, so that will have to be pushed back to a later date. Finally, I believe that our forks of libavoid, libcola and libvpsc are in fact part of the upstream "adaptagrams" project [1], although last time I looked, there seemed to be a very large delta, and the library isn't packaged for many distros.
Furthermore, we should probably note that our "switch to regular dependency" tasks are non-trivial processes, since we need to establish a dependency pathway between our upstream library dependencies and downstream users... basically something like this: 1. Rebase our (ancient) forks of external libraries on the latest upstream release. 2. Forward all remaining changes to the libraries to upstream devs and request a new upstream release. 3. Sync our fork of the library with an appropriate upstream version and forbid any more in-trunk edits. 4. Update build tools to use upstream library by default (maintain fallback to embedded version). Maybe display a warning in the build log to inform the user that they should be using the upstream lib from now on. 5. Delete embedded library (update build tools accordingly)
As such, it might be prudent to cut a release of Inkscape after item 4, so that downstream distros have time to catch the new upstream library dependencies... some of them, like Adaptagrams, are pretty poorly represented in distros, so they'll need time to find a package maintainer etc. In other words, if we suddenly announce a vast number of new dependencies (some fairly obscure) at once, we'll effectively make Inkscape 1.1 unusable for many users.
Best wishes,
Alex
[1] http://www.adaptagrams.org/documentation/index.html
On 8 April 2015 at 22:18, Martin Owens <doctormo@...400...> wrote:
On Wed, 2015-04-08 at 14:07 -0700, Bryce Harrington wrote:
Thanks Krzysztof, Martin, and Alex for providing feedback on the roadmap sketch I posted earlier.
I've fleshed out the following roadmap draft using this feedback, and extended it for another 5 releases. This assumes roughly 3 months per release.
http://wiki.inkscape.org/wiki/index.php/Roadmap
If anything, I think I've squeezed too much; I'd been hoping to have no more than maybe 3 major items per release. If you see items that could be put off or that would be too difficult to achieve in the near term, let me know so we can bump them down the list. Particularly for 0.92 and 0.93.
Even after squeezing all that stuff in, I've found quite a laundry list of feature requests left. If there are features that you think *must* go in pre-1.0, and you're planning on working on them yourself, please let me know and I'll shuffle things around to ensure it fits.
Beyond that... any and all feedback is welcomed! Come throw some darts!
Bryce,
This looks amazing, thanks for working on getting this list in order. It's so easy to see what needs to be worked on first with this.
I'm happy with the priority and the content of these steps.
Martin,
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, Apr 09, 2015 at 04:39:11PM +0100, Alex Valavanis wrote:
Hi Bryce,
tl;dr: Let's split modularization work over a few releases so we don't create dependency nightmares for downstream users.
Thanks for this. I wonder whether it would make sense to bring some of the modularisation from 1.1 forward to 0.93 (e.g., libcroco should be fairly easy, as soon as the upstream GNOME devs finally accept our changes!) I'd be a bit concerned about having so much in one milestone.
Very good points. I like your scheme for reorganizing the work, I'll update the roadmap to follow it.
Conversely, we can't drop our fork of libgdl until we migrate to Gtk+ 3, so that will have to be pushed back to a later date.
Good to know. We probably should plan how we're going to do the Gtk+3 transition before that, as I expect it may take more than one release. Probably a post-1.0 project.
Finally, I believe that our forks of libavoid, libcola and
libvpsc are in fact part of the upstream "adaptagrams" project [1], although last time I looked, there seemed to be a very large delta, and the library isn't packaged for many distros.
Ah, this is from Monash folks, I recognize the names. They were quite active in Inkscape some time back.
The latter is straightforward, just a packaging issue. As to the former, is the delta in the form of patches we've accumulated on top of their work, that hasn't gotten upstream yet? Or has it been sent upstream but the patches weren't landed?
If the upstream trees haven't been maintained and updated, then we may neet to consider having Inkscape take responsibility for their maintenance, either by formally adopting them (if we can contact the original developers and they're cool with that) or else worst case maybe fork them.
Anyway, probably a year or two before we need to get that sorted out.
Furthermore, we should probably note that our "switch to regular dependency" tasks are non-trivial processes, since we need to establish a dependency pathway between our upstream library dependencies and downstream users... basically something like this:
- Rebase our (ancient) forks of external libraries on the latest
upstream release. 2. Forward all remaining changes to the libraries to upstream devs and request a new upstream release. 3. Sync our fork of the library with an appropriate upstream version and forbid any more in-trunk edits. 4. Update build tools to use upstream library by default (maintain fallback to embedded version). Maybe display a warning in the build log to inform the user that they should be using the upstream lib from now on. 5. Delete embedded library (update build tools accordingly)
As such, it might be prudent to cut a release of Inkscape after item 4, so that downstream distros have time to catch the new upstream library dependencies... some of them, like Adaptagrams, are pretty poorly represented in distros, so they'll need time to find a package maintainer etc. In other words, if we suddenly announce a vast number of new dependencies (some fairly obscure) at once, we'll effectively make Inkscape 1.1 unusable for many users.
Sure, this seems like a good migration strategy. I'm not _super_ worried about distros; these types of libraries tend not to be terribly complex to package. Even if we did several in one go, they can often cookie cutter the packaging for the set and do it pretty efficiently.
Bryce
Best wishes,
Alex
[1] http://www.adaptagrams.org/documentation/index.html
On 8 April 2015 at 22:18, Martin Owens <doctormo@...400...> wrote:
On Wed, 2015-04-08 at 14:07 -0700, Bryce Harrington wrote:
Thanks Krzysztof, Martin, and Alex for providing feedback on the roadmap sketch I posted earlier.
I've fleshed out the following roadmap draft using this feedback, and extended it for another 5 releases. This assumes roughly 3 months per release.
http://wiki.inkscape.org/wiki/index.php/Roadmap
If anything, I think I've squeezed too much; I'd been hoping to have no more than maybe 3 major items per release. If you see items that could be put off or that would be too difficult to achieve in the near term, let me know so we can bump them down the list. Particularly for 0.92 and 0.93.
Even after squeezing all that stuff in, I've found quite a laundry list of feature requests left. If there are features that you think *must* go in pre-1.0, and you're planning on working on them yourself, please let me know and I'll shuffle things around to ensure it fits.
Beyond that... any and all feedback is welcomed! Come throw some darts!
Bryce,
This looks amazing, thanks for working on getting this list in order. It's so easy to see what needs to be worked on first with this.
I'm happy with the priority and the content of these steps.
Martin,
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
The Adaptagrams changes are mostly things from upstream that we haven't adopted yet, although there have been a few bug fixes in trunk. Actually, I think the rebasing should be fairly easy.
I think the main problem is that the project doesn't appear to have cut a release yet, so there's no easy way to test for versions if we use it as an external library. Perhaps it works be prudent to encourage them to start making release tarballs before we start rebasing.
AV On 10 Apr 2015 05:17, "Bryce Harrington" <bryce@...961...> wrote:
On Thu, Apr 09, 2015 at 04:39:11PM +0100, Alex Valavanis wrote:
Hi Bryce,
tl;dr: Let's split modularization work over a few releases so we don't create dependency nightmares for downstream users.
Thanks for this. I wonder whether it would make sense to bring some of the modularisation from 1.1 forward to 0.93 (e.g., libcroco should be fairly easy, as soon as the upstream GNOME devs finally accept our changes!) I'd be a bit concerned about having so much in one milestone.
Very good points. I like your scheme for reorganizing the work, I'll update the roadmap to follow it.
Conversely, we can't drop our fork of libgdl until we migrate to Gtk+ 3, so that will have to be pushed back to a later date.
Good to know. We probably should plan how we're going to do the Gtk+3 transition before that, as I expect it may take more than one release. Probably a post-1.0 project.
Finally, I believe that our forks of libavoid, libcola and
libvpsc are in fact part of the upstream "adaptagrams" project [1], although last time I looked, there seemed to be a very large delta, and the library isn't packaged for many distros.
Ah, this is from Monash folks, I recognize the names. They were quite active in Inkscape some time back.
The latter is straightforward, just a packaging issue. As to the former, is the delta in the form of patches we've accumulated on top of their work, that hasn't gotten upstream yet? Or has it been sent upstream but the patches weren't landed?
If the upstream trees haven't been maintained and updated, then we may neet to consider having Inkscape take responsibility for their maintenance, either by formally adopting them (if we can contact the original developers and they're cool with that) or else worst case maybe fork them.
Anyway, probably a year or two before we need to get that sorted out.
Furthermore, we should probably note that our "switch to regular dependency" tasks are non-trivial processes, since we need to establish a dependency pathway between our upstream library dependencies and downstream users... basically something like this:
- Rebase our (ancient) forks of external libraries on the latest
upstream release. 2. Forward all remaining changes to the libraries to upstream devs and request a new upstream release. 3. Sync our fork of the library with an appropriate upstream version and forbid any more in-trunk edits. 4. Update build tools to use upstream library by default (maintain fallback to embedded version). Maybe display a warning in the build log to inform the user that they should be using the upstream lib from now on. 5. Delete embedded library (update build tools accordingly)
As such, it might be prudent to cut a release of Inkscape after item 4, so that downstream distros have time to catch the new upstream library dependencies... some of them, like Adaptagrams, are pretty poorly represented in distros, so they'll need time to find a package maintainer etc. In other words, if we suddenly announce a vast number of new dependencies (some fairly obscure) at once, we'll effectively make Inkscape 1.1 unusable for many users.
Sure, this seems like a good migration strategy. I'm not _super_ worried about distros; these types of libraries tend not to be terribly complex to package. Even if we did several in one go, they can often cookie cutter the packaging for the set and do it pretty efficiently.
Bryce
Best wishes,
Alex
[1] http://www.adaptagrams.org/documentation/index.html
On 8 April 2015 at 22:18, Martin Owens <doctormo@...400...> wrote:
On Wed, 2015-04-08 at 14:07 -0700, Bryce Harrington wrote:
Thanks Krzysztof, Martin, and Alex for providing feedback on the
roadmap
sketch I posted earlier.
I've fleshed out the following roadmap draft using this feedback, and extended it for another 5 releases. This assumes roughly 3 months per release.
http://wiki.inkscape.org/wiki/index.php/Roadmap
If anything, I think I've squeezed too much; I'd been hoping to have no more than maybe 3 major items per release. If you see items that could be put off or that would be too difficult to achieve in the near term, let me know so we can bump them down the list. Particularly for 0.92 and 0.93.
Even after squeezing all that stuff in, I've found quite a laundry
list
of feature requests left. If there are features that you think *must* go in pre-1.0, and you're planning on working on them yourself, please let me know and I'll shuffle things around to ensure it fits.
Beyond that... any and all feedback is welcomed! Come throw some
darts!
Bryce,
This looks amazing, thanks for working on getting this list in order. It's so easy to see what needs to be worked on first with this.
I'm happy with the priority and the content of these steps.
Martin,
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live
exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2015-04-10 13:55 GMT+02:00 Mark Schafer <mschafer@...2596...>:
I'd just like to make one request. The Extension system (and Python and Dbus) capability is slated for 1.4. I firmly believe that a lot of people (myself included) could meaningfully contribute to Inkscape in the form of extensions which do not require a deep C knowledge of the Inkscape internals.
I'd like to request moving this up the timescale if at all possible. Cheers...
The old "filter-like" extension system is already there and it won't go away.
I think DBus based extensions may not be the best idea at this time, since they require some measure of API stability, and our current API is really deficient in a few places. That should be the main priority.
Another problem is that it wouldn't be possible to implement things such as new tools as DBus extensions. Every exchange of data would be a DBus call, and for an interactive tool the overhead would be too large.
Regards, Krzysztof
On Fri, Apr 10, 2015 at 11:55:38PM +1200, Mark Schafer wrote:
I'd just like to make one request. The Extension system (and Python and Dbus) capability is slated for 1.4. I firmly believe that a lot of people (myself included) could meaningfully contribute to Inkscape in the form of extensions which do not require a deep C knowledge of the Inkscape internals.
I'd like to request moving this up the timescale if at all possible. Cheers...
Yeah, it's long overdue. However, it's one of those things that requires careful design work to get right. It'd be easy enough to slap something in, but then we'd either need to live with with something clunky and ill-designed, or we'd be churning in new extension systems every coupe releases and need to reimplement extensions over and over.
Like Krzysztof mentioned, there's a whole series of technical decisions that need to be made, before we can firm up the design, which is why I set it for post-1.0. If someone felt ambitious and made a lot of progress at getting a really solid proposal for a new system drafted up, I think we could certainly consider moving the goal up sooner, but otherwise I don't think it's something we want to rush.
Bryce
On 4/10/2015 8:47 PM, Alex Valavanis wrote:
The Adaptagrams changes are mostly things from upstream that we haven't adopted yet, although there have been a few bug fixes in trunk. Actually, I think the rebasing should be fairly easy. I think the main problem is that the project doesn't appear to have cut a release yet, so there's no easy way to test for versions if we use it as an external library. Perhaps it works be prudent to encourage them to start making release tarballs before we start rebasing. AV On 10 Apr 2015 05:17, "Bryce Harrington" <bryce@...961...> wrote: On Thu, Apr 09, 2015 at 04:39:11PM +0100, Alex Valavanis wrote: > Hi Bryce, > > tl;dr: Let's split modularization work over a few releases so we don't > create dependency nightmares for downstream users. > > Thanks for this. I wonder whether it would make sense to bring some > of the modularisation from 1.1 forward to 0.93 (e.g., libcroco should > be fairly easy, as soon as the upstream GNOME devs finally accept our > changes!) I'd be a bit concerned about having so much in one > milestone. Very good points. I like your scheme for reorganizing the work, I'll update the roadmap to follow it. > Conversely, we can't drop our fork of libgdl until we > migrate to Gtk+ 3, so that will have to be pushed back to a later > date. Good to know. We probably should plan how we're going to do the Gtk+3 transition before that, as I expect it may take more than one release. Probably a post-1.0 project. Finally, I believe that our forks of libavoid, libcola and > libvpsc are in fact part of the upstream "adaptagrams" project [1], > although last time I looked, there seemed to be a very large delta, > and the library isn't packaged for many distros. Ah, this is from Monash folks, I recognize the names. They were quite active in Inkscape some time back. The latter is straightforward, just a packaging issue. As to the former, is the delta in the form of patches we've accumulated on top of their work, that hasn't gotten upstream yet? Or has it been sent upstream but the patches weren't landed? If the upstream trees haven't been maintained and updated, then we may neet to consider having Inkscape take responsibility for their maintenance, either by formally adopting them (if we can contact the original developers and they're cool with that) or else worst case maybe fork them. Anyway, probably a year or two before we need to get that sorted out. > Furthermore, we should probably note that our "switch to regular > dependency" tasks are non-trivial processes, since we need to > establish a dependency pathway between our upstream library > dependencies and downstream users... basically something like this: > 1. Rebase our (ancient) forks of external libraries on the latest > upstream release. > 2. Forward all remaining changes to the libraries to upstream devs and > request a new upstream release. > 3. Sync our fork of the library with an appropriate upstream version > and forbid any more in-trunk edits. > 4. Update build tools to use upstream library by default (maintain > fallback to embedded version). Maybe display a warning in the build > log to inform the user that they should be using the upstream lib from > now on. > 5. Delete embedded library (update build tools accordingly) > > As such, it might be prudent to cut a release of Inkscape after item > 4, so that downstream distros have time to catch the new upstream > library dependencies... some of them, like Adaptagrams, are pretty > poorly represented in distros, so they'll need time to find a package > maintainer etc. In other words, if we suddenly announce a vast number > of new dependencies (some fairly obscure) at once, we'll effectively > make Inkscape 1.1 unusable for many users. Sure, this seems like a good migration strategy. I'm not _super_ worried about distros; these types of libraries tend not to be terribly complex to package. Even if we did several in one go, they can often cookie cutter the packaging for the set and do it pretty efficiently. Bryce > Best wishes, > > > Alex > > [1] http://www.adaptagrams.org/documentation/index.html > > On 8 April 2015 at 22:18, Martin Owens <doctormo@...400...> wrote: > > On Wed, 2015-04-08 at 14:07 -0700, Bryce Harrington wrote: > >> Thanks Krzysztof, Martin, and Alex for providing feedback on the roadmap > >> sketch I posted earlier. > >> > >> I've fleshed out the following roadmap draft using this feedback, and > >> extended it for another 5 releases. This assumes roughly 3 months per > >> release. > >> > >> http://wiki.inkscape.org/wiki/index.php/Roadmap > >> > >> If anything, I think I've squeezed too much; I'd been hoping to have > >> no more than maybe 3 major items per release. If you see items that > >> could be put off or that would be too difficult to achieve in the near > >> term, let me know so we can bump them down the list. Particularly for > >> 0.92 and 0.93. > >> > >> Even after squeezing all that stuff in, I've found quite a laundry list > >> of feature requests left. If there are features that you think *must* > >> go in pre-1.0, and you're planning on working on them yourself, please > >> let me know and I'll shuffle things around to ensure it fits. > >> > >> Beyond that... any and all feedback is welcomed! Come throw some darts! > > > > Bryce, > > > > This looks amazing, thanks for working on getting this list in order. > > It's so easy to see what needs to be worked on first with this. > > > > I'm happy with the priority and the content of these steps. > > > > Martin, > > > > > > ------------------------------------------------------------------------------ > > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > > Develop your own process in accordance with the BPMN 2 standard > > Learn Process modeling best practices with Bonita BPM through live exercises > > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign= VA_SF > > _______________________________________________ > > Inkscape-devel mailing list > > Inkscape-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5863 / Virus Database: 4328/9499 - Release Date: 04/09/15
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, Apr 10, 2015 at 09:47:06AM +0100, Alex Valavanis wrote:
The Adaptagrams changes are mostly things from upstream that we haven't adopted yet, although there have been a few bug fixes in trunk. Actually, I think the rebasing should be fairly easy.
I think the main problem is that the project doesn't appear to have cut a release yet, so there's no easy way to test for versions if we use it as an external library. Perhaps it works be prudent to encourage them to start making release tarballs before we start rebasing.
Yes, even if it's just a 0.1, good point.
Bryce
AV On 10 Apr 2015 05:17, "Bryce Harrington" <bryce@...961...> wrote:
On Thu, Apr 09, 2015 at 04:39:11PM +0100, Alex Valavanis wrote:
Hi Bryce,
tl;dr: Let's split modularization work over a few releases so we don't create dependency nightmares for downstream users.
Thanks for this. I wonder whether it would make sense to bring some of the modularisation from 1.1 forward to 0.93 (e.g., libcroco should be fairly easy, as soon as the upstream GNOME devs finally accept our changes!) I'd be a bit concerned about having so much in one milestone.
Very good points. I like your scheme for reorganizing the work, I'll update the roadmap to follow it.
Conversely, we can't drop our fork of libgdl until we migrate to Gtk+ 3, so that will have to be pushed back to a later date.
Good to know. We probably should plan how we're going to do the Gtk+3 transition before that, as I expect it may take more than one release. Probably a post-1.0 project.
Finally, I believe that our forks of libavoid, libcola and
libvpsc are in fact part of the upstream "adaptagrams" project [1], although last time I looked, there seemed to be a very large delta, and the library isn't packaged for many distros.
Ah, this is from Monash folks, I recognize the names. They were quite active in Inkscape some time back.
The latter is straightforward, just a packaging issue. As to the former, is the delta in the form of patches we've accumulated on top of their work, that hasn't gotten upstream yet? Or has it been sent upstream but the patches weren't landed?
If the upstream trees haven't been maintained and updated, then we may neet to consider having Inkscape take responsibility for their maintenance, either by formally adopting them (if we can contact the original developers and they're cool with that) or else worst case maybe fork them.
Anyway, probably a year or two before we need to get that sorted out.
Furthermore, we should probably note that our "switch to regular dependency" tasks are non-trivial processes, since we need to establish a dependency pathway between our upstream library dependencies and downstream users... basically something like this:
- Rebase our (ancient) forks of external libraries on the latest
upstream release. 2. Forward all remaining changes to the libraries to upstream devs and request a new upstream release. 3. Sync our fork of the library with an appropriate upstream version and forbid any more in-trunk edits. 4. Update build tools to use upstream library by default (maintain fallback to embedded version). Maybe display a warning in the build log to inform the user that they should be using the upstream lib from now on. 5. Delete embedded library (update build tools accordingly)
As such, it might be prudent to cut a release of Inkscape after item 4, so that downstream distros have time to catch the new upstream library dependencies... some of them, like Adaptagrams, are pretty poorly represented in distros, so they'll need time to find a package maintainer etc. In other words, if we suddenly announce a vast number of new dependencies (some fairly obscure) at once, we'll effectively make Inkscape 1.1 unusable for many users.
Sure, this seems like a good migration strategy. I'm not _super_ worried about distros; these types of libraries tend not to be terribly complex to package. Even if we did several in one go, they can often cookie cutter the packaging for the set and do it pretty efficiently.
Bryce
Best wishes,
Alex
[1] http://www.adaptagrams.org/documentation/index.html
On 8 April 2015 at 22:18, Martin Owens <doctormo@...400...> wrote:
On Wed, 2015-04-08 at 14:07 -0700, Bryce Harrington wrote:
Thanks Krzysztof, Martin, and Alex for providing feedback on the
roadmap
sketch I posted earlier.
I've fleshed out the following roadmap draft using this feedback, and extended it for another 5 releases. This assumes roughly 3 months per release.
http://wiki.inkscape.org/wiki/index.php/Roadmap
If anything, I think I've squeezed too much; I'd been hoping to have no more than maybe 3 major items per release. If you see items that could be put off or that would be too difficult to achieve in the near term, let me know so we can bump them down the list. Particularly for 0.92 and 0.93.
Even after squeezing all that stuff in, I've found quite a laundry
list
of feature requests left. If there are features that you think *must* go in pre-1.0, and you're planning on working on them yourself, please let me know and I'll shuffle things around to ensure it fits.
Beyond that... any and all feedback is welcomed! Come throw some
darts!
Bryce,
This looks amazing, thanks for working on getting this list in order. It's so easy to see what needs to be worked on first with this.
I'm happy with the priority and the content of these steps.
Martin,
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live
exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2015-04-08 23:07 GMT+02:00 Bryce Harrington <bryce@...961...>:
Beyond that... any and all feedback is welcomed! Come throw some darts!
1. I think GTK 3 migration should be a little sooner. Reportedly GTK 3 has much better support for Windows and OS X. I also really want to get rid of all these ifdefs.
2. DBus extensions - The more I think about this, the more I am convinced this idea is like the laser-shooting plane: attractive but impractical.
2a) Exposing API via DBus is more difficult than just making a binding, so according to the "worse is better" principle of Unix engineering, we can get more done in shorter time by simply creating a normal scripting language binding.
2b) While being able to use any language to create an Inkscape extension is an attractive feature, it is a nightmare waiting to happen from a maintainability point of view. It's a lot better to choose one language and stick to it, so that you don't need to know an arbitrary number of languages to debug an extension - only one. Python seems to be the natural choice, as the vast majority of existing extensions is in Python.
2c) The API of the existing DBus binding is really poor. For example, you have to hijack the global UI selection to do anything. This is a result of our internal API being just as poor - many functions operate on a selection, and that object is essentially a singleton. We need to able to create objects that represents the same structure as the selection and specify to what elements in the document an action should apply, but is not tied to UI in any way. (I wrote about this some time ago.)
3. Inkscape for Android - I have no idea how that is going to work. That would essentially be a completely different program. It could use some of our code if we up our game with regards to modularization, but that's all.
4. 2Geom as a separate library - I am not sure about that. At some point - yes, but not in the immediate future. Some parts of 2Geom API are now in reasonably good shape - for instance Rect, Path, the Curve hierarchy. However, others are really poor. For instance, the whole "Crossing" mess and old intersection APIs are very poorly designed; some shapes are missing the most obvious functions. Many of the toys don't actually showcase 2Geom's API, but contain a lot of nontrivial code, which is not present in the library itself.
5. Renaming SPThings - I agree, and would also add that we should reduce the proliferation of namespaces. Either put everything in Inkscape, or make at most a few second-level namespaces e.g. UI, XML, SVG (for things which now start with SP). Separate Widget and Dialog namespaces must die.
6. We should think about linear RGB rendering, possibly in floating-point linear scRGB colorspace. Cairo is not currently capable of this, unfortunately, but these sorts of operations are blazingly fast on GPUs. This would improve our rendering quality a lot and allow us to actually render filters correctly.
Regards, Krzysztof
On Fri, Apr 10, 2015 at 6:01 PM, Krzysztof Kosiński <tweenk.pl@...972.....> wrote:
2015-04-08 23:07 GMT+02:00 Bryce Harrington <bryce@...961...>:
Beyond that... any and all feedback is welcomed! Come throw some darts!
- I think GTK 3 migration should be a little sooner. Reportedly GTK 3
has much better support for Windows and OS X. I also really want to get rid of all these ifdefs.
I agree about it being done sooner. I think one of the biggest blockers we currently have is canvas flickering on scrolling and zooming. If this were to be looked into during the hackfest, I think it would make Liam a happy individual.
Cheers, Josh
On Fri, Apr 10, 2015 at 06:37:11PM -0700, Josh Andler wrote:
On Fri, Apr 10, 2015 at 6:01 PM, Krzysztof Kosiński <tweenk.pl@...847...0...> wrote:
2015-04-08 23:07 GMT+02:00 Bryce Harrington <bryce@...961...>:
Beyond that... any and all feedback is welcomed! Come throw some darts!
- I think GTK 3 migration should be a little sooner. Reportedly GTK 3
has much better support for Windows and OS X. I also really want to get rid of all these ifdefs.
From what I've seen, there's still a lot of unknowns and random bugs; I
worry if we list it as a near term objective and find ourselves mired in bugs and problems then we might be forced to either delay releases a long time or compromise the UI to work around problems.
I'm thinking it may be better to list it as an objective for a distant milestone, and then if someone miraculously gets it working and irons out all the issues so there's no regressions, then we could certainly look at landing it early.
I agree about it being done sooner. I think one of the biggest blockers we currently have is canvas flickering on scrolling and zooming. If this were to be looked into during the hackfest, I think it would make Liam a happy individual.
I know we did look at this the first day of the hackfest. Could someone report on what was found?
Bryce
Alex made some progress on the flickering, but it requires more work - there is a lot of ungodly mess to untangle in SPCanvas. Our working hypothesis is that this happens because we draw to the canvas widget outside of the draw signal. I'll try to find the e-mail from Paul Davis on the GTK list that had some useful tips on dealing with this problem. On 29 Apr 2015 08:30, "Bryce Harrington" <bryce@...961...> wrote:
On Fri, Apr 10, 2015 at 06:37:11PM -0700, Josh Andler wrote:
On Fri, Apr 10, 2015 at 6:01 PM, Krzysztof Kosiński <tweenk.pl@...360...400...>
wrote:
2015-04-08 23:07 GMT+02:00 Bryce Harrington <bryce@...961...
:
Beyond that... any and all feedback is welcomed! Come throw some
darts!
- I think GTK 3 migration should be a little sooner. Reportedly GTK 3
has much better support for Windows and OS X. I also really want to get rid of all these ifdefs.
From what I've seen, there's still a lot of unknowns and random bugs; I worry if we list it as a near term objective and find ourselves mired in bugs and problems then we might be forced to either delay releases a long time or compromise the UI to work around problems.
I'm thinking it may be better to list it as an objective for a distant milestone, and then if someone miraculously gets it working and irons out all the issues so there's no regressions, then we could certainly look at landing it early.
I agree about it being done sooner. I think one of the biggest blockers we currently have is canvas flickering on scrolling and zooming. If this were to be looked into during the hackfest, I think it would make Liam a happy individual.
I know we did look at this the first day of the hackfest. Could someone report on what was found?
Bryce
In favour of DBus API:
2a) Exposing API via DBus is more difficult than just making a binding.
Is it? Only if one were experienced with one and not the other.
We have a scripting language binding. It's not great. It requires invoking from inkscape, a complete build of said language for mac and windows distributions and is very very poky. It's amazing we get so much out of it.
A better reason would be the lack of current DBus support in Windows. Although that could be solved in later Gtk releases/builds.
2b) It is a nightmare waiting to happen from a maintainability point of view.
Nonsense. What we support and ship has nothing to do with what other people ship. We can even tilt the scales by providing good documentation and examples for python. Overall this isn't a reason not to do DBus.
2c) The API of the existing DBus binding is really poor.
So is the python scripting 'binding'. That's not a reason to not do a job well.
2d) Every exchange of data would be a DBus call, and for an interactive tool the overhead would be too large.
Speed wise, it shouldn't be a problem. It's only really an issue when you start tying together mouse move events (which should just not happen) or rendering steps (which shouldn't happen). So long as all the comparability parts are in there and we support SVG and our API isn't poor quality, speed shouldn't be too much of an issue. Even inkboard could be remade using DBus if we did the API right.
If you think up something that wouldn't work, let me know here and I'll design a solution which the API would have in it's platonic form.
Martin,
2015-04-11 4:00 GMT+02:00 Martin Owens <doctormo@...400...>:
2a) Exposing API via DBus is more difficult than just making a binding.
Is it? Only if one were experienced with one and not the other.
We have a scripting language binding. It's not great. It requires invoking from inkscape, a complete build of said language for mac and windows distributions and is very very poky. It's amazing we get so much out of it.
What we have is not a binding at all, it's just a means to pipe the raw XML from Inkscape to an arbitrary filter program, with Glade-like .inx files that let you specify the UI for additional parameters, and receive back modified output. The scripts do not invoke any functions within Inkscape, they are entirely self-contained.
For such a model, allowing arbitrary implementation languages is OK, since to Inkscape the script is just a black box with one input, one output and some extra command line parameters.
A better reason would be the lack of current DBus support in Windows. Although that could be solved in later Gtk releases/builds.
DBus is not part of GTK
2c) The API of the existing DBus binding is really poor.
So is the python scripting 'binding'. That's not a reason to not do a job well.
For the existing Python extensions there is no API at all. The only point of interface between Inkscape and script extensions are the .inx files that specify how the UI for extra parameters should look, and these are reasonably well designed.
Regards, Krzysztof
Krzysztof Kosiński <tweenk.pl@...400...> writes:
2015-04-08 23:07 GMT+02:00 Bryce Harrington <bryce@...961...>:
Beyond that... any and all feedback is welcomed! Come throw some darts!
- I think GTK 3 migration should be a little sooner. Reportedly GTK 3
has much better support for Windows and OS X. I also really want to get rid of all these ifdefs.
- DBus extensions - The more I think about this, the more I am
convinced this idea is like the laser-shooting plane: attractive but impractical.
I worked a bit on the DBus api, and I use it for my Emacs/Inkscape integration Inkmacs. It would be very inconvenient for me if the DBus API were to disapear.
My personal preference wouldn't be DBus though, but rather a GObject Introspection API. Furthermore I much prefer a Lisp interpreter over Python, like Guile which is pretty easy to embed. I realize that people seem to prefer Python though. With a GObject API you can have language bindings out of the box for many language implementations.
At any rate I'm very interested in working on an API for Inkscape that can be used from other programs, and I have also done so in the past.
I like having an API to work with, since I'm never very comfortable with traditional user interfaces. People tend to discuss option A or B forever, but never give any thought to option C which is the one I usually want. With proper API:s I can have C withouth bothering anyone else.
2a) Exposing API via DBus is more difficult than just making a binding, so according to the "worse is better" principle of Unix engineering, we can get more done in shorter time by simply creating a normal scripting language binding.
2b) While being able to use any language to create an Inkscape extension is an attractive feature, it is a nightmare waiting to happen from a maintainability point of view. It's a lot better to choose one language and stick to it, so that you don't need to know an arbitrary number of languages to debug an extension - only one. Python seems to be the natural choice, as the vast majority of existing extensions is in Python.
2c) The API of the existing DBus binding is really poor. For example, you have to hijack the global UI selection to do anything. This is a result of our internal API being just as poor - many functions operate on a selection, and that object is essentially a singleton. We need to able to create objects that represents the same structure as the selection and specify to what elements in the document an action should apply, but is not tied to UI in any way. (I wrote about this some time ago.)
- Inkscape for Android - I have no idea how that is going to work.
That would essentially be a completely different program. It could use some of our code if we up our game with regards to modularization, but that's all.
- 2Geom as a separate library - I am not sure about that. At some
point - yes, but not in the immediate future. Some parts of 2Geom API are now in reasonably good shape - for instance Rect, Path, the Curve hierarchy. However, others are really poor. For instance, the whole "Crossing" mess and old intersection APIs are very poorly designed; some shapes are missing the most obvious functions. Many of the toys don't actually showcase 2Geom's API, but contain a lot of nontrivial code, which is not present in the library itself.
- Renaming SPThings - I agree, and would also add that we should
reduce the proliferation of namespaces. Either put everything in Inkscape, or make at most a few second-level namespaces e.g. UI, XML, SVG (for things which now start with SP). Separate Widget and Dialog namespaces must die.
- We should think about linear RGB rendering, possibly in
floating-point linear scRGB colorspace. Cairo is not currently capable of this, unfortunately, but these sorts of operations are blazingly fast on GPUs. This would improve our rendering quality a lot and allow us to actually render filters correctly.
Regards, Krzysztof
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 4/11/2015 10:41 PM, joakim@...1974... wrote:
Krzysztof Kosiński <tweenk.pl@...400...> writes:
2015-04-08 23:07 GMT+02:00 Bryce Harrington <bryce@...961...>:
Beyond that... any and all feedback is welcomed! Come throw some darts!
- I think GTK 3 migration should be a little sooner. Reportedly GTK 3
has much better support for Windows and OS X. I also really want to get rid of all these ifdefs.
- DBus extensions - The more I think about this, the more I am
convinced this idea is like the laser-shooting plane: attractive but impractical.
I worked a bit on the DBus api, and I use it for my Emacs/Inkscape integration Inkmacs. It would be very inconvenient for me if the DBus API were to disapear.
My personal preference wouldn't be DBus though, but rather a GObject Introspection API. Furthermore I much prefer a Lisp interpreter over Python, like Guile which is pretty easy to embed. I realize that people seem to prefer Python though. With a GObject API you can have language bindings out of the box for many language implementations.
At any rate I'm very interested in working on an API for Inkscape that can be used from other programs, and I have also done so in the past.
I like having an API to work with, since I'm never very comfortable with traditional user interfaces. People tend to discuss option A or B forever, but never give any thought to option C which is the one I usually want. With proper API:s I can have C withouth bothering anyone else.
The OpenCV project has done an amazing job with their python implementation. It mirrors the c++ classes and has required minimal modification after initial setup. I think having the python available for computer vision has really opened up the ease of interfacing for users who did not want to recompile the entire project and use a higher level language. It has certainly made it easy for people to experiment with computer vision. Of course OpenCV has no UI. So I am referring to access to the internals. E.g. boolean ops in inkscape.
2a) Exposing API via DBus is more difficult than just making a binding, so according to the "worse is better" principle of Unix engineering, we can get more done in shorter time by simply creating a normal scripting language binding.
2b) While being able to use any language to create an Inkscape extension is an attractive feature, it is a nightmare waiting to happen from a maintainability point of view. It's a lot better to choose one language and stick to it, so that you don't need to know an arbitrary number of languages to debug an extension - only one. Python seems to be the natural choice, as the vast majority of existing extensions is in Python.
2c) The API of the existing DBus binding is really poor. For example, you have to hijack the global UI selection to do anything. This is a result of our internal API being just as poor - many functions operate on a selection, and that object is essentially a singleton. We need to able to create objects that represents the same structure as the selection and specify to what elements in the document an action should apply, but is not tied to UI in any way. (I wrote about this some time ago.)
- Inkscape for Android - I have no idea how that is going to work.
That would essentially be a completely different program. It could use some of our code if we up our game with regards to modularization, but that's all.
- 2Geom as a separate library - I am not sure about that. At some
point - yes, but not in the immediate future. Some parts of 2Geom API are now in reasonably good shape - for instance Rect, Path, the Curve hierarchy. However, others are really poor. For instance, the whole "Crossing" mess and old intersection APIs are very poorly designed; some shapes are missing the most obvious functions. Many of the toys don't actually showcase 2Geom's API, but contain a lot of nontrivial code, which is not present in the library itself.
- Renaming SPThings - I agree, and would also add that we should
reduce the proliferation of namespaces. Either put everything in Inkscape, or make at most a few second-level namespaces e.g. UI, XML, SVG (for things which now start with SP). Separate Widget and Dialog namespaces must die.
- We should think about linear RGB rendering, possibly in
floating-point linear scRGB colorspace. Cairo is not currently capable of this, unfortunately, but these sorts of operations are blazingly fast on GPUs. This would improve our rendering quality a lot and allow us to actually render filters correctly.
Regards, Krzysztof
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2015-04-12 2:26 GMT+02:00 Mark Schafer <mschafer@...2596...>:
The OpenCV project has done an amazing job with their python implementation. It mirrors the c++ classes and has required minimal modification after initial setup. I think having the python available for computer vision has really opened up the ease of interfacing for users who did not want to recompile the entire project and use a higher level language. It has certainly made it easy for people to experiment with computer vision.
The biggest difference between us and OpenCV is that OpenCV 1. is a library and 2. already had a reasonably good C / C++ API. Inkscape is a program, which means it can't work in the same way unless it is reimplemented as a set of Python modules, and does not have a reasonably good API yet.
I agree that allowing people to write scripts in Python that could access more of Inkscape's internals would be a big boon to innovation, but the API that we could hook up to Python is not yet there.
(Sorry for necropost, I forgot to send this.)
Regards, Krzysztof
participants (7)
-
unknown＠example.com -
Alex Valavanis -
Bryce Harrington -
Josh Andler -
Krzysztof Kosiński -
Mark Schafer -
Martin Owens