Since release is nearing, let's talk 0.48 and beyond...
Hey All,
Kinda lengthy, but, please read and respond if you intend to be involved in the upcoming releases.
In numerous off-list discussions with a handful of devs and contributors it seems like there is a favored route for the upcoming releases. Essentially, make 0.47 "good enough" (avoid point releases if possible). Have a short dev cycle for 0.48 which needs to be pretty solid (even if made so over time by point releases... I will commit to continuing a couple of those). Then we go for another long-ish refactoring cycle for 0.49.
For 0.48 the thought is to... move to a DVCS before any code changes are made in trunk. This needs to be discussed and resolved ASAP, svn is not good enough for our needs any longer, period. Then, we drop in this year's SoC work, the spray tool, any big things that are far enough along in people's working copies, polish up everything and fix all new issues discovered from 0.47... if we're lucky, further text tool work could make it in too. Additionally, if we could get cairo work in a branch (under said DVCS) during this cycle, it would be excellent to possibly get something to drop in for the 0.49 dev cycle... this is part of why the stability and functionality of this release is critical (trunk may need to have issues for a bit after 0.48 drops).
For 0.49 the thought is to attempt to ditch our copy of gdl in favor of submitting the necessary bits upstream and using it as a proper library. It has been said before, it would be really excellent if we could have 2geom be broken out and used as a proper library. I understand the general "it's an experiment" and "we can't promise a stable api" issues, but, the cord needs to be cut at sometime and I think this is fair notice. Also, this is how gimp is being developed with babl and gegl... so it is doable and a non-issue (I use unstable gimp too, so I know from experience of having to update them both when I want to update gimp).
Any objections or concerns that people feel the need to voice? Anything that other people would like to see during these releases?
Cheers, Josh
Joshua A. Andler wrote:
For 0.48 the thought is to... move to a DVCS before any code changes are made in trunk. This needs to be discussed and resolved ASAP, svn is not good enough for our needs any longer, period. Then, we drop in this year's SoC work, the spray tool, any big things that are far enough along in people's working copies, polish up everything and fix all new issues discovered from 0.47... if we're lucky, further text tool work could make it in too. Additionally, if we could get cairo work in a branch (under said DVCS) during this cycle, it would be excellent to possibly get something to drop in for the 0.49 dev cycle... this is part of why the stability and functionality of this release is critical (trunk may need to have issues for a bit after 0.48 drops).
Great idea. I still vote for git, but since I don't plan to do the work myself I will happily use whatever I get!
It has been said before, it would be really excellent if we could have 2geom be broken out and used as a proper library. I understand the general "it's an experiment" and "we can't promise a stable api" issues, but, the cord needs to be cut at sometime and I think this is fair notice. Also, this is how gimp is being developed with babl and gegl... so it is doable and a non-issue (I use unstable gimp too, so I know from experience of having to update them both when I want to update gimp).
(I hope someone who is more experienced will chime in here.) Is it meaningful for this discussion to mention that babl, gegl and gimp are C projects. 2geom and inkscape are C++ and it was my understanding that there were special problems and considerations for C++ library versioning and compatibility. Perhaps we could strongly recommend that packagers package inkscape and 2geom together with 2geom being built as a dynamic library named specially so it won't conflict with other uses of 2geom on the system. This would of course only be an intermediate step and only if the 2geom developers and resident C++ experts find it necessary.
Aaron Spike
...
Great idea. I still vote for git, but since I don't plan to do the work myself I will happily use whatever I get!
I would vote for bazaar because I work on windows and need a system that works natively here. Also it looks that there is a good integration in Launchpad ... Adib.
It has been said before, it would be really excellent if we could have 2geom be broken out and used as a proper library. I understand the general "it's an experiment" and "we can't promise a stable api" issues, but, the cord needs to be cut at sometime and I think this is fair notice. Also, this is how gimp is being developed with babl and gegl... so it is doable and a non-issue (I use unstable gimp too, so I know from experience of having to update them both when I want to update gimp).
(I hope someone who is more experienced will chime in here.) Is it meaningful for this discussion to mention that babl, gegl and gimp are C projects. 2geom and inkscape are C++ and it was my understanding that there were special problems and considerations for C++ library versioning and compatibility. Perhaps we could strongly recommend that packagers package inkscape and 2geom together with 2geom being built as a dynamic library named specially so it won't conflict with other uses of 2geom on the system. This would of course only be an intermediate step and only if the 2geom developers and resident C++ experts find it necessary.
Aaron Spike
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
the Adib wrote:
...
Great idea. I still vote for git, but since I don't plan to do the work myself I will happily use whatever I get!
I would vote for bazaar because I work on windows and need a system that works natively here.
I am also a windows user. What sort of native windows functionality do you use from bzr?
I don't make heavy use of git on windows but I have cloned repos occasionally using msysgit and tortoisegit.
http://code.google.com/p/msysgit/ http://code.google.com/p/tortoisegit/
Windows users who would like to have input on the choice of VCS, please test these tools and give us your impressions.
Also it looks that there is a good integration in Launchpad ...
For launchpad integration bzr is a clear winner. My hope is that now that lp is fully opened, we will start to see support for other VCSs. I don't think we should wait for this. If lp integration is a must, bzr is the only choice.
Let me just reiterate, I will be happy with whatever we choose.
Aaron Spike
I am also a windows user. What sort of native windows functionality do you use from bzr?
I don't make heavy use of git on windows but I have cloned repos occasionally using msysgit and tortoisegit.
http://code.google.com/p/msysgit/ http://code.google.com/p/tortoisegit/
Windows users who would like to have input on the choice of VCS, please test these tools and give us your impressions.
Since you asked re: msysgit...
As a user of msysgit (CLI only), I find it quite stable in my daily use and am happy with it. The issue has been raised in other forums that since it currently carries the "preview" label, it's perceived as "not stable for critical development needs" by some. For my needs, I've found this to be absolutely false and the feedback usually comes from someone who hasn't yet tried it out and/or has other reasons for not wanting to move to Git.
On the bigger issue of Which DVCS, for Inkscape *users* rather than developers, I strongly believe it's a don't care red herring.
Pick the one that makes the most sense to enable your core contributors to collaborate, quickly get it implemented and begin using it. While we *users* may prefer one over the other (probably the first one we tried), any of us that do want to actually start looking at the source are probably going to be able to quickly start using whatever one you choose with not a lot of drama. The core cloning, pulling, and diffing aren't that different.
I started with Mercurial, liked it and still do, swore I'd never use Git and ironically find myself using msysgit/Github daily and liking it. I've installed and uninstalled bzr too many times to count, but saw nothing to indicate I couldn't pick it up quickly and start running if interested.
Jon
Josh,
thanks for picking this up. However I really want this 0.47 out the door!
I want for 0.48 (adib didn't check the roadmap do): - file dialogues as in Gimp - put all the non svg formats into export/import - cmake support - connector tool width rounded corners - uniconvertor that can handle text - release 0.48 around christmas ....
the Adib. ---
On Sun, Sep 13, 2009 at 8:16 AM, Joshua A. Andler <scislac@...400...> wrote:
Hey All,
Kinda lengthy, but, please read and respond if you intend to be involved in the upcoming releases.
In numerous off-list discussions with a handful of devs and contributors it seems like there is a favored route for the upcoming releases. Essentially, make 0.47 "good enough" (avoid point releases if possible). Have a short dev cycle for 0.48 which needs to be pretty solid (even if made so over time by point releases... I will commit to continuing a couple of those). Then we go for another long-ish refactoring cycle for 0.49.
For 0.48 the thought is to... move to a DVCS before any code changes are made in trunk. This needs to be discussed and resolved ASAP, svn is not good enough for our needs any longer, period. Then, we drop in this year's SoC work, the spray tool, any big things that are far enough along in people's working copies, polish up everything and fix all new issues discovered from 0.47... if we're lucky, further text tool work could make it in too. Additionally, if we could get cairo work in a branch (under said DVCS) during this cycle, it would be excellent to possibly get something to drop in for the 0.49 dev cycle... this is part of why the stability and functionality of this release is critical (trunk may need to have issues for a bit after 0.48 drops).
For 0.49 the thought is to attempt to ditch our copy of gdl in favor of submitting the necessary bits upstream and using it as a proper library. It has been said before, it would be really excellent if we could have 2geom be broken out and used as a proper library. I understand the general "it's an experiment" and "we can't promise a stable api" issues, but, the cord needs to be cut at sometime and I think this is fair notice. Also, this is how gimp is being developed with babl and gegl... so it is doable and a non-issue (I use unstable gimp too, so I know from experience of having to update them both when I want to update gimp).
Any objections or concerns that people feel the need to voice? Anything that other people would like to see during these releases?
Cheers, Josh
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Adib,
I think we all want 0.47 out the door just as bad. ;)
I completely agree about gimp's newer handling of files, and theoretically it should be very easy for us to make the changes quickly and easily. For everyone's sake, it's a better approach that we should share with the gimp.
Perhaps cmake support should be held off for that longer 0.49 cycle since it's a type of refactoring. I wouldn't be opposed to it for 0.48, but have no idea how far off it really is at this point.
I'm pretty sure the connector tool request you have was done in the SoC work that is planned to be merged.
The short response is, 0.48 around Christmas is just not possible. Mid-December Feature Freeze could be possible though if 0.47 is out in a month though.
One last thing to shoot for for 0.48 would be for the LPEs that could take advantage of the new node tool to be updated (such as envelope).
Cheers, Josh
On Sun, 2009-09-13 at 14:48 +0200, the Adib wrote:
Josh,
thanks for picking this up. However I really want this 0.47 out the door!
I want for 0.48 (adib didn't check the roadmap do):
- file dialogues as in Gimp - put all the non svg formats into export/import
- cmake support
- connector tool width rounded corners
- uniconvertor that can handle text
- release 0.48 around christmas ....
the Adib.
On Sun, Sep 13, 2009 at 8:16 AM, Joshua A. Andler <scislac@...400...> wrote:
Hey All,
Kinda lengthy, but, please read and respond if you intend to be involved in the upcoming releases.
In numerous off-list discussions with a handful of devs and contributors it seems like there is a favored route for the upcoming releases. Essentially, make 0.47 "good enough" (avoid point releases if possible). Have a short dev cycle for 0.48 which needs to be pretty solid (even if made so over time by point releases... I will commit to continuing a couple of those). Then we go for another long-ish refactoring cycle for 0.49.
For 0.48 the thought is to... move to a DVCS before any code changes are made in trunk. This needs to be discussed and resolved ASAP, svn is not good enough for our needs any longer, period. Then, we drop in this year's SoC work, the spray tool, any big things that are far enough along in people's working copies, polish up everything and fix all new issues discovered from 0.47... if we're lucky, further text tool work could make it in too. Additionally, if we could get cairo work in a branch (under said DVCS) during this cycle, it would be excellent to possibly get something to drop in for the 0.49 dev cycle... this is part of why the stability and functionality of this release is critical (trunk may need to have issues for a bit after 0.48 drops).
For 0.49 the thought is to attempt to ditch our copy of gdl in favor of submitting the necessary bits upstream and using it as a proper library. It has been said before, it would be really excellent if we could have 2geom be broken out and used as a proper library. I understand the general "it's an experiment" and "we can't promise a stable api" issues, but, the cord needs to be cut at sometime and I think this is fair notice. Also, this is how gimp is being developed with babl and gegl... so it is doable and a non-issue (I use unstable gimp too, so I know from experience of having to update them both when I want to update gimp).
Any objections or concerns that people feel the need to voice? Anything that other people would like to see during these releases?
Cheers, Josh
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Color Management in 4.7 final or in 4.8 ?
and I mean support for icc profiles / color managed view ..
2009/9/13 Joshua A. Andler <scislac@...400...>:
Adib,
I think we all want 0.47 out the door just as bad. ;)
I completely agree about gimp's newer handling of files, and theoretically it should be very easy for us to make the changes quickly and easily. For everyone's sake, it's a better approach that we should share with the gimp.
Perhaps cmake support should be held off for that longer 0.49 cycle since it's a type of refactoring. I wouldn't be opposed to it for 0.48, but have no idea how far off it really is at this point.
I'm pretty sure the connector tool request you have was done in the SoC work that is planned to be merged.
The short response is, 0.48 around Christmas is just not possible. Mid-December Feature Freeze could be possible though if 0.47 is out in a month though.
One last thing to shoot for for 0.48 would be for the LPEs that could take advantage of the new node tool to be updated (such as envelope).
Cheers, Josh
On Sun, 2009-09-13 at 14:48 +0200, the Adib wrote:
Josh,
thanks for picking this up. However I really want this 0.47 out the door!
I want for 0.48 (adib didn't check the roadmap do):
- file dialogues as in Gimp - put all the non svg formats into export/import
- cmake support
- connector tool width rounded corners
- uniconvertor that can handle text
- release 0.48 around christmas ....
the Adib.
On Sun, Sep 13, 2009 at 8:16 AM, Joshua A. Andler <scislac@...400...> wrote:
Hey All,
Kinda lengthy, but, please read and respond if you intend to be involved in the upcoming releases.
In numerous off-list discussions with a handful of devs and contributors it seems like there is a favored route for the upcoming releases. Essentially, make 0.47 "good enough" (avoid point releases if possible). Have a short dev cycle for 0.48 which needs to be pretty solid (even if made so over time by point releases... I will commit to continuing a couple of those). Then we go for another long-ish refactoring cycle for 0.49.
For 0.48 the thought is to... move to a DVCS before any code changes are made in trunk. This needs to be discussed and resolved ASAP, svn is not good enough for our needs any longer, period. Then, we drop in this year's SoC work, the spray tool, any big things that are far enough along in people's working copies, polish up everything and fix all new issues discovered from 0.47... if we're lucky, further text tool work could make it in too. Additionally, if we could get cairo work in a branch (under said DVCS) during this cycle, it would be excellent to possibly get something to drop in for the 0.49 dev cycle... this is part of why the stability and functionality of this release is critical (trunk may need to have issues for a bit after 0.48 drops).
For 0.49 the thought is to attempt to ditch our copy of gdl in favor of submitting the necessary bits upstream and using it as a proper library. It has been said before, it would be really excellent if we could have 2geom be broken out and used as a proper library. I understand the general "it's an experiment" and "we can't promise a stable api" issues, but, the cord needs to be cut at sometime and I think this is fair notice. Also, this is how gimp is being developed with babl and gegl... so it is doable and a non-issue (I use unstable gimp too, so I know from experience of having to update them both when I want to update gimp).
Any objections or concerns that people feel the need to voice? Anything that other people would like to see during these releases?
Cheers, Josh
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Joshua A. Andler-2 wrote:
Perhaps cmake support should be held off for that longer 0.49 cycle since it's a type of refactoring. I wouldn't be opposed to it for 0.48, but have no idea how far off it really is at this point.
CMake support needs to be substantially rewritten before it's usable, because the current work is incompatible with Linux and Mac. Windows linkers resolve back references between static libraries (e.g. libX.a can have references to libY.a and libY.a can have references to libX.a), while Linux linkers don't (no circular dependencies between .a files are allowed). Currently CMake tries to link one library per directory, which does not work because of circular dependencies.
Personally I don't like CMake because its syntax is weak (no boolean expressions in conditionals; nothing like Automake's += exists so I have to spell out a variable's name twice if I want to append something, e.g. SET(inkscape_sources ${inkscape_sources} some-file.cpp)), ugly and irregular (sometimes case-sensitive and sometimes not). Some of its built-in macros are apparently incompatible with C++.
SCons looks much nicer to me. It allows you to use the full power of Python for build scripts, but I have not used it much yet. Certainly the number of people who can read Python is much greater than the number which can read CMake macros, so more people could diagnose and fix build problems. Currently we suffer from the fact that Automake is somewhat arcane and adding new useful features to it (SVN revision in the About dialog for example) is a pain. It looks sufficiently capable, and it's used in commercial projects like Google Chrome and VMware. The downside is that it doesn't have native support for gettext internationalization.
Does anyone have strong opinions on build systems, or know some 'killer features' that could affect the choice?
Regards, Krzysztof Kosiński
Krzysztof Kosiński wrote:
Does anyone have strong opinions on build systems, or know some 'killer features' that could affect the choice?
I believe build systems all do pretty much the same thing. For any system we could point to at least one or two large projects that use it as proof of its sufficiency. Comprehensibility is an important feature and I believe this is what is driving the search for a new system. But in my opinion the most important feature any build system can have is a group of skilled and energetic people to implement and maintain the necessary configuration for Inkscape.
Aaron Spike
2009/9/14 Krzysztof Kosiński <tweenk.pl@...400...>:
SCons looks much nicer to me. It allows you to use the full power of Python for build scripts, but I have not used it much yet.
I have the same feeling, but unfortunately also the same lack of experience. I only used SCons for a small project recently, but it looked and felt very easy to use and quite powerful. The use of Python is a big plus IMHO, and I believe it would be quite suitable for our purposes. FWIW, the free music typesetter Lilypond [1] is currently also looking for an alternative to automake (but their requirements are a lot more advanced than ours). In the discussion, someone pointed out SCons's slowness as a big disadvantage and suggested to look at waf instead. [2][3] But as I said, I have almost no experience with SCons and none with waf, so I cannot really judge the statements and it would be interesting to hear other people's opinions and experiences.
Max
[1] http://www.lilypond.org [2] http://code.google.com/p/waf/ [3] See this email: http://lists.gnu.org/archive/html/lilypond-devel/2009-09/msg00169.html
Maximilian Albert-2 wrote:
In the discussion, someone pointed out SCons's slowness as a big disadvantage and suggested to look at waf instead. [2][3]
Thanks for the pointer. Even now Make takes quite a bit of time to compute the dependencies when rebuilding. If SCons is more than 10x slower than Make as evidenced in the benchmarks, then this might become a big problem.
At a glance Waf looks promising, I'll research it some more. The speed is certainly an advantage.
Regards, Krzysztof
On Sep 14, 2009, at 11:38 AM, Krzysztof Kosiński wrote:
Thanks for the pointer. Even now Make takes quite a bit of time to compute the dependencies when rebuilding. If SCons is more than 10x slower than Make as evidenced in the benchmarks, then this might become a big problem.
Generally that is a breakdown of the application of Make and/or recursive make. The latter is usually the main time killer.
The paper "Recursive Make Considered Harmful" does a good job exploring these issues, including file system access and dependency graph generation.
Jon A. Cruz wrote:
The paper "Recursive Make Considered Harmful" does a good job exploring these issues, including file system access and dependency graph generation.
I read that paper :) and agree with the conclusions. When I do any substantial build system work, I will run some benchmarks. First I will try Waf, and if it's not enough I'll go with CMake.
Regarding the monolithic library - I agree that this is a serious performance hit. However, the dependencies between directories are not specified and everything tends to depend on everything. Putting all things in a single library was the only way to get rid of the situation where a Windows developer adds some code and it builds correctly for him, and when he commits the build is broken for the Unix developers, which then have to conduct dark rituals and move files to unrelated directories to fix the build. If we clearly specify the dependencies between our subsystems so that there are no cyclic dependencies, we can go back to building several static libraries.
From the discussion, it looks like:
- 0.47 was a mixed refactoring / feature cycle. - 0.48 will be an infrastructure work cycle (merging GSoC work, build system and DVCS changes). I think we should try to rip out the GDL dependency during this cycle too, as it fits with the theme. - 0.49 should be a heavy refactoring cycle where we look hard at the SP tree, the renderer, etc.
Regards, Krzysztof Kosiński
On Sep 14, 2009, at 11:38 AM, Krzysztof Kosiński wrote:
Thanks for the pointer. Even now Make takes quite a bit of time to compute the dependencies when rebuilding. If SCons is more than 10x slower than Make as evidenced in the benchmarks, then this might become a big problem.
Oh, and I forgot to mention the other main data-point on this. When our build was switched from the separate libs build to one monolithic build-and-link, the times for me to do a build after editing a single file grew significantly, moving from seconds to several minutes. This was on OS X, and I have seen performance differ based on the OS.
So we definitely would need to measure things on different platforms and for different use cases (full build vs. developer tweak-and-build, etc.)
On Mon, 2009-09-14 at 10:15 -0700, Krzysztof Kosiński wrote:
Does anyone have strong opinions on build systems, or know some 'killer features' that could affect the choice?
make distcheck and out of tree builds. And support for "make -j" type actions. Intltool support too. But yes, I agree with Aaron, excited people make all the difference :)
--Ted
On Sep 14, 2009, at 10:15 AM, Krzysztof Kosiński wrote:
SCons looks much nicer to me. It allows you to use the full power of Python for build scripts, but I have not used it much yet. Certainly the number of people who can read Python is much greater than the number which can read CMake macros, so more people could diagnose and fix build problems. Currently we suffer from the fact that Automake is somewhat arcane and adding new useful features to it (SVN revision in the About dialog for example) is a pain. It looks sufficiently capable, and it's used in commercial projects like Google Chrome and VMware. The downside is that it doesn't have native support for gettext internationalization.
Does anyone have strong opinions on build systems, or know some 'killer features' that could affect the choice?
Some of the larger early proponents of SCons have since moved on to CMake.
SCons has had some major cross-platform breakdowns. At one point I tried to build a SCons-based project on OS X, and even with hacking the SCons sources themselves, I was unable to do so.
Before the recent Inkscape efforts to explore CMake, SCons was carefully reviewed and evaluated.
2009/9/14 Krzysztof Kosiński wrote:
SCons looks much nicer to me. It allows you to use the full power of Python for build scripts
If Python is really what you need, just use waf - at least it doesn't play silly buggers by telling a user (s)he doesn't have a particular version of SCons, because waf script has no dependencies other Python itself. Ardour3 has moved to waf a while ago.
Alexandre
Alexandre Prokoudine wrote:
If Python is really what you need, just use waf
That's what I did. I'm far from building Inkscape wih Waf, but slowly making some progress. There are some undocumented things, but hopefully I'll be able to figure them out based on examples and Waf source.
Regards, Krzysztof
Joshua A. Andler-2 wrote:
Essentially, make 0.47 "good enough" (avoid point releases if possible). Have a short dev cycle for 0.48 which needs to be pretty solid (even if made so over time by point releases... I will commit to continuing a couple of those). Then we go for another long-ish refactoring cycle for 0.49.
A sound plan, I agree :)
For 0.48 the thought is to... move to a DVCS before any code changes are made in trunk.
I vote for bzr. There is hardly anything to learn with respect to SVN (you can use the exact same commands but substitute 'svn' for 'bzr') and the Launchpad integration is a big benefit. For example, branches with tentative fixes could be attached to complicated bugs.
Additionally, if we could get cairo work in a
branch (under said DVCS) during this cycle, it would be excellent to possibly get something to drop in for the 0.49 dev cycle
Is there any plan on how we're going to do this? Do we write a new C++ library that is similar to libnr but nicer to work with and uses Cairo and 2Geom internally, or rip out rendering code from libnr and replace it with Cairo operations?
For 0.49 the thought is to attempt to ditch our copy of gdl in favor of submitting the necessary bits upstream and using it as a proper library.
+1. In addition to our modifications I would like to see support for creating dock items with named icons.
It has been said before, it would be really excellent if we could have 2geom be broken out and used as a proper library.
I think this could be done when 2Geom has something resembling a coherent API :) Right now some files are just copies of old Inkscape code (for example bezier-utils.h) and several objects are ugly (rtree.h). At a minimum, this could be postponed until 0.49.
Regards, Krzysztof Kosiński
On Sun, 2009-09-13 at 18:08 -0700, Krzysztof Kosiński wrote:
I vote for bzr
Noted
Additionally, if we could get cairo work in a branch (under said DVCS) during this cycle, it would be excellent to possibly get something to drop in for the 0.49 dev cycle
Is there any plan on how we're going to do this? Do we write a new C++ library that is similar to libnr but nicer to work with and uses Cairo and 2Geom internally, or rip out rendering code from libnr and replace it with Cairo operations?
bulia, can you please comment on what you think would be the best course of action given your experiments/testing? I know you've been going it along in this department for quite a while which is why I proposed getting a branch going... I'm sure others would love to help make it happen.
Cheers, Josh
On Sat, 2009-09-12 at 23:16 -0700, Joshua A. Andler wrote:
Have a short dev cycle for 0.48 which needs to be pretty solid (even if made so over time by point releases... I will commit to continuing a couple of those). Then we go for another long-ish refactoring cycle for 0.49.
One thing that Debian is considering is fixed dates for freezes. So they'd do a freeze on a fixed schedule, and then release when it's ready. I'm curious if this might work for us long term, certainly with a DVCS we'd have more flexibility there.
For 0.48 the thought is to... move to a DVCS before any code changes are made in trunk. This needs to be discussed and resolved ASAP, svn is not good enough for our needs any longer, period. Then, we drop in this year's SoC work, the spray tool, any big things that are far enough along in people's working copies, polish up everything and fix all new issues discovered from 0.47...
I just want to say here that if we're going to switch to a DVCS, I think we should switch BEFORE merging the SoC projects in. We'll get a better version history there and it'll also make the merges better.
For 0.49 the thought is to attempt to ditch our copy of gdl in favor of submitting the necessary bits upstream and using it as a proper library.
+1, the GDL guys have also offered some help with this. It may be possible for 0.48 even.
It has been said before, it would be really excellent if we could have 2geom be broken out and used as a proper library.
Yes! I don't believe there are any more C++ issue with this now that they've spec'd the ABI.
Any objections or concerns that people feel the need to voice? Anything that other people would like to see during these releases?
I'd like to see if we can't do the same type of library splitouts with libavoid and libcoroco...
Also, I'd like to make it so that we're a little more independent for extensions as well. That way we could release extensions in a different release schedule than the core Inkscape.
--Ted
On Sun, 2009-09-13 at 23:09 -0500, Ted Gould wrote:
On Sat, 2009-09-12 at 23:16 -0700, Joshua A. Andler wrote:
Have a short dev cycle for 0.48 which needs to be pretty solid (even if made so over time by point releases... I will commit to continuing a couple of those). Then we go for another long-ish refactoring cycle for 0.49.
One thing that Debian is considering is fixed dates for freezes. So they'd do a freeze on a fixed schedule, and then release when it's ready. I'm curious if this might work for us long term, certainly with a DVCS we'd have more flexibility there.
Interesting approach... I think that this may work for us too after 0.49 since it may be a little unpredictable with the library changes.
For 0.48 the thought is to... move to a DVCS before any code changes are made in trunk. This needs to be discussed and resolved ASAP, svn is not good enough for our needs any longer, period. Then, we drop in this year's SoC work, the spray tool, any big things that are far enough along in people's working copies, polish up everything and fix all new issues discovered from 0.47...
I just want to say here that if we're going to switch to a DVCS, I think we should switch BEFORE merging the SoC projects in. We'll get a better version history there and it'll also make the merges better.
I thought that was what I said... move to a DVCS before any code changes are made in trunk. :)
Any objections or concerns that people feel the need to voice? Anything that other people would like to see during these releases?
I'd like to see if we can't do the same type of library splitouts with libavoid and libcoroco...
Agreed.
Cheers, Josh
On Sun, Sep 13, 2009 at 10:16 AM, Joshua A. Andler wrote:
Any objections or concerns that people feel the need to voice? Anything that other people would like to see during these releases?
In 0.48:
1. Add an already created Airbrush tool. I played with this a little and it is quite cool, even though some terminology is inevitably techie.
2. Integrate GSoC projects. IMO since we already have D-BUS integration there, we need to do same what GIMP did - checking for an already running instance and using it instead of creating a new process.
3. Finish Maximilian's patch for guides selection. Being able to distribute guides like objects would be awesome. Another low hanging fruit here will be what Scribus has since 1.3.5 - aligning objects to a selected guideline.
4. Finish Jon's autoswatches, if he will have time for this.
5. Use recently added color management in poppler based PDF/AI import plug-in.
In 0.49:
I don't know how many times this was already discussed, but we need a single release which would *really* concentrate on bugfixing and quality/speed of rendering. Yep, I know that all day bugfixing and no new feature makes Jack a dull suicidal boy, but let's face it -- Inkscape is a tortoise crawling uphill to die at the top of Kilimanjaro. This really should stop. Just like all the craze with renderiing artefacts in gradients.
Another thing that should have happened ages ago is switching to the usual coordinates system.
Alexandre
On Mon, 2009-09-14 at 09:53 +0400, Alexandre Prokoudine wrote:
On Sun, Sep 13, 2009 at 10:16 AM, Joshua A. Andler wrote:
I don't know how many times this was already discussed, but we need a single release which would *really* concentrate on bugfixing and quality/speed of rendering. Yep, I know that all day bugfixing and no new feature makes Jack a dull suicidal boy, but let's face it -- Inkscape is a tortoise crawling uphill to die at the top of Kilimanjaro. This really should stop. Just like all the craze with renderiing artefacts in gradients.
I think that 0.48 and it's point releases will take care of the focus on bugfixing (in the meantime)... seriously. If we plan to do as much focused refactoring during 0.49 as has been touched upon, we will need to maintain 0.48 actively for probably well over a year (yes, I'm not joking and am willing to commit to ensuring we have those releases happen). The reality is though, we will probably introduce a number of all new bugs with 0.49 that won't be discovered before it's released... and it is unavoidable.
Another thing that should have happened ages ago is switching to the usual coordinates system.
I think this would be perfect for 0.49.
Cheers, Josh
On Mon, Sep 14, 2009 at 10:21 AM, Joshua A. Andler wrote:
I think that 0.48 and it's point releases will take care of the focus on bugfixing (in the meantime)... seriously.
Yay, those point releases have been like good old friends to me that you don't see anymore after moving to a new continent :) If we are really going to have them back, then surely serious bugfixing can be part of 0.48.x.
Alexandre
On Mon, 2009-09-14 at 10:24 +0400, Alexandre Prokoudine wrote:
On Mon, Sep 14, 2009 at 10:21 AM, Joshua A. Andler wrote:
I think that 0.48 and it's point releases will take care of the focus on bugfixing (in the meantime)... seriously.
Yay, those point releases have been like good old friends to me that you don't see anymore after moving to a new continent :) If we are really going to have them back, then surely serious bugfixing can be part of 0.48.x.
The point releases have a place... we should have had a couple for 0.46 honestly. If you would like to point fingers, I am willing to take the blame for it as I was a release warden for it and for this release. This release cycle was a real eye opener as to what being overly optimistic gets you. I want to avoid point releases for 0.47 if possible and really focus on the transition to a DVCS and then 0.48 and it's point releases. We know 0.49 will not happen for quite a while which is why I'm being so vocal about a plan to have the point releases for 0.48.
Before 0.47 we hadn't had any major refactoring cycles... we now know how long it can take and how bad it can be to clean up. With this hindsight, we know as a community what needs to be done differently. I can't do much more than to tell you I'm committed to maintaining 0.48 while the people really doing the hard work can focus on what they need to for the refactoring effort. I will backport any fixes possible, I will ask for help when needed, I will put in the time necessary to make sure that 0.48 and it's point releases will be rockin'.
Cheers, Josh
P.S. Move continents all you want Alexandre, I'll nag you wherever you go. ;)
On Mon, Sep 14, 2009 at 10:38 AM, Joshua A. Andler wrote:
The point releases have a place... we should have had a couple for 0.46 honestly. If you would like to point fingers, I am willing to take the blame for it as I was a release warden for it and for this release.
No fingers, no blame. The long 0.46/0.47 development cycles got quite a few important contributors burnt out. We need to learn to deal with it, IMO.
P.S. Move continents all you want Alexandre, I'll nag you wherever you go. ;)
That goes without saying :)
P.S. Thank you for posting 0.47 screenshots btw!
Alexandre
Alexandre,
Is your continent not big enough for you? I'm certain you won't find a bigger one (on this planet).
;)
JF
Joshua A. Andler wrote:
On Mon, 2009-09-14 at 10:24 +0400, Alexandre Prokoudine wrote:
On Mon, Sep 14, 2009 at 10:21 AM, Joshua A. Andler wrote:
I think that 0.48 and it's point releases will take care of the focus on bugfixing (in the meantime)... seriously.
Yay, those point releases have been like good old friends to me that you don't see anymore after moving to a new continent :) If we are really going to have them back, then surely serious bugfixing can be part of 0.48.x.
The point releases have a place... we should have had a couple for 0.46 honestly. If you would like to point fingers, I am willing to take the blame for it as I was a release warden for it and for this release. This release cycle was a real eye opener as to what being overly optimistic gets you. I want to avoid point releases for 0.47 if possible and really focus on the transition to a DVCS and then 0.48 and it's point releases. We know 0.49 will not happen for quite a while which is why I'm being so vocal about a plan to have the point releases for 0.48.
Before 0.47 we hadn't had any major refactoring cycles... we now know how long it can take and how bad it can be to clean up. With this hindsight, we know as a community what needs to be done differently. I can't do much more than to tell you I'm committed to maintaining 0.48 while the people really doing the hard work can focus on what they need to for the refactoring effort. I will backport any fixes possible, I will ask for help when needed, I will put in the time necessary to make sure that 0.48 and it's point releases will be rockin'.
Cheers, Josh
P.S. Move continents all you want Alexandre, I'll nag you wherever you go. ;)
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2009-September-14 , at 07:53 , Alexandre Prokoudine wrote:
but let's face it -- Inkscape is a tortoise crawling uphill to die at the top of Kilimanjaro. This really should stop.
I am sorry to concur that this is indeed a very big problem. When I first used Inkscape (6 years ago), it felt lean and to the point. Sure it was limited. But the things it could do, it did fast and efficiently UI-wise. Now, I hate to say that, but Inkscape often feels bloated. It has a wealth of new features, many of which were repeatedly asked for, but sometimes it feels like too many, too fast. Some of it is due to things being added and added again to the UI without a general overhaul (which leaves Inkscape with 3 toolbars, a larger bottom bar, less screen real estate for the actual drawing, so many tools that they don't fit on a decent 1280x800 screen etc.). Most of the feeling of bloatiness, however, seems to actually come from slowness. Many new features make Inkscape so slow that they soon become unusable (blur, some LPEs, numerous snapping possibilites etc.). This is probably exacerbated on my system because I use Inkscape on a laptop (still, a top of the line one) and the X server on OS X is not very efficient. Yet it looks like a very real problem on other systems and platforms too...
My message probably does not seem very constructive. I sure don't mean to upset anyone (especially not those who already worked on speeding up the rendering of blurs, disentangling the snapping possibilites etc.). I guess that many of the core coders of Inkscape are aware of the issues and even know where the bottlenecks are. I would just like to stress, as a user, that: - speed is a feature, - because of a lack of speed, some of the very cool new features of Inkscape are not used to their full potential (and sometimes not even used at all), which is really too bad.
Working on speed improvements is probably more tedious and less rewarding than coding an all new feature but maybe this "ungrateful" message, and others like it, could motivate more people to continue tackling these issues.
Thanks in advance,
PS: I am still VERY grateful for Inkscape ;)
JiHO --- http://maururu.net
On 9/14/09, JiHO <jo.lists@...400...> wrote:
Some of it is due to things being added and added again to the UI without a general overhaul (which leaves Inkscape with 3 toolbars, a larger bottom bar, less screen real estate for the actual drawing, so many tools that they don't fit on a decent 1280x800 screen etc.). Most of the feeling of bloatiness, however, seems to actually come from slowness. Many new features make Inkscape so slow that they soon become unusable (blur, some LPEs, numerous snapping possibilites etc.).
...none of which existed 6 years ago :)
Not to say we don't need to speed it all up of course - but if you hide all toolbars you don't need and use only basic path objects, it's probably going to be just as snappy as those early versions. (Except for startup time, though, which now most directly depends on the number of fonts on your system.)
On Fri, Sep 18, 2009 at 23:06, bulia byak <buliabyak@...400...> wrote:
On 9/14/09, JiHO <jo.lists@...400...> wrote:
Some of it is due to things being added and added again to the UI without a general overhaul (which leaves Inkscape with 3 toolbars, a larger bottom bar, less screen real estate for the actual drawing, so many tools that they don't fit on a decent 1280x800 screen etc.). Most of the feeling of bloatiness, however, seems to actually come from slowness. Many new features make Inkscape so slow that they soon become unusable (blur, some LPEs, numerous snapping possibilites etc.).
...none of which existed 6 years ago :)
Not to say we don't need to speed it all up of course - but if you hide all toolbars you don't need and use only basic path objects, it's probably going to be just as snappy as those early versions. (Except for startup time, though, which now most directly depends on the number of fonts on your system.)
Thanks for the reply. Indeed, *I* can do that because I know what I need and what to do with the software. A new user would not though. And more importantly, many of these new features are useful (swatches, snapping toolbar, etc.) or very cool (LPEs, etc.) so they make me (and everyone I guess) want to use them ;). However, their accumulation and sometimes their slowness makes for an overall more frustrating experience, e.g. "Inkscape has blur, wicked!... uh oh, it seems I cannot add more than 4 or 5 objects with a large blur before Inky crawls". Similarly, the new behaviour of the dropper tool is very useful, except it is made difficult to reach by the connector tool and flood fill tools that I never use but cannot move out of the way.
Basically I am not saying that new features are bad, and especially those that were added to Inkscape these last 6 years, but that speeding up and better accommodating those features in the UI would be a worth a feature in itself. And, from a few discussions I had with new Inkscape users and the original email of Alexandre, the speed part at least seems to be a commonly acknowledged. People I initially interested into Inkscape are sometimes switching back to AI (Adobe Illustrator, no less than this pack of ... !!) because Inkscape cannot handle their thousand-paths drawing smoothly (which is common when importing graphs from other software). It hurts. ;)
JiHO --- http://maururu.net
On 9/23/09, JiHO <jo.lists@...400...> wrote:
Basically I am not saying that new features are bad, and especially those that were added to Inkscape these last 6 years, but that speeding up and better accommodating those features in the UI would be a worth a feature in itself.
And that is normal lifecycle in open source software - indeed any sofrware. No feature is ever released in fully optimized form. Its first implementation is often clumsy and slow. Over time it is gradually optimized and streamlined (but new clumsy ones are added at the same time!). What is critical here is that we support a sufficient level of vigorousness in the developer community so that code does not stagnate and is constantly improved. Refactorings (as much as I hate them personally :) are also very important - after each refactoring, apart from its direct advantages of better code, we get a new developer who is deeply interested and willing to support his refactored part of the code.
On Mon, Sep 14, 2009 at 7:11 PM, JiHO <jo.lists@...400...> wrote:
On 2009-September-14 , at 07:53 , Alexandre Prokoudine wrote:
but let's face it -- Inkscape is a tortoise crawling uphill to die at the top of Kilimanjaro. This really should stop.
I am sorry to concur that this is indeed a very big problem. When I first used Inkscape (6 years ago), it felt lean and to the point. Sure it was limited.
Sorry for joining the discussion this late but I'd just like to provide a little balance to our views of Inkscape. This is almost only based on personal experience but I'd still like convey how well Inkscape works in my production pipeline.
I've worked as a designer the last 8 years with various tools (Illustrator, Photoshop, Fireworks, Corel Draw, InDesign). The last 2 years, I've used Inkscape professionally as a "screen based" designer and I'd just like to say that working with this application is such a relief compared to working in Adobe Illustrator CSx and the like.
I normally use Fireworks for most screen based designs and slicing but as I'm trying to move to Linux I'm also interested in moving to FLOSS design applications.
*Things I enjoy daily with Inkscape:* * Beatiful, correct, slim SVGs! No bloat! It's even possible to explore the source by clicking individual elements in the drawing. * Inkscape starts within 10-12 secs while Illustrator finally comes around after 30-35 sec * With some tweaks, using Inkscape as a slicing tool for any web design file *does* work even if the export format is limited to .png. Inkscape is unique here in the sense that you can choose to export a certain area or just a single background image even if it's covered with other design elements. It even supports relative paths. The concept of slices has to be made somewhat clearer, though, maybe with the option of viewing the slices as coloured squares or make the names and paths appear on top of exportable objects at the right view setting. * Quite powerful command line. Helped me convert 390 SVGs in a flash recently. * Really fast and comfortable * Excellent support for reuse of objects, colors, gradients and filters. * Really fast and flexible path drawing tools. Almost redeems some of the inflexibility wrt stroke inside/outside/center on path. * Really pleasant to be able to apply styles by copying and pasting between objects.
*Areas for improvement* ** Strokes* - hard to use properly because it is not possible to set the stroke inside or outside the path, only centered on the path. This is especially troublesome with stroked text as the stroke can only be so wide before the fill colour is completely covered. Especially with stroked Affects the work quite a lot more often than anticipated. I must admit, this is one of the real time-wasters when drawing icons or doing other precision work that require high stroke accuracy. * *Semi-transparent strokes *- kinda the same story here. This is actually a bit worse since it is hard to convince potentially new Inkscapers to create 2 shapes or to juggle a dynamic offset shape only to be able to have a convincing semi-transparent stroke on text or or around images. * *Filters* - Hard to use at the moment but the filter presets help very much, of course. * *Toggle all toolbars*/settings panels, palettes on and off. Like pressing F12, only more powerful. I do not mind the current amount of setting bars and toolbars as long as the can be toggled easily in and out of view. After all, this means that almost all needed tools could be available at the press of a button and then quickly removed as the drawing operation takes place. It's the mode of work I've grown accustomed to in other tools and it turns out to be very effective. Also, it's a *very* nice feature when when doing customer presentations of the design since all focus can be devoted to the drawing and not the GUI of the drawing application.
*And BTW*: Thanks so much for the new Windows Explorer save/open file dialog in 0.47! Supports filtering files by using wildcards (*) as a part of the filename, thumbnails, sorting by file size, modefied date etc. All you would expect to work under Windows. Only the preview is a bit lacking with regards to showing bitmaps embedded in SVGs but I can live with that :)
With regs,
JimmyVolatile
Jimmy Volatile wrote:
*Areas for improvement* ** Strokes* - hard to use properly because it is not possible to set the stroke inside or outside the path, only centered on the path. (...)
I think this, and the semi-transparent stroke thing, would be better served by improving dynamic and linked offset. In general, the outset/inset, and to some extent even dynamic offset, are superfluous. There should be only 1 item (offset) which would work like dynamic offset when applied to a normal object, and like linked offset when applied to a clone. There should also be a way to specify whether the offset is round, miter or bevel (so miter offset would work like what you get after: union, set stroke of desired width, stroke to path, break apart and delete the inner subpath).
An additional effect called Half Stroke would work like offset + live Boolean XOR (so that if the offset is positive, the source is subtracted from the offset, and if it's negative the offset is subtracted from the source).
However, this needs a lot of grunt work "in the bowels" (at the SP tree level) to simplify creating elements saved as svg:switch, as well as in 2Geom to make Boolean operations precise and easier to perform. I use dynamic offsets often, so it could be a nice GSoC 2010 project.
Regards, Krzysztof
On Sat, Sep 19, 2009 at 3:04 AM, JimmyVolatile wrote:
- Toggle all toolbars/settings panels, palettes on and off. Like pressing
F12, only more powerful.
Shift+F11
We never exposed this in UI, did we, Ted? :)
Alexandre
Ah. Thanks!
No, it's like you say, it's not in the UI.
There's only: View --> Show/Hide Dialogs View --> Commands Bar, Snap Controls Bar, Tool Controls Bar, Toolbox, Rulers, Scrollbars, Palette, Status bar
So, View --> Show/Hide All Toolbars (or similar) would of course fit nicely here :)
(Using: Inkscape 0.47pre2 r22153, built Aug 24 2009 on WinXP)
BTW: I managed to drag loose some of the toolbars, which ended up floating around as separate .exe instances. When I tried to drag the toolbars back into the right place, they didn't re-attach. I'll report the bug if it's not already registered.
With regs,
Jarl Arntzen
On Mon, Sep 21, 2009 at 8:32 AM, Alexandre Prokoudine < alexandre.prokoudine@...400...> wrote:
On Sat, Sep 19, 2009 at 3:04 AM, JimmyVolatile wrote:
- Toggle all toolbars/settings panels, palettes on and off. Like pressing
F12, only more powerful.
Shift+F11
We never exposed this in UI, did we, Ted? :)
Alexandre
Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 9/21/09, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On Sat, Sep 19, 2009 at 3:04 AM, JimmyVolatile wrote:
- Toggle all toolbars/settings panels, palettes on and off. Like pressing
F12, only more powerful.
Shift+F11
We never exposed this in UI, did we, Ted? :)
That's not good. Ted, would you please make sure any features and especially shortcuts you add, including this one and "quick zoom", are added to: 1) release notes and 2) doc/keys.xml? Thanks!
On Mon, Sep 21, 2009 at 6:55 PM, bulia byak wrote:
> * Toggle all toolbars/settings panels, palettes on and off. Like pressing > F12, only more powerful.
Shift+F11
We never exposed this in UI, did we, Ted? :)
That's not good. Ted, would you please make sure any features and especially shortcuts you add, including this one and "quick zoom", are added to: 1) release notes and 2) doc/keys.xml? Thanks!
The plan was to merge it with the other clutter removal tool already exposed in UI :)
Alexandre
On 9/21/09, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
The plan was to merge it with the other clutter removal tool already exposed in UI :)
Any plans notwithstanding, everything that works in 0.47 (even by accident :) must be fully reflected in the 0.47 documentation.
On Mon, 2009-09-21 at 10:32 +0400, Alexandre Prokoudine wrote:
On Sat, Sep 19, 2009 at 3:04 AM, JimmyVolatile wrote:
- Toggle all toolbars/settings panels, palettes on and off. Like pressing
F12, only more powerful.
Shift+F11
We never exposed this in UI, did we, Ted? :)
No, it's a secret. Don't tell anyone! :)
Bulia, I'll write the release notes. I had actually forgotten about those :)
--Ted
-----Original Message----- From: Ted Gould [mailto:ted@...11...] Sent: 22 September, 2009 02:09 To: Alexandre Prokoudine Cc: Inkscape Devel List Subject: Re: [Inkscape-devel] Since release is nearing, let's talk 0.48 and beyond...
On Mon, 2009-09-21 at 10:32 +0400, Alexandre Prokoudine wrote:
On Sat, Sep 19, 2009 at 3:04 AM, JimmyVolatile wrote:
- Toggle all toolbars/settings panels, palettes on and off. Like
pressing
F12, only more powerful.
Shift+F11
We never exposed this in UI, did we, Ted? :)
No, it's a secret. Don't tell anyone! :)
Bulia, I'll write the release notes. I had actually forgotten about those :)
--Ted
There is a bus on XP, it's like the tablet is not reinitialized with the new window coordinates after using F11 or Shift+F11.
https://bugs.launchpad.net/bugs/386237
Preben
On Mon, Sep 21, 2009 at 11:08 PM, Ted Gould wrote:
Shift+F11
We never exposed this in UI, did we, Ted? :)
No, it's a secret. Don't tell anyone! :)
Too late. It's already cached by Google.
Thus, as they say in Ukraine, "Тиха украинская ночь. Но сало лучше перепрятать". Which means in this case they you need to hide this feature again somewhere else :)
Alexandre
I've created a revised roadmap page (http://wiki.inkscape.org/wiki/index.php?title=Roadmap_revised) with the proposed changes.
Apparently the animation stuff is not going to be a focus for .48 or .49, so I took that and everything else out that seemed extraneous until the refactoring is finished.
If this seem acceptable, I'll continue to work on integrating the points I took out (any ideas what should go where? I mean, should I just insert the Animation and SVG spec stuff in after the refactor, or would we want to add it elsewhere?). Then we can replace the current roadmap with this one?
Please feel free to update this roadmap revision, or let me know if you notice something that needs to be updated or explained (I'll be happy to do it for those who don't have the time). It's obviously a very rough draft, and based solely on what a few people have mentioned they'd like to see done.
Something else which might be handy is to do "assignments" - whoever wants to volunteer to a specific item can put his name with it, just so we have a better idea of what is likely to be done and what is not being addressed. Then keep the progress updated (like the Scribus wiki)?
Thoughts?
JF
Joshua A. Andler wrote:
Hey All,
Kinda lengthy, but, please read and respond if you intend to be involved in the upcoming releases.
In numerous off-list discussions with a handful of devs and contributors it seems like there is a favored route for the upcoming releases. Essentially, make 0.47 "good enough" (avoid point releases if possible). Have a short dev cycle for 0.48 which needs to be pretty solid (even if made so over time by point releases... I will commit to continuing a couple of those). Then we go for another long-ish refactoring cycle for 0.49.
For 0.48 the thought is to... move to a DVCS before any code changes are made in trunk. This needs to be discussed and resolved ASAP, svn is not good enough for our needs any longer, period. Then, we drop in this year's SoC work, the spray tool, any big things that are far enough along in people's working copies, polish up everything and fix all new issues discovered from 0.47... if we're lucky, further text tool work could make it in too. Additionally, if we could get cairo work in a branch (under said DVCS) during this cycle, it would be excellent to possibly get something to drop in for the 0.49 dev cycle... this is part of why the stability and functionality of this release is critical (trunk may need to have issues for a bit after 0.48 drops).
For 0.49 the thought is to attempt to ditch our copy of gdl in favor of submitting the necessary bits upstream and using it as a proper library. It has been said before, it would be really excellent if we could have 2geom be broken out and used as a proper library. I understand the general "it's an experiment" and "we can't promise a stable api" issues, but, the cord needs to be cut at sometime and I think this is fair notice. Also, this is how gimp is being developed with babl and gegl... so it is doable and a non-issue (I use unstable gimp too, so I know from experience of having to update them both when I want to update gimp).
Any objections or concerns that people feel the need to voice? Anything that other people would like to see during these releases?
Cheers, Josh
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Joshua Facemyer wrote:
I've created a revised roadmap page (http://wiki.inkscape.org/wiki/index.php?title=Roadmap_revised) with the proposed changes.
- Based on what was said until now, I think 0.48 should be an infrastructure work release. We should limit ourselves to merging GSoC work, changing to a DVCS, switching the build system to Waf or CMake, and unforking GDL. If we limit ourselves to those 4 tasks we MIGHT succeed in meeting the tentative 6 month deadline. I can take the build system work in addition to integrating my GSoC project, since I already did one overhaul some time ago.
- 0.49 and later can then concentrate on refactoring. I already did some work in the tools department by writing C++ classes to replace SPKnot, so I can work on improving the internal tools APIs in the 0.49 cycle: making each tool a C++ object, integrating clipboard handlers and toolbar creation into those objects so that most of the code related to a tool is in one place, creating context menus that are actually useful (when done right they could even replace the toolbox), and the like.
- "Support for creating dock items with named icons" is a GDL improvement, so it should be together with the other GDL item.
- It needs clarification what "Switch to the usual coordinates system" means. Does it mean making the dt2doc transform an identity?
- I have once drafted a roadmap update proposal but then forgot about it. It may contain some bad ideas, but hopefully it has some useful ones as well. It's here: http://wiki.inkscape.org/wiki/index.php/Roadmap_update_proposal
Regards, Krzysztof Kosiński
participants (15)
-
Aaron Spike -
Alexandre Prokoudine -
bulia byak -
JiHO -
JimmyVolatile -
Jon -
Jon A. Cruz -
Joshua A. Andler -
Joshua Facemyer -
Krzysztof Kosiński -
Maximilian Albert -
Preben Soeberg -
SorinN -
Ted Gould -
the Adib