Discussion:
[Inkscape-devel] Inkscape 0.47 Development Plans
Bryce Harrington
2008-03-14 05:54:00 UTC
Permalink
Hi all,

With Inkscape 0.46 wrapping up, it's time to look forward to our next
release, 0.47, and our plans for its development.

When we started Inkscape, we began with a codebase with lots of
potential but with some architectural limitations that we've never quite
resolved. Inkscape has grown rapidly, especially thanks to Google's
Summer of Code program. Unfortunately, while we've gained a lot of new
features, it hasn't addressed the underlying issues - and in some cases
has exposed new problems.

Inkscape's also been extremely successful at gaining a lot of
contributors, yet this comes with a price: Stylistic differences,
accidental code duplication, unfinished code, obsoleted code, etc.

What will the codebase cleanup work entail? The work will range from
straightforward "grunt" work like making some simple code changes to all
files in the codebase, to meatier work like abstracting widely used code
into a more concise and powerful algorithm, to advanced work such as
extracting distinct code into independent code packages.

To boil this down into five high level objectives:

0. Complete some of the big architectural refactoring efforts
1. Reduce source code line count
2. Break useful code out into stand-alone libraries
3. Increase code stylistic consistency
4. Make the codebase more convenient to code in

Now, architectural reworkings can often risk incur massive breakages
since fundamental pieces of the code are being changed. In order to
minimize this, I'd like to suggest the following principles:

* Always keep the tree buildable
* Do major refactorings in small steps
* Hold code review parties with 2-3 others to brainstorm
* Drop copied-in codebases in favor of external dependencies
* Make sure every function you touch has some doxygen comments

Further, this kind of work can go on indefinitely without a clear
stopping point, so I think for this release we should use a schedule
with a date-based stopping point. This will help everyone know how they
should time their work.

Mar 10 Release 0.46. 0.47 Refactoring / Cleanup work begins
Apr
May
Jun
Jul 1 Completion of refactoring. Focus on Bug Fixing begins.
Open 0.48 development tree early, for GSoC work.
Aug Put out 0.47-pre releases.
Sep Release 0.47.

For reference, here are some key GSoC dates:

May 26 GSoC work begins.
Jul 14 GSoC midterm. First delivery of GSoC code
Aug 18 GSoC work ends.

This schedule permits us to focus exclusively on refactoring for several
months, with a due date of July 1st to complete it. It uses a very
early branch point, where we'll split into a stable branch for doing bug
fix and release work, and a development branch for the GSoC students to
use and for folks to continue right on with refactoring projects if they
wish.

Bryce
Bryce Harrington
2008-03-14 06:34:53 UTC
Permalink
Forgot to mention, I've also updated the Roadmap, and listed some more
specific tasks:

http://wiki.inkscape.org/wiki/index.php/Roadmap
Post by Bryce Harrington
Hi all,
With Inkscape 0.46 wrapping up, it's time to look forward to our next
release, 0.47, and our plans for its development.
When we started Inkscape, we began with a codebase with lots of
potential but with some architectural limitations that we've never quite
resolved. Inkscape has grown rapidly, especially thanks to Google's
Summer of Code program. Unfortunately, while we've gained a lot of new
features, it hasn't addressed the underlying issues - and in some cases
has exposed new problems.
Inkscape's also been extremely successful at gaining a lot of
contributors, yet this comes with a price: Stylistic differences,
accidental code duplication, unfinished code, obsoleted code, etc.
What will the codebase cleanup work entail? The work will range from
straightforward "grunt" work like making some simple code changes to all
files in the codebase, to meatier work like abstracting widely used code
into a more concise and powerful algorithm, to advanced work such as
extracting distinct code into independent code packages.
0. Complete some of the big architectural refactoring efforts
1. Reduce source code line count
2. Break useful code out into stand-alone libraries
3. Increase code stylistic consistency
4. Make the codebase more convenient to code in
Now, architectural reworkings can often risk incur massive breakages
since fundamental pieces of the code are being changed. In order to
* Always keep the tree buildable
* Do major refactorings in small steps
* Hold code review parties with 2-3 others to brainstorm
* Drop copied-in codebases in favor of external dependencies
* Make sure every function you touch has some doxygen comments
Further, this kind of work can go on indefinitely without a clear
stopping point, so I think for this release we should use a schedule
with a date-based stopping point. This will help everyone know how they
should time their work.
Mar 10 Release 0.46. 0.47 Refactoring / Cleanup work begins
Apr
May
Jun
Jul 1 Completion of refactoring. Focus on Bug Fixing begins.
Open 0.48 development tree early, for GSoC work.
Aug Put out 0.47-pre releases.
Sep Release 0.47.
May 26 GSoC work begins.
Jul 14 GSoC midterm. First delivery of GSoC code
Aug 18 GSoC work ends.
This schedule permits us to focus exclusively on refactoring for several
months, with a due date of July 1st to complete it. It uses a very
early branch point, where we'll split into a stable branch for doing bug
fix and release work, and a development branch for the GSoC students to
use and for folks to continue right on with refactoring projects if they
wish.
Bryce
Maximilian Albert
2008-03-14 12:57:49 UTC
Permalink
Post by Bryce Harrington
Forgot to mention, I've also updated the Roadmap, and listed some more
http://wiki.inkscape.org/wiki/index.php/Roadmap
Regarding the C++-ification of SPObjects, what is the best way to
proceed? As I understand it, it is not really possible (or feasible) to
mix GObjects and true C++ objects so I suppose that we would need to
first switch "under the hood" and then get rid of the GObject framework
in one go, right?

