Thorsten's Weblog

So, got some time to work on SVG import again. Gradients are now working pretty good (within the limits of OOo/ODF, of course), basic text support is in as well. Most importantly, I added a graphic filter for SVG, such that e.g. openclipart images can be easily included. But see the discussion here about my long-term plans about that – OOo’s internal metafile neither has the fidelity, not do I see much sense in implementing the n-th SVG renderer (the mapping from SVG to ODF is an altogether different story, and I will keep improving that).

As usual, patches available in ooo-build, binaries will appear here.

Some sample cliparts imported as graphics:

Feeling somewhat challenged by the other Thorsten’s comments that “some groups in the community say, these [processes] hinder the contribution to the project”, I cannot but present a slightly different view on that topic.

OOo was using child workspaces already for 2.0, so this is not a discriminating factor, and neither is valgrind (which was also in use before – and on top of that, focused fixing of valgrind issues resulted in a total of 35 issues fixed, versus 41 issues still open).

Leaves warning free code and crash reports – the former is all about defect prevention (from personal experience, actually making the code warning free did result in fixing a few serious bugs, but most of them were minor issues – the benefits come afterwards). The latter is about fixing issues after OOo has been released to the general public, and is indeed a great tool – but it does not explain why the numbers of new issues has been kept consistently lower than for 2.0 (if that’s not obvious: something must have changed before releasing the code).

So, my explanation for the significant differences between 2.0 and 3.0 would be

• introduction of some defect prevention measures
• but most importantly: taking the pressure off of the hackers to finish features at a certain point in time

This was achieved via a so-called train model, having frequent feature releases instead of 24-month big-bang style development. Needless to say that this style is standard for almost every opensource development. And coming back to the opening paragraph, I do believe that certain processes in place at vanilla OOo hinder community contributions – I’m talking about code contribution here, and I see a significant difference between contributions of part-time hackers to ooo-build, in comparison to vanilla OOo. The question is, what’s the focus of the project (community? the product?) – and, which of those processes have significant influence on quality and which don’t (and which can be replaced by other, similarly effective measures, that are more hacker-friendly).

As mentioned, we did some focused usability bugfixing during Novell’s Project Pedigree – here’s a brief account on what I did for Impress:

Previously, when you saved an Impress document with a non-default zoom level (i.e. slightly zoomed in or out), repeated load/save cycles would move the document display increasingly farther to the right (first image: original, second image: after first reload, third: after three reloads). Fixed now.

Another one: moving text frames with the mouse is hard – one has to hit an invisible, four-pixel-wide area around the text. Added better visual clues to that, by taking the same hatched frame for moving that is already used when editing the text content (the advantage becomes especially apparent when the text box is also rotated).

A bunch of users had apparently fooled themselves when inserting pictures as links into their documents (because moving either the OOo file or the linked pictures usually kills the document). So I added a big, fat warning dialog, and also made the state of the “I want a linked graphic” checkbox in the file selector non-persistent.

Other fixes made during Pedigree: VCL transparent printing is now much smarter (spool files will tend to be much smaller), PowerPoint export will now keep linked graphics as links, a bunch of crashers&uninitialized variables are now gone, fixed the fact that leaving the inplace OLE editing mode ends up in a selection frame, and backported issue i69364 and issue i76650 to 2.4. All of this is included in ooo-build – get a copy here.

Does this sound familiar: there’s a ton of stuff to do, which people put on a list. Every day, things from the top of the list get done, and other things are added to the bottom of the list. Usually, these lists are sorted for priority – which means, if there are enough high-priority tasks coming in, (almost) all lower-prio tasks will suffer from starvation.

For OOo, the list is IssueZilla, and the starving low-prio tasks are affectionally named “OOo later” – that name has the nice property of being eternally correct, as later usually never comes…

My conjecture would be that about every bugtracker in this world has those issues – annoying, but never important enough to be fixed for the upcoming release (but surely for the one after that…). At least it’s the same for Novell’s bugzilla. What’s the computer scientist’s answer to this class of problems: fair queuing – partition the input into priority classes, and assign each class an own queue and a minimal fraction of the resource-to-be-scheduled. This ensures members of each class at least minimal progress, and prevents starvation (at the cost of limited throughput for the highest priority class, of course).

So, well, that’s what we did here at Novell: we set aside a fixed fraction of time for Project Pedigree, which was all about fixing those small, but very annoying issues that our internal users have reported over time (or even reported for the first time – we went around and asked them about their favorite pet peeve). Smart idea, and I really enjoyed touching application code again – in fact, the work was quite similar to the very focused bi-weekly iterations I did during the agile experiment at Sun, as there have been (almost) no interruptions.

I’m currently wrapping up the Impress part of the Pedigree project, stay tuned for the list of things achieved.