A gentle reminder: please occassionally check back on bugs you've reported and resolve them if they have been fixed in recent versions.

Sometimes we developers fix bugs but forget to resolve them ourselves; sometimes bugs are fixed by newer versions of other software we depend on; sometimes bugs are fixed as consequences of other fixes.

So help us out and resolve your own bugs when possible.

Thanks.

Kubuntu has packages for 4.8 bringing updates to Plasma workspaces and a load of KDE Applications.

To quote a nice user posting on kde-devel

"I upgraded to Ubuntu's Precise Alpha 1 a few days ago. After the upgrade completed, I tried out KDE 4.8 RC 2. It worked great until the final release of KDE 4.8 Final. KDE 4.8 Final is even better than the RC!"

or later in the same thread

"KDE 4.8 is rocking for me too.Using the Kubuntu PPA's on Sandy Bridge system and it's just lightning fast to do anything. "

There are job offers floating sporadically on planetkde so I guess this one would fit too especially that there are many related technologies involved.

You may remember my story about some crazy Qt device. Now there is apparent expansion both vertically and to other types of high-end devices, so:

This offer is for permanent jobs in Warsaw office, rather for Polish speakers. More on my Polish blog.

I often get asked about junior jobs in Calligra Words. I ususally say no, but now I actually have some.

The reason I say no is that there are no easy jobs left, and so jobs would take much more of my time than I would like. And I also don't want to purposely leave unfinished stuff behind.

Anyway here is a brief synopsis of the junior job: We have code that applies bold, italic etc, and it works, except it doesn't respect table cell protection. The job consists of repeating an example I've already made to the application of bold, italic and several other similar things.

It's pretty easy copy,paste,edit and will give you practical experience with the visitor pattern

You are a student, you would like to contribute to an Open Source project, and get paid for it ?

Then I may have something for you.
At my job at Fraunhofer in Kaiserslautern we are using the CDash testing server for testing the software we develop - various different High Performance applications for Linux clusters.