So for each SPObject a corresponding C++ class needs to be created which
encapsulates its functionality, and all the SPObject "methods" would be
changed to only call the corresponding ones of the new class (as seems
to already be the case in sp-item-group.cpp). Is that correct or am I
getting something completely wrong here? Should we keep a list on the
wiki for which SPObjects this conversion has already be done so that we
can keep track of the progress?

Max
MenTaLguY
2008-03-15 20:58:19 UTC
Permalink
Post by Maximilian Albert
So for each SPObject a corresponding C++ class needs to be created which
encapsulates its functionality, and all the SPObject "methods" would be
changed to only call the corresponding ones of the new class (as seems
to already be the case in sp-item-group.cpp). Is that correct or am I
getting something completely wrong here? Should we keep a list on the
wiki for which SPObjects this conversion has already be done so that we
can keep track of the progress?
I'm not happy with the approach that was taken with CGroup -- I think
it's an unmaintainable mess, and we'd be unlikely to ever finish the
migration if we went that route.

My preferred approach would be to replace GObject with NRObject in the
SPObject hierarchy, removing the inter-SPObject refcounting (which would
create unbreakable GC cycles) and explicit member initialization (no
longer needed, as NRObject calls the C++ constructor/destructors). At
that point we can start using all C++ features directly in the existing
SPObject classes.

It's a big hurdle to get over initially, but it's one shot, and once we
do it we can start improving the design and adopting native C++ features
organically and incrementally.

-mental
MenTaLguY
2008-03-15 22:01:19 UTC
Permalink
Post by MenTaLguY
My preferred approach would be to replace GObject with NRObject in the
SPObject hierarchy, removing the inter-SPObject refcounting (which would
create unbreakable GC cycles) and explicit member initialization (no
longer needed, as NRObject calls the C++ constructor/destructors). At
that point we can start using all C++ features directly in the existing
SPObject classes.
Actually, I think it may be best if I move the GC stuff into e.g. a
distinct NRGCObject subclass, so that we don't have to do the GC
migration things at the same time as everything else.

-mental
Chris Lilley
2008-03-14 13:40:45 UTC
Permalink
On Friday, March 14, 2008, 7:34:53 AM, Bryce wrote:

BH> Forgot to mention, I've also updated the Roadmap, and listed some more
BH> specific tasks:

BH> http://wiki.inkscape.org/wiki/index.php/Roadmap

In milestones 15 and 16, which seem to be focussed on mobile, multipage is listed.

Does that date from when the SVG WG was trying to use the same page construct for actual printed pages and also for animation scenes? (We no longer do this). SVG Tiny 1.2 does not have multipage.

However, it does have a bunch of other features that would be interesting to author - video, audio, discard, the animation element, and so forth.

Is anyone else interested in working on a list of SVG Tiny 1.2 features that go beyond SVG 1.1, from an authoring perspective, and discussing what authoring challenges each feature might present?

Same question, but this time for authoring SVG Print documents. In case the answer to my first question was "no, it means multiple pages like in SVG Print".
--
Chris Lilley mailto:***@w3.org
Interaction Domain Leader
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG
Bryce Harrington
2008-03-14 18:05:25 UTC
Permalink
Post by Chris Lilley
BH> Forgot to mention, I've also updated the Roadmap, and listed some more
BH> http://wiki.inkscape.org/wiki/index.php/Roadmap
In milestones 15 and 16, which seem to be focussed on mobile, multipage is listed.
Does that date from when the SVG WG was trying to use the same page construct for actual printed pages and also for animation scenes? (We no longer do this). SVG Tiny 1.2 does not have multipage.
No, it's just an oft-requested feature, and coincidental that it got
listed there.

Note that while our milestones "declare" a focus, in reality much of
Inkscape development is parallel, and strongly driven by the developer
interest. So we may say that Foo feature is scheduled for 0.49, but if
no one is interested in working on it, it might get pushed back to ever
later releases (which is what has happened with both animation and
multipage.) On the other hand, other features which are of interest,
often get done earlier.

So, it's best to think of the Roadmap not as a work plan, but more of a
weather forecast.

