A string is a string and its all XML. As minimum I would expect to not find a complete XML data-structure in an ISO standard that 1) is such an implementation detail and 2) does define an own complex data-structure for just one single use-case that could have beem easily covered by an already used data-structure.

MSOOXML does exactly that. I was caught in surprise when discovering following snipped in an MSOOXML XML document;

<c:cat>
  <c:multiLvlStrRef>
    <c:f>Sheet1!$E$3:$G$4</c:f>
    <c:multiLvlStrCache>
    <c:ptCount val="3"/>
    <c:lvl>
      <c:pt idx="0"><c:v>Pass</c:v></c:pt>
      <c:pt idx="1"><c:v>Fail</c:v></c:pt>
      <c:pt idx="2"><c:v>NA</c:v></c:pt>
    </c:lvl>
    <c:lvl>
      <c:pt idx="0"><c:v>Result</c:v></c:pt>
    </c:lvl>
    </c:multiLvlStrCache>
  </c:multiLvlStrRef>
</c:cat>

Compared to the commonly used c:strRef element the c:multiLvlStrRef element defines a multidimensional list of strings. Something that could be easily covered by just using multiple c:strRef elements. But no.

When looking at the MSOOXML specifications we discover those whole rather complex structure is used for exactly one single time for one single use-case;

ECMA-376 page 4060

5.7.2.116 multiLvlStrRef (Multi Level String Reference)

 Parent Elements:
  - cat (§5.7.2.24); xVal (§5.7.2.235)

 Child Elements:
  - extLst (Chart Extensibility) §5.7.2.64
  - f (Formula) §5.7.2.65
  - multiLvlStrCache (Multi Level String Cache) §5.7.2.115

What I had to do was to implement code to parse all that and do exactly what the c:strRef element does. This pushed additional logic and work on consumers of that standard for no good reason. Worst is that this stayed undiscovered in Calligra for a long time and so we could, in some rather random cases, completely ignore categories in charts when importing Microsoft 2007/2010 documents.

Why oh why is that data-structure used? Why not reuse c:strRef like *ALL* the other parts of that ISO Standard do? Why duplicate the whole formula and cache logic? Why force consumers of that standard to special case exactly one single case rather then unifying this and removing a complete unneeded section plus a complete type-specification from the already rather large standard of >5000 pages?

A proper QA on that standard rather then pushing it in such amazing speed through an ISO fasttrack process would have cleaned up a lot of such cases is my believe. It would have decreased the burden for adoption and improved the overall quality.

Since changing such fundamental things afterwards, means after becoming an official ISO standard, is impossible to do within a maintenance life-circle with a patch release (something like the already published ISO OpenDocument 1.1, 1.2 or the still to publish 1.x releases after them) this has to wait for a long time and would introduce then backwards-incompatible data-structures. Looks as we have to stick now with such mistakes forever :-(

4 1

Our pretty cool Calligra Quality Dashboard lists 11 remaining release-critical blocker bugs that still need to be fixed till then.

Now is the perfect time to give the latest Calligra a try and report all your findings at our bug-tracker. Probably most interesting are serious data-lose issues on saving to our native OpenDocument formats, crashes and other major problems we can add to our top-priority list for either 2.4 or 2.5 which may finally be a silver-state candidate.

On a side-note it is rather interesting that we are in fact releasing 3 different versions of our suite more or less in parallel. The 2.4 desktop-edition mostly known as office suite for the KDE desktop, the Harmattan Office edition shipped together with the N9 and Calligra Active. Following the spirit of the work done on Plasma Active One Calligra is btw also already packaged and available for Mer.

Calligra is far ahead it's competition in this field. Building products based on the community-driven Calligra suite (or Calligra frameworks which would probably match more) is easy and can be done with little resources within very short time. That is a huge achievement we aimed for when starting working on KOffice version 2 lot of years back. An achievement we finally reached and we are able to prove to have reached and that today and now.

Gratulations to everybody involved in making that happen :-)

7 1

OpenOffice and KOffice (and the Maemo/Meego Office Viewer) both have ODF as their main file format. ODF is an open standard and this means exchanging data between these programs should be simple and lossless. To help the developers of these programs find differences in rendering of slides, I have written a program that loads a presentation and shows it as rendered by KOffice and OpenOffice.

