We've been discussing what needs to be done for the Pangoification work that we identified as required for 0.39, and what scope of work we should pursue for this release.
One of the key factors driving the consideration is that we've got a lot of (cool but non-Pango) things implemented in the codebase right now that we'd like to get released to users soon. Unfortunately, the quantity of work to do the full conversion over to Pango 100% is daunting, especially considering the wide number of platform bugs we're certain will crop up.
Thus, we are floating this idea for how to scope the Pango work for this release:
0. Document all of the routines in libnrtype
1. Create a copy of libnrtype in the codebase called libnrtype_pango
2. Go through all of the nr-*.cpp routines in libnrtype_pango and rewrite them to use Pango calls. This is the bulk of the work, but I figure this could be done by a couple developers in a week or so.
3. Cleanup and remove whatever files and code become obsolete from libnrtype_pango in the process.
4. Create a compile-time option --with-libnrtype-pango that controls whether inkscape is built with the existing type renderer, or our new Pango-based one.
5. Get Inkscape able to compile and run with the new libnrtype_pango code; if it misses a lot of existing features or has a lot of new quirks, that's perfectly fine - we'll fix them later.
6. Finish up all the non-Pango development work and finalize the release.
7. Generate two sets of packages for Windows, Linux, and Mac: One compiled with libnrtype_pango for testing, the other compiled with the existing type renderer for regular usage.
We then will adjust the Roadmap by moving the 0.40 milestone and all subsequent ones forward one release and introducing a new 0.40 milestone that focuses on the second phase of the Pango conversion.
The advantage of this change to the Roadmap is that it buys us additional development and testing time for Pango but still gets the current work out and available for users to start taking advantage of and testing out. Another advantage is that it will enable us (including users) to test out the feasibility of switching to Pango without having to take the full plunge all at once.
Previously, we had not scoped out precisely what would be done for this release for Pango, so had assumed we'd try to get 100% finished with it; this may be doable but appears to be unrealistic to achieve within an acceptable amount of time.
Please let us know if this plan sounds suitable, or if not, what adjustments to it that you would suggest.
Thanks, Bryce
On Sun, 2004-06-06 at 16:52 -0700, Bryce Harrington wrote:
Please let us know if this plan sounds suitable, or if not, what adjustments to it that you would suggest.
Sounds like a good compromise between releasing regularly and evolving the codebase. The two can't always be done completely simultaneously.
It is a good time to get a release out with piqued interest via ./, osnews, and our community.
I think this sounds brilliant. Will give us a more realistic target to clean up app for this release...it have been like 2 months since last release.
Hopefully we can all take a look at the roadmap and sign up for tasks to push it along...About how long will the rest of this milestone take. While I'm not pointing to a time-based release, but what is the reasonable amount of time till we release so I can plan my energy output.
Jon
On Sun, 2004-06-06 at 17:02, Charles Goodwin wrote:
On Sun, 2004-06-06 at 16:52 -0700, Bryce Harrington wrote:
Please let us know if this plan sounds suitable, or if not, what adjustments to it that you would suggest.
Sounds like a good compromise between releasing regularly and evolving the codebase. The two can't always be done completely simultaneously.
On Sun, 6 Jun 2004, Jon Phillips wrote:
Hopefully we can all take a look at the roadmap and sign up for tasks to push it along...About how long will the rest of this milestone take. While I'm not pointing to a time-based release, but what is the reasonable amount of time till we release so I can plan my energy output.
Well, in discussing this with mental and bulia we sense that there is still some work to do on other non-Pango features to get them finalized; for instance, the sluggishness that has been noticed with the fill and stroke dialog, etc. This finalization work would need at least a couple of weeks to settle out and bring to a close.
Second, we do need to make at least one concerted pass through the bug tracker; this is a development release and we can probably afford to release with less intensive bug fixing than previously, but we still should make sure to swat the critical bugs.
Third, for the pango work itself, we would estimate that it's a few person-weeks of effort, but a guestimate of about a week for two developers would probably not be too far off. Fred is committed to working on it, Similarius has offered to help test the Win32 side of things, and so we need one more volunteer with good programming chops to help Fred on it, who can do some work recasting algorithms from NRType style to Pango style, focusing on it intently for a week or two.
These three lines of effort could certainly go on in parallel, if we can get enough people pitching in. If we do, then I think it's definitely realistic that we could get a release out within the month of June, assuming we can pump through the release process itself within half a week or so. Otherwise it could take another few weeks beyond that.
So, I know that a lot of people are working on a lot of different interesting areas, but the trick to getting this release out the door soon is for them to get to a good stopping point and turn attention to bug fixing.
Bryce
participants (3)
-
Bryce Harrington -
Charles Goodwin -
Jon Phillips