Bryce
Jon A. Cruz
2008-03-14 06:53:00 UTC
Permalink
Post by Bryce Harrington
Now, architectural reworkings can often risk incur massive breakages
since fundamental pieces of the code are being changed. In order to
* Always keep the tree buildable
* Do major refactorings in small steps
* Hold code review parties with 2-3 others to brainstorm
* Drop copied-in codebases in favor of external dependencies
* Make sure every function you touch has some doxygen comments
I think you missed one key point.

We need to get the unit test passing and updated.

Although some fails are not too hard to fix, but there are a few that
are probably critical. I recall that at least one is due to one of
our core string-enum-string round trips is failing. For that one we
might need to change a core assumption and approach.

I think that getting them working and keeping them working is
probably only second to "Always keep the tree buildable". If we can
have unit tests working and added to, then most of the other problems
can be reduced.

One other way to describe this is...

Before we start climbing up the front of the building to start
tearing down the facade, let's make sure we have a scaffolding up and
bolted solidly together instead of just leaning out from the window
ledges.

:-)
Maximilian Albert
2008-03-14 12:23:29 UTC
Permalink
Post by Jon A. Cruz
We need to get the unit test passing and updated.
Is there an overview of the test framework available somewhere? How does
it work? What is already there, what needs to be updated or newly
implemented and how can this be done? Sorry if these are dumb questions
(I couldn't find anything on the wiki) but apparently I haven't yet got
in touch with the testing stuff but would be interested in having a look
at it (if only to be able to have it in mind during future coding).

Max
Bryce Harrington
2008-03-14 18:21:34 UTC
Permalink
Post by Maximilian Albert
Post by Jon A. Cruz
We need to get the unit test passing and updated.
Is there an overview of the test framework available somewhere? How does
it work? What is already there, what needs to be updated or newly
implemented and how can this be done? Sorry if these are dumb questions
(I couldn't find anything on the wiki) but apparently I haven't yet got
in touch with the testing stuff but would be interested in having a look
at it (if only to be able to have it in mind during future coding).
There isn't an overview in Wiki, but you can see the code itself in
inkscape/cxxtest, which includes a simple user's guide in the README.
You can also see examples in inkscape/src/round-test.h,
extract-uri-test.h, etc.

Note there is also a src/utest/, which is used by attributes-test.h and
style-test.cpp. It seems to me that it's redundant to have two
different unit test systems in the code. cxxtest seems to be more
widely used; perhaps the tests currently using utest should be converted
to cxxtest, and utest dropped.

It would also be good to create a Wiki page about the test framework
(with a pointer to cxxtest's README for details) in case others go
looking for it. Maximilian, would you mind creating this?

Bryce
Bryce Harrington
2008-03-14 18:22:28 UTC
Permalink
Post by Jon A. Cruz
We need to get the unit test passing and updated.
Agreed; I've added this:
http://wiki.inkscape.org/wiki/index.php/0.47_Refactoring_Plan

Bryce
MenTaLguY
2008-03-15 20:49:03 UTC
Permalink
Post by Jon A. Cruz
We need to get the unit test passing and updated.
We also need to break up dependencies and stub/mock things as needed so
that individual test suites don't take 45 minutes to build.

As long as new test runs take as long as they currently do, I don't
think anyone's going to be seriously using the unit tests for anything.

-mental
j***@joncruz.org
2008-03-15 22:05:35 UTC
Permalink
Post by MenTaLguY
Post by Jon A. Cruz
We need to get the unit test passing and updated.
We also need to break up dependencies and stub/mock things as needed so
that individual test suites don't take 45 minutes to build.
As long as new test runs take as long as they currently do, I don't
think anyone's going to be seriously using the unit tests for anything.
Sounds like there is some debugging to do on the process. I don't see anything
near that on my system.

If I go into the src directory, ensure my inkscape compile is up to date, then
fire off a check, it goes very quickly:

real 0m42.900s
user 0m34.698s
sys 0m3.588s

So I'm seeing 43 seconds to build and execute the base unit tests, but you're
seeing 45 minutes. Something is seriously different.

Perhaps we need to just collect this on a "Unit Test Pain" page so we can fix it
for people seeing bad behavior.
MenTaLguY
2008-03-15 22:28:59 UTC
Permalink
Post by j***@joncruz.org
Sounds like there is some debugging to do on the process. I don't see anything
near that on my system.
If I go into the src directory, ensure my inkscape compile is up to date, then
real 0m42.900s
user 0m34.698s
sys 0m3.588s
So I'm seeing 43 seconds to build and execute the base unit tests, but you're
seeing 45 minutes. Something is seriously different.
It's been a while since I've looked at the tests -- it sounds like this
problem may already be fixed?

-mental
jiho
2008-03-14 09:54:35 UTC
Permalink
Post by Bryce Harrington
[...]
No