As an added bonus, it also shows how these programs render PowerPoint files. PowerPoint files are converted to ODP first and then loaded into each of the two rendering engines. That gives four types of output:

• Converted by OpenOffice to ODP and rendered by OpenOffice
• Converted by KOffice to ODP and rendered by KOffice
• Converted by KOffice to ODP and rendered by OpenOffice
• Converted by OpenOffice to ODP and rendered by KOffice

You can see an example view in the screenshot and screencast below.

The code has been announced on the koffice mailing list.

Ogg Theora screencast of SlideCompare
Flash screencast of SlideCompare

0 0

OpenOffice and KOffice (and the Maemo/Meego Office Viewer) both have ODF as their main file format. ODF is an open standard and this means exchanging data between these programs should be simple and lossless. To help the developers of these programs find differences in rendering of slides, I have written a program that loads a presentation and shows it as rendered by KOffice and OpenOffice.

As an added bonus, it also shows how these programs render PowerPoint files. PowerPoint files are converted to ODP first and then loaded into each of the two rendering engines. That gives four types of output:

• Converted by OpenOffice to ODP and rendered by OpenOffice
• Converted by KOffice to ODP and rendered by KOffice
• Converted by KOffice to ODP and rendered by OpenOffice
• Converted by OpenOffice to ODP and rendered by KOffice

You can see an example view in the screenshot and screencast below.

The code has been announced on the koffice mailing list.

Ogg Theora screencast of SlideCompare
Flash screencast of SlideCompare

10 0

Click to enjoy the show

Apaprently, Qt Lighthouse was used for porting the QtGUI module.

From the Author:
"You don't have to write your own jni<=>java connections, all the magic is done from java by com.nokia.qt package, take a look to examples/android/QtTest/src/com/nokia/qt"

I can only say, Kudos to BogDan! And of course I still cannot believe how flexible Qt architecture is. I bet we can expect more ports this year.

Dig for more details... and leave what you discovered in the comments below.

0 0

Click to enjoy the show

Apaprently, Qt Lighthouse was used for porting the QtGUI module.

From the Author:
"You don't have to write your own jni<=>java connections, all the magic is done from java by com.nokia.qt package, take a look to examples/android/QtTest/src/com/nokia/qt"

I can only say, Kudos to BogDan! And of course I still cannot believe how flexible Qt architecture is. I bet we can expect more ports this year.

Dig for more details... and leave what you discovered in the comments below.

10 2

QML allows one to write flashy applications with little code. My first QML program is a metronome. The N900 has a metronome program but it is rather boring. It does not look and feel like a real metronome. So I set out to write one in QML and managed to do so in 56 lines of QML. The interaction is simple: tap it to toggle between on and off and slide up and down to move the cross-bar on the metronome which will adjust the tempo in the range 40 to 208 beats per minute.

Without further ado here is the code. You can run it in qmlviewer. Two things are lacking at the moment: a nice SVG image of a metronome and of course the ticking sound. I am keen to find out how to make the metronome produce sound to make it useful.


import Qt 4.6

Rectangle {
width: 640
height: 480

Rectangle { // metronome bar
id: bar
x: 320; y: 100; width: 30; height: 300
color: "#aaaaaa"
property double tempo: 120

Rectangle { // weight on metronome bar that determines the tempo
x: -15; y: parent.tempo; width: 60; height: 30
color: "#aaaaaa"
}

transformOrigin: Item.Bottom
rotation: 0
rotation: SequentialAnimation {
id: anim
repeat: true
NumberAnimation { to: 35; easing: "easeInOutQuad"; duration: 60000/bar.tempo }
NumberAnimation { to: -35; easing: "easeInOutQuad"; duration: 60000/bar.tempo }
}
}

Text { // tempo indicator
x: 0; y: 0;
font.pointSize: 24; font.bold: true
text: bar.tempo
}

MouseRegion { // logic for tempo tuning and turning metronome on and off
anchors.fill: parent
property int start: -1
property bool moved: false
property bool wasrunning: true

onReleased: { // start or stop the metronome
anim.running = (moved) ?wasrunning :!wasrunning
bar.rotation = 0
start = -1
}
onPositionChanged: { // adjust the tempo
moved = start != -1
wasrunning = (moved) ?wasrunning :anim.running
bar.tempo += (moved) ?(mouse.y - start) :0
bar.tempo = (bar.tempo > 208) ?208 :bar.tempo
bar.tempo = (bar.tempo < 40) ?40 :bar.tempo
anim.running = false;
bar.rotation = 0
start = mouse.y
}
}
}

