Having a video in your Impress slideshow is nice, not being able to control start, stop or pause during your talk is sometimes just an annoyance. I recently got around fixing that, and put up a little screencast (ogg video, see here for a list of players) that should give you an idea what’s possible now (stuff as usual available in recent go-oo builds).

Note: the used video is Big Buck Bunny, copyright Blender Foundation | www.bigbuckbunny.org, and licensed under Creative Commons Attribution 3.0.

Being honoured with having a session at the OpenSuSE Helping Hands, I faced the problem of creating a screencast under Linux. Considering the load of vnc-based solutions inherently un-sexy, I tried istanbul and recordmydesktop - with the latter appealing to my knack for command-line utils (an extra requirement was no-hassles support for the very nice USB headset MMX2, which recordmydesktop’s “-device” option solved quite nicely).

So without further ado, here’s the recordmydesktop v0.3.7.3 cmd line I used:

recordmydesktop -delay 2 -device hw:1,0 --on-the-fly-encoding -s_quality 1 -width 1024 -height 768 --quick-subsampling --overwrite -o "path_to_ogg_file"

Of course the device option can either be ommitted, or needs to be adapted, depending on your local alsa setup. Recording starts after two seconds, when you’re done with your ramblings, press Alt-Ctrl-S. Some results of me doing screencasts can be found here.

Wow. Hub just pointed me at one of the recent GCC developer summit’s talks (also quite interesting: coding rule checking and incremental compilation, which goes along nicely with gold’s (not-yet-implemented) incremental linking), which presents a static c++ code analysis framework, implemented on top of GCC (I mentioned some previous attempts at that before).

Derivatives:

• dehydra-generated source code cross-reference
• pork, a code rewriting tool for refactoring
• treehydra, a GCC plugin that gives access to the AST via a JavaScript interface

Hopefully the days of rebuilding all of OOo, just to find all places an overloaded member was called, are finally gone…

With some 7 million lines of code (depending on how you count it), mostly c++, OOo is extremely challenging for everybody starting to hack on it. There’s a set of excellent tutorials on building, debugging & hacking on OOo - alas, and the end of the day, smooth coding requires thorough understanding of the inner workings and functional dependencies - in short, the design of OOo. I guess that’s where our documentation story is still lacking (with some notable exceptions, e.g. the API developer’s guide, or the UNO subsystem documentation). The problem with good (design) documentation is that it’s

• hard to write
• tedious to keep up-to-date (in fact, I believe most static source code documentation is always at least partially outdated)

To somewhat fill this gap (and avoid the staleness issue), I’ve setup doxygen-autogenerated source code documentation at go-oo. As of now, this is only a partial set of modules (because of runtime and space constraints) - feel free to drop me a note if your favorite module is missing.

Two examples for auto-generated inheritance graphs:

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.

]]> http://blog.thebehrens.net/2008/05/21/recent-impress-fixes/feed/ thorstenb http://blog.thebehrens.net/2008/05/19/fair-queuing/ http://blog.thebehrens.net/2008/05/19/fair-queuing/#comments Mon, 19 May 2008 21:06:29 +0000 thorstenb http://thorstenb.wordpress.com/?p=110

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.

]]> http://blog.thebehrens.net/2008/05/19/fair-queuing/feed/ thorstenb http://blog.thebehrens.net/2008/05/10/lgm-2008/ http://blog.thebehrens.net/2008/05/10/lgm-2008/#comments Sat, 10 May 2008 08:41:11 +0000 thorstenb http://thorstenb.wordpress.com/?p=104

Currently attending the Libre Graphics Meeting in Wrocław - incredible congregation of bright people from vastly different areas. Well worth the visit.

Most of the external header guards now removed from the OOo source tree.