We'd like to extend the features offered by CDash, especially with regard to performance monitoring (so we can check our software actually stays high-performance). There are more things we'd like to have in CDash, and if you are interested, you can probably also come up with ideas how to make CDash rock even more. :-)
Of course everything you develop for CDash will be upstreamed (as long as the maintainer agrees, I'm in good contact with him).

So, if this sounds interesting to you, if you are good with LAMP, then get in touch with me: neundorf AT kde.org.

Alex

P.S. there are also regular software development jobs available (C++, Linux, Qt, distributed systems), but they are not in an Open Source project. If you are interested anyway, feel free to contact me.

Since Monday, a feature I have been working on for quite a while has been merged into Calligra master. This is the style selection combo box.
Until Monday, the style selection widget was a home brewed widget based on QFrame. It wasn't optimal and that is a British understatement. Now this widget is still home brewed, but based on a QComboBox.

As this is my first blog here, a bit of introduction is probably due. My name is Pierre Stirnweiss, I am french and currently lives in Munich. I have been using Linux for longer than I care to admit and have been coding for about 4-5 years now, starting on KOffice. I am now a fellow member of the Calligra team.

Now to the point:

On this first screen shot you can see two of these combo used (on the right hand side in the "Text Editing" docker). What you can see is that there is a paragraph style selected (Standard) and that no special character style is applied at the current cursor position.

On this screen shot you see the drop down menu of the combo. The items in the list provide a preview of each style. Here you can spot a small button on the currently hovered item. This button allows to call the full blown Style Manager where you'll be able to change the style options. Also of interest, the character style preview is shown "on top" of the currently selected paragraph style. This means that a character style defining only the bold property, will be previewed with the other properties (like font, italic, ...) of the current paragraph style.

If the style name cannot fit in the preview (because the font is too big for example), it will be scaled down. The real font point size is shown:

On this screenshot, the cursor is supposed to be in the "some bold words" part. You'll notice a green + sign in the character style combo. This has two purposes. The first is to notify that the style under the cursor has some modified properties. In that particular case the bold property is different from the defined one in the style. The second purpose is to allow a quick creation of a new style. Pressing the + button will bring you:

Here you can enter the name of the new style. Validating the name will create a style based on the text properties under the cursor.

Now that the functionality has been roughly presented, I must also give credit where credit is due. This combo implementation is to a very large extend inspired by the KComboBox, KLineEdit classes. The + button functionality derives directly from these classes.
As for the drop down menu and the style manager button, this is implemented using a custom delegate.

That's it for now. Please try out the next beta and let us know what you think.

It's been quite a while since I last wrote a blog post, but it's not because I haven't been coding, in fact quite the opposite. The Qt opengov project is finally underway and I've been doing quite a lot of work on the various SSL classes. I'm now an official Qt approver, so as you can see the process of getting non-nokia developers the ability to commit to Qt is working.

In Qt 4.x and currently in Qt5 even though the various QSsl classes provide an abstraction from the underlying SSL implementation, there is only one backend and it uses openssl. I recently made a change that means we can add new backends during the Qt5 life time by separating the concepts of SSL support from the availability of SSL - of course this doesn't change anything if openssl is the only game in town.

Over the last couple of weekends, I've been investigating GnuTLS as a
potential implementation that could form the basis of a second backend. I started with the easy part - handling X.509 certificates, and last weekend managed to implement some code that showed that we could implement this part of the Qt API using GnuTLS. I did hit some issues of course, but most were minor. The GnuTLS maintainer Nikos Mavrogiannopoulos has already fixed the minor documentation issues I spotted, and has even implemented a couple of features that I found were missing - definitely a sign that this library is being actively maintained I think you'll agree.

Today I attempted the more challenging task of trying to make GnuTLS work through a QTcpSocket. This integration is essential for using the library in Qt since without it features such as proxy support etc. would not be available - it really is a 'must have'. As you might guess from the fact I'm bothering to blog about it the results were positive, so let's take a look.

What I've done for this prototype is implement a QObject that provides the same basic outline as a QIODevice subclass. In order to keep things simple, I haven't yet tried to make something that is tied to that specific API at this point. I've also not tried to integrate this into QSslSocket, instead this code aims to demonstrate that doing so will be feasible in future.

The API I've implemented is reasonably close to what QSslSocket offers, the header file should make it clear that most of what you'd expect is there:

class SslSocket : public QObject { Q_OBJECT public: SslSocket(QObject *parent=0); ~SslSocket(); QByteArray read(qint64 maxsize); public slots: void connectToHost(const QString &hostname, int port); void startHandshake(); qint64 write(const QByteArray &data); signals: void handshakeComplete(); void readyRead(); void error(); private slots: void dataReceived(); private: void setupSession(); void handshakeInternal(); ssize_t readInternal(void *buffer, size_t length); ssize_t writeInternal(const void *buffer, size_t length); ssize_t writeVectorInternal(const giovec_t *iov, int iovcnt); static ssize_t read_callback(gnutls_transport_ptr_t transport, void *buffer, size_t length); static ssize_t write_callback(gnutls_transport_ptr_t transport, const void *buffer, size_t length); static ssize_t write_vector_callback(gnutls_transport_ptr_t transport, const giovec_t *iov, int iovcnt); SslSocketPrivate *d; };

Now you've seen the header, let's take a look at the implementation. The first method we'll look at is the one that performs the initial setup of our SSL session. This happens before we even attempt to send any data to the server since once of the things we're going to do is change the way data is sent to run it via QTcpSocket:

void SslSocket::setupSession() { qDebug() << "Initialise client session"; // Setup the trust store gnutls_certificate_allocate_credentials(&d->x509cred); gnutls_certificate_set_x509_trust_file(d->x509cred, "/etc/ssl/ca-bundle.pem", GNUTLS_X509_FMT_PEM); // Configure the session gnutls_init(&d->session, GNUTLS_CLIENT); gnutls_credentials_set(d->session, GNUTLS_CRD_CERTIFICATE, d->x509cred); const char *err; gnutls_priority_init(&d->priority_cache, "NORMAL", &err); gnutls_priority_set(d->session, d->priority_cache); // Setup the transport functions to use QTcpSocket gnutls_transport_set_ptr(d->session, this); gnutls_transport_set_pull_function(d->session, read_callback); gnutls_transport_set_push_function(d->session, write_callback); }

The first thing this method does is setup the trust store, and point it to the location of the CA bundle on my opensuse 12.1 system. In fact, this is a total waste of time, since verifying the certificate isn't something I've implemented yet! The next part is rather more useful however, we initialise a session and tell GnuTLS that we're acting as an SSL client. After this, we set the priority of the various ciphers etc. that are available. This step seemed unimportant, but I discovered that if you fail to do it then rather than using a sane default, GnuTLS dies with an internal error. The last setup step we do is to tell the library that we want to use our own functions to send and receive data rather than using the built-in ones.

For each of the read and write functions, we provide a callback. This is a static method (since a pointer-to-member-function is a no-no for reasons I won't go into). Our static method then calls the member function that implements our callback:

ssize_t SslSocket::read_callback(gnutls_transport_ptr_t transport, void *buffer, size_t length) { SslSocket *self = static_cast<SslSocket *>(transport); return self->readInternal(buffer, length); } ssize_t SslSocket::readInternal(void *buffer, size_t length) { qDebug() << "readInternal, length" << length << ", available" << d->socket->bytesAvailable(); if (d->socket->bytesAvailable() < qint64(length)) { gnutls_transport_set_errno(d->session, EAGAIN); return -1; } return d->socket->read(static_cast<char *>(buffer), length); }

As you can see the static function simply casts the user data pointer (which we provided using gnutls_transport_set_ptr earlier) to our class, then calls the appropriate method. The read implementation simply sees if we have enough bytes in our socket's buffer to satisfy the request, and if not tells the library to try again. If we do, then naturally we read the data. The data we need can only become available when the eventloop is running since that's when QTcpSocket performs its data transfers. If we simply retried immediately then
we'd see no more data than we did during our first attempt.

The write function is similar, but since QTcpSocket has buffering of its own we can simply perform the write as requested. My real implementation supports a slightly more complex form of the write function that can process requests to write several blocks of data at once, but the basic concept is the same.

In order to allow the retry behaviour I mention above, there's a simple state machine. The SslSocket has the following basic states:

enum State { Disconnected, Connecting, Handshaking, Encrypted };

If new data is received then we look the state and retry the relevant
operation as follows:

void SslSocket::dataReceived() { qDebug() << "dataReceived() state is " << d->state; if (d->state == Handshaking) { handshakeInternal(); } else if (d->state == Encrypted) { emit readyRead(); } }

The handshakeInternal() method is the one that actually performs the SSL handshake, and as you can see if we're in the appropriate state then we retry each time more data is received. The actual implementation is pretty simple:

void SslSocket::handshakeInternal() { qDebug() << "start handshake, state is" << d->state; int result = gnutls_handshake(d->session); qDebug() << "shake result" << gnutls_strerror(result) << result; if (result == 0) { qDebug() << "handshake completed"; d->state = Encrypted; emit handshakeComplete(); } else if (gnutls_error_is_fatal(result)) { qDebug() << "fatal error in handshake"; emit error(); d->socket->disconnect(); d->state = Disconnected; } }

As you can see, once we get a real result from the handshake (ie. one that can't be solved with more data) then we emit either the handshakeComplete() signals or the error() signal and update the state of the SslSocket. If the handshake is completed successfully then we can now send and receive encrypted data.

The read and write methods are similar. In both cases, we need to consider the possibility that we need to retry (indicated by either an interrupted, or again error). The implementations are as follows:

QByteArray SslSocket::read(qint64 maxsize) { QByteArray buffer; if (d->state != Encrypted) { qFatal("Write before encrypted is not supported yet"); return buffer; } buffer.resize(maxsize); // ### This could get pretty big! ssize_t result; do { result = gnutls_record_recv(d->session, buffer.data(), maxsize); } while( result == GNUTLS_E_INTERRUPTED || result == GNUTLS_E_AGAIN ); buffer.truncate(result); return buffer; } qint64 SslSocket::write(const QByteArray &data) { qDebug() << "write"; if (d->state != Encrypted) { qFatal("Write before encrypted is not supported yet"); return -1; } ssize_t result; do { // ### It's possible that this could fail due to the need to read some data // for example if a renegotiation is underway. Not sure. result = gnutls_record_send(d->session, data.constData(), data.size()); qDebug() << "write result" << result; } while( result == GNUTLS_E_INTERRUPTED || result == GNUTLS_E_AGAIN ); return result; }

In order to test this, I wrote a very simple class that will perform an HTTP GET and read the response. The result is that we can can connect to an HTTPS server and see the root page - not very exciting I guess but a sign that everything is working!

GetSlash::GetSlash(SslSocket *sock) : QObject() { this->sock = sock; connect(sock, SIGNAL(handshakeComplete()), this, SLOT(start())); connect(sock, SIGNAL(readyRead()), this, SLOT(gotData())); } void GetSlash::start() { sock->write(QByteArray("GET / HTTP/1.0\n\n")); } void GetSlash::gotData() { QByteArray result = sock->read(2000); qDebug() << result; }

Finally there's a basic main() function that ties all this together, and a little bit of code to log what's going on. The end result is that I now feel confident that we could implement a working backend for QSslSocket etc. using GnuTLS without too much trouble.

I'll add the code to my normal qt-examples repository later, but if anyone needs it (or earlier experiment experimenting with the certificate APIs) then just let me know.

EDIT: The code is now available here https://gitorious.org/qt-examples/qt-examples/commit/40e57647242079745c46d84e15d92f2093af300f

Have anyone seen user jhk or know what his real name or email is

If so then please leave a note either here or on irc #calligra

He has started some work on Calligra Words that I'm really interested in and I havn't seen him since middle of december.

As most of you are probably well aware, since quite a while it is not very hard to write Qt applications to run on Android devices. A couple of weeks ago we at KO GmbH decided to look into how hard it would be to get KDE applications to run, and more specifically, if it would be possible to run Calligra with one of its mobile UI's on an android device.

So after some (sometimes frustrating) hacking, I've got the first results: Calligra Mobile running on an android tablet. There are still lots of rough edges, and not everything works correctly, but as you can see in these screenshots, it does actually run and work. To get to this point I had to make some rather ugly hacks though to work around some of the android limitations.

D-Bus
First of all, I had the problem that android does not come with dbus. Or, to be more precise, dbus is only used internally in android as an implementation detail and 3rd party applications should not try to use it. Because of this lack of d-bus, I basically ifdef'fed out all d-bus usages in the parts of kdelibs that I needed to run Calligra. I wasn't too worried about lack of dbus causing actual issues with Calligra, since from for example the Documents application on the Nokia N9 (which uses Calligra internally) I knew that Calligra doesn't really need any of the runtime deamons/processes that a KDE application generally tries to communicate with via dbus (none of the kde deamons are present on the N9).

KSyCoCa
The second major problem (and one I couldn't just get rid of by ignoring it) was figuring out how to get KSyCoCa to work. Calligra is heavily plugin based and relies on the ksycoca functionality to determine what plugins are available, and which are needed to display different filetypes. What I'll probably end up doing (and what is also basically what the N9 does) is include a prebuilt ksycoca file in my package. I tried various ways of getting kbuildsycoca4 to run nicely when needed (one hack even uglier than another), and none of them really worked nicely. Also I don't think it is really too big of a loss to not be able to install extra plugins outside of the application package for a mobile version of Calligra.

DBus and KSyCoCa are really the two big problems I had while getting to the point I am now. To get it all to work relatively smoothly I of course had lots of other small things to worry about:

• Removing SOVERSION's from libraries. The way necessitas is designed it kind of fails if your libraries have a SOVERSION set in CMake.
• Renaming plugins from foosomething.so to libfoosomething.so. I'm still not sure if it is an android limitation or a necessitas specific thing, but only libraries that start with "lib" seem to end up installed where I can dlopen them.
• I'm currently including $prefix/share as part of the "assets" of my android package, this works fine and even somewhat transparantly with the way necessitas wraps this in a QAbstractFileEngine, but since these are not real files on the actual filesystem, I had to patch KStandardDirs to use QDir/QFile instead of direct filesystem access. A cleaner solution might be to extract all the files to some place in the filesystem first, but that would mean duplicating them, since they would also still be in the .apk.
• Calligra Mobile used to (unnecesary) link against libQtOpenGL, this caused Necessitas to pick the OpenGL graphics engine, which unfortunately seems to be very buggy. After removing this dependency it reverted back to the raster engine and lots of things suddenly started working.

The current state of my code can be found in the following repositories:
git://anongit.kde.org/scratch/mkruisselbrink/calligra-android-build.git
This repository has a bunch of scripts I use to build kdelibs and calligra for android. Lots of hardcoded paths, so don't expect it to actually work for you. Also heavily based on the android build scripts for Quantum-GIS. The existence of those scripts helped me a lot to get KDE to build.

git://anongit.kde.org/clones/kdelibs/mkruisselbrink/android.git
The android branch in this repository has all my current hacks to kdelibs to make it build&run on android. Here also lots of hardcoded paths around as well as a whole bunch of ugly hacks and things that don't realy work yet.

git://anongit.kde.org/calligra.git
In the mobile-android-mek branch you can find the changes I made to calligra to make it run on Android. Nothing too spectacular here.

I finally got around to running vttest [1] in Konsole (4.8/master) [2].

The most noticeable issue is the the console resizing commands don't work [3].

A list of other issues:

• 49 - The line bold doesn't look correct (OSX); the line underscored has no underline
• 54 - Set 0 (SI/SO) bottom line differs (OSX/Linux have different graphics).
• 56 - An extra "This is another line" normal size is displayed
• 58 - An extra "This is another line" normal size is displayed
• 60 - An extra "This is another line" normal size is displayed
• 62 - An extra "This is another line" normal size is displayed
• 63 - The outer box frame doesn't connect all the way around
• 64 - The outer box frame doesn't connect all the way around
• 76 - Control keys didn't work: @ ^ _ (OSX)
• 87 - Graphics character set - bottom line differs
• 93 - The "by one." line has "Push " being overwritten
• 99 - The "by one." line has "Push " being overwritten

None of these are terrible although the resizing issue really needs to get fixed!

[1] http://invisible-island.net/vttest
[2] http://www.kermitproject.org/vttest.html
[3] https://bugs.kde.org/show_bug.cgi?id=238073

(this is a continuation of the Fruits of Calligra Suite Sprint #2 series)

2012 started and I am still summarizing ideas from the Sprint. Today an integration idea: Office Forms for Calligra apps.

Forms are useful for improving data entry. Alternatives like entering data into spreadsheet cells can be too error-prone or tedious for the end-users. Forms reuse the GUI paradigm that is most probably already known and accepted by the user.

First, it is good to know forms were historically handled in popular office software. Extra functionality in MS Office or OpenOffice/LibreOffice still tend to be added using form elements (widgets) like buttons directly embedded into the document.

OpenOffice with embedded invoicing functionality. Note the buttons floating within the spreadsheet area.

Quick look from the bird's-eye view shows multiple issues.

There is clear escape from the document paradigm to the application paradigm, thus mixing the document and the app functionality can be observed. Not only there is no model-view approach. On the plus side is that the user can just open the document which is a self-contained file, easy to manage and transmit. But this comes at cost. To start fresh with a clean document, the whole original document with the GUI and business logic code is just copied. This is not a surprise as the documents with forms are distributed as document templates. Because of that copying there is no organized way to upgrade the GUI and the code when the authors provide a new version.

And let's not forget: users are gernerally unable to notice which part of the GUI comes with document and which is provided by the application itself. So there is a break in the familiar GUI paradigm. User may accidentally move or delete a button. The form elements affect the presence of printouts. Various document formats deal with this by employing whole set of workarounds like locking position and modification of a form widget and excluding them in printouts. This further contributes to complexity of the solution.

So at the Calligra Sprint instead of drafting a set of workarounds I outlined idea for the solution (see the mockup below):

• Enable creation of flake tool-compatible side panes that could be then switched on by user demanding custom functionality with a few mouse clicks. Documents that demand given functionality would be able to show/hide the panes too.
• Plugin approach. Plugins could be deployed as single file bundles, versioned and separated from documents. Business logic would use JavaScript (via QtScript) to fully escape from platform dependency and to address major security issues. This approach blends with the idea of including JavaScript APIs for document integration generation and data visualization within the Calligra Engine.
• Since ODF allows to embed custom object files, the plugin bundles could be embedded into the files for easier deployment. For this some kind of fall-back to the version embedded in document would be needed. But once installed at app-level, that installed version would be used as long as version, vendor, whatever matches. Side-by-side installation of various versions would be a plus.
• GUI builder and extra runtime functionality may be delivered with the help of Kexi Form designer, which is a higher-level data-oriented reimplementation of Qt Designer in development since 2004.
• Effect: the document is not cluttered, stays just as a document. The scripted functionality can be bind to the application's structure at runtime instead of injecting into document structure directly.

A mockup of Calligra Tables with embedded invoicing functionality. The sample custom form has been moved to a separate sidebar.

There is extra rationale. It was never too realistic for the Calligra project to support VBA/StarBasic and forms. Even StarBasic perceived as a drop-in replacement for VBA never achieved compatibility and continued its life as a distinct scripting environment. Only simpler VBA solutions are similar under StarBasic. Even assuming extremely good will, achieving reasonable compatibility is very hard. So VBA is Windows+MS Office-only. Microsoft itself has admitted this at least twice: by giving up with delivering VBA for its Mac Office, then it skipped scripting topics in its MSOOXML specifications by declaring scripting as implementation-defined area. That was rather honest move.

Then there is question about the ODF. Currently reusing any partial support for scripting/forms defined by ODF is not worth the effort in my opinion. While working on applications we start with requirements and usability. Reusing incomplete standards here is nice-to-have but at this stage definitely it cannot have higher priority than practicality and usability of the solution.

This does not mean I am ignoring importance of standards. As the case of OpenFormula shows, ODF is vital in its iterative approach especially when the problem and the scope is well defined and rather narrow. So users would eventually see some complete standard in the area of forms going behind the level of XForms. Cooperation is getting more possible after the collapse of the controlled corporate structures of OpenOffice.org (but let's appreciate the huge contributions of Sun) and emerging of LibreOffice as a free software project.

First, I've changed the branches that are being built on build.kde.org to reflect the branching of 4.8.

Second I've incorporated a build of Qt 4.8 branch that is triggered once a week to keep up with fixes there.

Third I've tried to get a build of Qt 5 up and running also, however this is where I've hit some bumps. I've been unable to get Qt 5 to build and as such not all other jobs are working :(

According to the FAQ the error I was first hitting can be avoided by building the submodules after building and installing qtbase, however then I get build errors in QtWebKit and if I try to omit that module somehow it is getting dragged back in by something yet to be determined.

So if anyone has any clues how to get a clean build of Qt 5 working please leave a comment.

Earlier this year Jono mused about getting older. Ah bless, I remember him when he was just a whippersnapper promoting KDE at a warehouse in Birmingham.

Today is my turn to reach my 30s and I had it all planned out. I was going to be living on a tropical island with loads of awesome beaches, reliable and warm surf to learn how to use a waveski (sit on top canoe kayak for surfing) while speaking fluent French and drinking ti'punch (rhum agricole, lime, and cane syrup). I spent a lovely month there meeting new people, trying new things, working in the sunshine with a swimming pool a meter away for when something is compiling.

But I did not count on one problem, the French drive on the wrong side of the road. I don't remember the accident but I remember a couple of days in hospital being like a dream drifting in and out of consciousness, speaking (what I thought was) surprisingly good French to the doctors. After three days they sent me home in a taxi with my MRI scan results, which being concussed I left in the taxi. Fortunately I have an excellent family and my dad flew out there to sort out the status with the polis (who had got a story from the guy who crashed into me that sounded like he had learnt his physics from car chase films) and the car rental company (that car won't be on the roads again) and the canoe club (nice kit rescued from the smashed up car) and took me on a flight back home.

The lovely NHS (the independent Scottish one, not the about-to-be-privatised English one) had GPs and MRI scanners and eye specialists look at me. My eyes are very squint, muscle damage in one means the image is at a different angle in each of the eyes and I can only look out of each eye one at a time. The doctors expect this to get better over the next weeks to months. My brain feels a bit woozy, like I've been sipping low quality beer. I'm feeling more lethargic then usual and because everyone tells me to rest I don't want to set my alarm clock early so have no way to get back on European time, a quick prescription for metacinin should fix that (surprisingly hard to get hold of, in most countries it's not even a prescription thing).

So Kubuntu has been a bit slow to get started and we missed the first alpha (testing ISOs can be boring but this time I really was comatose) for the precise release but all the packages got merged and we have bits like a KDE SC and Calligra betas packaged. I've a long todo list which should keep me busy next year.

And I very much love my life, excellent family, top friends, satisfying physical hobby (nearly done building the east wing to the canoe club) and excellent awesome intellectual one which I'm fortunate enough is also my job (lets see if Kubuntu can help Plasma Active do that world domination thing in 2012).

I'm looking forward to my 30s. Happy Riddellmas and have a great hogmanay to start 2012.

FYI:

I just added some symbolic links on the api.kde.org machine to make accessing the 'stable' and 'unstable' dox a little easier.

So now stable points to 4.7 and unstable points to 4.8.

For example:
http://api.kde.org/stable/kdepimlibs-apidocs is the url for the stable kdepimlibs 4.7
http://api.kde.org/unstable/kdepimlibs-apidocs is url for the upcoming kdepimlibs 4.8

Might want to keep this in mind when putting links into your documentation. for example.

Now I need to remember to move those symlinks when a new release comes along

(this is a continuation of the Fruits of Calligra Suite Sprint #2 series)

You don't need to become a seasoned web developer to know the value of styling documents with the CSS. This Sunday the technology turns 15 since its initial release.

We describe presentation semantics separately of document (or data in general) and this makes us feel empowered as professionals. More often than not when we look over the shoulder of an inexperienced user who clicks BOLD, ITALIC in an office suite, playing with font size combo box and what not, we feel overwhelming urge to say "wait, you can do this so much easier".

And then when we start spreading the document styles religion, you know what? That is not thought-out.

Read on to see why.

The reason is both as simple as unnoticed by many. For years we have been operating in documents world without any equivalent of CSS in major office apps. (Sure, some of you would find some rare or forgotten counter-examples and challenge me but I said "major office apps" and I don't mean DTP apps)

Basically NONE of the apps employed Document Themes, as I call CSS equivalent in documents, abstraction over document styles. Until 2005.

Then it all started for many casual users. In January 2005 Apple has started its iWork suite:

[..] Both Pages and Keynote 2 take full advantage of the advanced typography and graphics engine of Mac OS X, are seamlessly integrated with iLife '05. They include a collection of themes and templates that make it easy to produce stunning results in minutes.

iWork's spreadsheet with a theme applied

Shortly after (haha...), in 2007 Document Themes and Quick Styles appeared in a new MS Office. Quoting after this good and generic Wikipedia description:

"Microsoft Office 2007 places more emphasis on Document Themes and Quick Styles. The Document Theme defines the colors, fonts and graphic effects for a document. Almost everything that can be inserted into a document is automatically styled to match the overall document theme creating a consistent document design." [..]

Selectors for theme colors in MSO 2007 separated from standard colors (two different themes)

Theme-aware font picker in MSO 2007 separated from ordinary font list

It is good to know that Themes are more than just sets of styles, possibly saved in a template. Quoting after office.com blog:

[..] "Themes are simply a new level of abstraction available to Styles. Specifically, Themes let you to use variables instead of constants when you specify the properties within a Style. For example, let's say I'm creating a new Style called "Tea," and I want to specify the color property.

With the introduction of Themes I have two choices:

• make the color absolute (ex. green)
• make the color relative (ex. Accent 3).

If I choose the former, Tea's color won't be affected when I change the Theme of my document. If I choose the later, Tea's color will be affected when I change the Theme of my document. This comes in handy when you want to make a compelling and consistent change to the overall look and feel of your document in a few clicks."

Document themes selector in MSO 2010

Yes, most of the times you want these features in any app that create rich content. As in many other aspects, good defaults make our work easier. Back in 2007 MS added Document Themes support to seven its apps in one go, including the database and project management apps. (They also added handy Quick Styles but this is another story)

To know how widely a document theme can be applied across applications, imagine a theme for table with border styles, cell colors and padding. The same theme can be used by a spreadsheet document and tables presentation and finally in a wordprocessor's table. They would be thus visually connected. We're getting close to DTP world but without alienating average users.

What's in Open Document Format
To my knowledge ODF does not codify sets of connected styles what would be a building block for document themes. The only related term is styles inheritance which is used in single families, e.g. Heading styles 1, 2, 3, and so on can inherit from common Heading style, for example to share common font. But for example there is nothing that restricts or suggests number of fonts used in a document or template.

In no way this is critics of ODF. Perhaps themes would appear in next generation of ODF thanks to demand from the community and community involvement. By then applications have to handle and define themes on their own. It would be good to have single definition, probably not the one hard-coded into MSOOXML formats but at least similarly functional. I will be polite enough saying that the way how MSOOXML defines themes does not look like how standard should look like.

But we have templates!111!!!
While document templates are medium for storing styles, they do not replace document themes. Using template-like technology for styling to replace the Internet's HTML/CSS technology would be like deploying pre-formated HTML documents with placeholders for user content without style/layout/content separation. Document templates are very useful when they define content, let it be invoice, formal letter or any document with predefined structure.

Usage of document templates appears to be at least problematic when we need to start with empty documents because the only explicit value of template documents carrying no content are styles embedded inside. But documents do NOT inherit definitions from a template. Documents are just static copies of one selected template or another.

Even existence of extra filename extensions (ott is a template for odt, etc.) is a mere naming sugar used mostly by OS shells to make easy distinction between opening document and copying document (creating document from template). And finally, changing style definitions in a template will only change styles of FUTURE documents that will be based on that template. These semantics remember the release date of the Terminator 2 movie and is very much unlike CSS.

Users are confronted with a case when some styles reside in one document and other set of styles is a part of another document or template. So once again there is no real equivalent of CSS. Through the years various Style Organizer dialogs have been implemented in office suites only adding complexity to this kind of software.

Templates cannot even emulate most crucial features of themes: their dynamism caused by close separation of style definition from content definition. Good typography in documents can be achieved by having set of styles. But as noted in description of the ODF limitation, only loose set of styles is available with minor inheritance features.

What's in FOSS?
LibreOffice still does not support themes and I have not heard about any plans. Funny enough there is Tools->Gallery that looks like Themes feature but it's a gallery of bitmap items for use in bullets or elements of HTML 2 (!) web pages. Clicking on graphic background item inserts a floating bitmap instead of formatting background for a spreadsheet's cells.

Calligra apps and AbiWord or Gnumeric so far follow what comes with ODF, what means zero theming functionality. Basically all the apps offer is a style selector and editor presenting styles defined in the document (and copied from a template). While standardized around ODF, this functionally matches features of the closed-source competition from the pre-2005 era.

For many years now charts in LibreOffice or in Calligra have implied some sort of color themes for data series. But I believe even this is largely defined at application level though and just copies a functionality of older office apps.

What now?
So what to do? I was aware of many massive TODO years ago but just now I think it's good opportunity to push for making KDE software produce professionally-looking documents. And any content in general. While we can see so much effort put into the GUI elements, content is not less important. It is what users creates and so often the reason he fires up an app. GUI, the shell, is the envelope so we cannot stop just at it.

At the Calligra Sprint #2 I presented the vision and reasoning so in theory things should go smoother now even if a lot of effort is put into the Calligra Engine, a machinery running on the backstage to make your document viewing and editing fly. Wish us luck implementing global Calligra Themes and apply them anywhere we can.

Many mockups could be prepared but I only found time for three, showing the vision in practice (actually for Kexi these are real screenshots):

Reporting in Kexi with theme applied (visible in the font faces and size and in the color of the page header)

Resulting report with data populated, ready for printing

The same document theme shared by Calligra Words, document heading shared the same style the one seen in the Kexi report

Summing up, proposed ideas and requirements for the Calligra Suite:

• Themes define every visual aspect of document
• Goal: enabling users to work with styles via themes
  • Default theme could be selectable globally in Calligra
  • In some aspects theme can define GUI elements that are not well defined by QStyle/KStyle, e.g. spreadsheet grid and cell styles (Calligra Tables) and database tables grid (Kexi) can have common look defined by a theme
• Support for themes in:
  • documents (odt, ods, odp)
  • reports of any types, especially reports used in Kexi and Plan
  • Kexi views, besides reports also forms and tables. This means that also form widgets could be themable and thus receive more web-like look if this is expected by users.
  • graphical elements like frames, diagrams (Flow)
• Themes affect any properties of ODF styles - character, paragraph, table styles (fonts, colors, margins, padding)
• Themes are applicable to existing styles without manual tweaking by users
• Themes are stored separately of documents is dedicated format and versioned. Only for compatibility with other office suites, styles are generated into the document but references to original themes are kept in custom XML tags. This is allowed by ODF.
• Thus, themes may be shared through the KDE Get Hot New Stuff and/org other means
• To design a theme one should not need to edit XML representation, it should be possible using dedicated theme editor.

I've just committed a fix to the Calligra Engine, so that font rendering will be without hinting when compiled against Qt 4.8.

And here are the obligatory screenshots to prove it (thanks buscher). Both are with system wide hinting turned on.

First on Qt 4.7:

And here on Qt 4.8:

Big thanks to Eskil Abrahamsen Blomfeldt at Nokia for implementing it in Qt.

A comment at the Calligra Words blog-entry asked about re-adding the CTRL+M "Hide Menubar" option back to Calligra Words (and the KDEPim-applications).

That is a *very* bad idea.

The "Hide Menubar" option, known from many KDE3 applications, is the typical example of a break-me option. The user can hit it by accident and will have a hard time to restore the previous state. More so if you add a 2-letter shortcut like CTRL+M to that option which is easy to hit by mistake and not so easy to discover if you did not know about it before.

Our rather detailed KDE Human Interface Guidelines even explicit name the problem:

Don't make the menubar 'hideable', users may not easily be able to make the menubar viewable again

As cool as it may to hide the applications menubar it can be a rather destructive action if done by accident without an easy way to undo and restore how it was before.

Ask yourself why you like to add such an action to your application? If the target is to just remove the menubar from all the applications cause you do not need or like them then why should that be done for every single application manually? Why should there not be a global way that allows to disable (or enable) them all in one go? Maybe even with a possibility to display the applications menubar somewhere else outside of the application like in the Panel (OSX-like) or only on hover or only with a certain shortcut like CTRL+M... This is what widget-styles like QtCurve or Bespin allow already today. If your preferred style (e.g. Oxygen) does not allow that yet, then you can still create a bug-report for that or provide a patch. In any case it will work out-of-the-box for all our applications and does not require you do add and later enable such an option at every single application.

Allow me to introduce the amazing new word processor that will be released with Calligra Suite 2.4 in 2012. It is fast and nible to use, and using the powerful Calligra Engine we have made sure it can load .doc and .docx and ODF documents. And with so astonishing quality, that it will be your favourite for viewing such documents.

For writing and editing we are developing an efficient and innovative user interface. It has a lightweight menu bar with only the basic File, Edit, View, Settings and Help menus. Everything else is manipulated through the sidebar.

And by choosing ODF as our native loading and saving format, we have ensured that your documents can be exchanged easily with other users. ODF is chosen by many governments and users around the world.

Our aim is to become the word processor of choice for everyone. In the following releases we will gradually expand and improve our user interface so you can insert and manipulate more of the fantastic features hidden in our engine. But even in the first release you can add and manipulate many of the basic document elements like tables and lists plus more special elements like footnotes, endnotes, autoupdating table of contents, graphics (the text flows around it) and even a bibliography.

We are still in beta phase of development which means we fix bugs and improve the stability, but we are no longer adding new features for the first release. We are regularly releasing beta snapshots and would like to invite you to thoroughly test and report any issues you find. Especially in the areas of editing and saving. This way you can be part of making Calligra Words the best it can be when we finally release.

Since I don't have an account to reply there http://blog.rburchell.com/2011/12/why-i-avoid-qregexp-in-qt-4-and-so.html, I'll do it here.

Recently somebody benchmarked regexp libraries as potential candidates for use in CMake.
Short version: PCRE was not exactly much faster than what is in CMake, re2 and TRE were magnitudes faster: [cmake-developers] Re: slow regex implementation in RegularExpression.
This is the home of TRE: http://laurikari.net/tre/about/

Alex

It may seem obvious but eating our own dog food can definitely be good for your project's condition. Especially when it is maturing over time. How many testers can we have and how many personas for your user-centered design can we define and maintain? Usually just a few with the actual resources. Is only fulfilling needs of more or less fictional actors focusing on few use cases a good direction? Or does it put our vigilance to sleep?

Well, I am convinced you and your co-workers can be good actors if you actually start using your software more.

Click to open (PDF)

In the CSS2 presentation I published above there are only few but probably telling examples of what features of Calligra we can start using more in the project and how. There also a 'why'. Never force using apps if there are better (or good enough) tools already in place. Own dog food consumption can also be a risky business if the usage feels superficial and would not finally translate to any real-world use cases.

For example I do not intend to employ Kexi database creator for ad-hoc spreadsheet calculations on small, loosely structured data. Kexi and databases in general were not designed with this use case in mind. So as always it is better look closer.

The idea already brings its fruits. Adam has already set up a PostgreSQL server for internal project-related services, in addition to various tests we plan to host there.

Can you quickly identify your products' use cases that can be introduced by your team eating your own dog food? Please leave them in the comments section below.

PS: Next time in the CSS2 series on shared Calligra themes.