Some like to make a joke of OpenOffice.org coming with around 8 different string-implementations and comparing that with what we are having in Calligra with QString. But when we worked back then in OASIS to form what later became the ISO OpenDocument standard we left such implementation details out.
Planet maemo: category "feed:c7e5726454066386af96dd3c47820d51"
As Andreas note we are rather close towards Calligra 2.4 which will be the very first release of the Calligra Suite.
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 :-)
Rendering slides is a complicated business. Slides can contain tons of different features just like webpages can. People expect that presentations look the same in different programs. Perhaps not pixel-perfect but very similar nevertheless.
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
Rendering slides is a complicated business. Slides can contain tons of different features just like webpages can. People expect that presentations look the same in different programs. Perhaps not pixel-perfect but very similar nevertheless.
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
Remember the last call? After less than 5 months we can see apparent success, and a lot more than a proof of concept.
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.
Remember the last call? After less than 5 months we can see apparent success, and a lot more than a proof of concept.
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.
Tonight I could not attend band rehearsal so I used the time to play with the new QML language. There is a nice tutorial online and a good screencast.
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
}
}
}
Tonight I could not attend band rehearsal so I used the time to play with the new QML language. There is a nice tutorial online and a good screencast.