0 0

QML allows one to write flashy applications with little code. My first QML program is a metronome. The N900 has a metronome program but it is rather boring. It does not look and feel like a real metronome. So I set out to write one in QML and managed to do so in 56 lines of QML. The interaction is simple: tap it to toggle between on and off and slide up and down to move the cross-bar on the metronome which will adjust the tempo in the range 40 to 208 beats per minute.

Without further ado here is the code. You can run it in qmlviewer. Two things are lacking at the moment: a nice SVG image of a metronome and of course the ticking sound. I am keen to find out how to make the metronome produce sound to make it useful.

12 1

Catalog name:

Maemo Extras-devel

Web address:

http://repository.maemo.org/extras-devel

Distribution:

fremantle

Components:

free

Then the application 'freoffice' will be available in the category 'Office'. The install is 9 megabytes.

With the viewer, you can open multiple files at once, open office documents from your e-mail, search in office files and copy and paste from your documents. A very nice feature is the ability to give presentations with the phone. Here are some screen shots of the viewer running on the N900.

The code for this viewer is available in the KOffice repository. New releases of the viewer will be uploaded to the repository as KOffice progresses towards version 2.2.

The viewer has a simple user interface and responds quickly to user input such as page changing and scrolling.

25 2

Catalog name:

Maemo Extras-devel

Web address:

http://repository.maemo.org/extras-devel

Distribution:

fremantle

Components:

free

Then the application 'freoffice' will be available in the category 'Office'. The install is 9 megabytes.

With the viewer, you can open multiple files at once, open office documents from your e-mail, search in office files and copy and paste from your documents. A very nice feature is the ability to give presentations with the phone. Here are some screen shots of the viewer running on the N900.

The code for this viewer is available in the KOffice repository. New releases of the viewer will be uploaded to the repository as KOffice progresses towards version 2.2.

The viewer has a simple user interface and responds quickly to user input such as page changing and scrolling.

0 0

Apart from using the N900 for serious things, I've also done a bit of playing with it. Qt has a famous OpenGL demo that shows the Qt logo in a QGLWidget. Instead of controlling the rotation of the object with the scrollbars, the adapted version uses the accelerometers in the device to move the logo.

This was a simple adaptation: reading the accelerometers is simple:

Nokia-N900-41-10:~# cat /sys/class/i2c-adapter/i2c-3/3-001d/coord
36 -18 -1134

The application source and a debian package for the N900 are now available.

Here is a screenshot of five running instances in the application overview. The five logos all move if you move the phone.

Perhaps a Qt on Maemo guru can adapt this program to be a desktop widget with a transparent background.

0 0

Apart from using the N900 for serious things, I've also done a bit of playing with it. Qt has a famous OpenGL demo that shows the Qt logo in a QGLWidget. Instead of controlling the rotation of the object with the scrollbars, the adapted version uses the accelerometers in the device to move the logo.

This was a simple adaptation: reading the accelerometers is simple:

Nokia-N900-41-10:~# cat /sys/class/i2c-adapter/i2c-3/3-001d/coord
36 -18 -1134

The application source and a debian package for the N900 are now available.

Here is a screenshot of five running instances in the application overview. The five logos all move if you move the phone.

Perhaps a Qt on Maemo guru can adapt this program to be a desktop widget with a transparent background.

1 0

But after several more hours of hacking and trying to figure out how transparency works in X11, I even managed to get nice translucent applets. Also I figured out how to hook up the normal maemo5 widget configuration system to display the correct configuration dialog when you click on the configure button on one of these plasmoids. So with in the end maybe 20 lines of code, I got a rather good working implementation that makes it basically possible to have any plasmoid you might have on your normal kde desktop, also on your maemo5 home screen. One (somewhat major) problem with the current implementation is that it is not possible to resize widgets, but as far as I can tell that is mostly a limitation of the maemo5 desktop widget system, so I'm not sure if there is anything I can do about it from my side.

9 0