Today I updated the KDE Licensing Policy with a couple of changes following requests from folks. Most notably Creative Commons is now allowed. This is only for standalone media files (such as an image for a splash screen) and not for anything which might want to be mixed with GPL material such as icons. "Attribution-Share Alike 3.0 Unported" is the version allowed. The other change is requiring BSD licencing for CMake modules, which brings the policy into line with existing practice.

The Ubuntu Developer Summit is happening this week in Dallas. The theme of the discussions is LTS and what it will take to have a release in six months which can be supported for three years hence. We've been having sessions on packaging, development, bugs policy, translations and more. You can find the schedule and how to take part in sessions on the summit website, there are icecast streams for all the rooms. The Kubuntu specs are on this wiki page still works in progress of course. It's going to be great to have a KDE 4 release suitable for LTS, just six months to do it!

Some of the Kubuntu Team take to the ice rink

Many small fixes are a building block of the Kexi porting effort - the goal is joining the KOffice 2.2. Many of the fixes and refactoring is related to forms. Much more left and we're scheduling works on crazy features even up to Kexi 2.6 already.

The next is porting task, I hope, is the table view port to QScrollArea from QScrollView, what's rather demanding task to me at least since while the table view can be called widget itself, it is the biggest one (# of SLOC) of those I have touched directly so far in KDE (at least it bundles a dedicated model/view framework developed long before the first announcement of Qt4 Model View API).

Sometimes one needs to add some procrastination, and this time I added an indicator/emblem-like icon to forms so you can easily notice that what widgets are bound to data source (and to which).

Kexi Forms: Data source emblems for data-aware widgets; click to enlarge

Other small improvement that you can find in above screenshot is frame-around-labels in the design view. Before that, we had to live with borderless labels, like in Designer. As Kexi generally lowers barriers for new users, we display the frame more like in case of a text frame in a word processor.

In related news, I am also excited that Nuno has admitted that one of the forthcoming items on his list are Oxygen icons specific to Kexi.

Speaking of procrastination, we (me and Nuno and Hugo Pereira) just yesterday had a small session of three graphics-loving guys regarding some bits of Oxygen style. Two outcomes of that are:

1. Idea for cleaning up vertical lines for the case when docks+tabwidget+splitter+another frame is used in an application. This is the case for Kexi as well everywhere in KOffice and most complex apps featuring sidebars. I bet the idea is not new and the improvement is pretty much demanded. Two proposals (less and more extreme):

(compare these improvements with the current look presented earlier.

2. Exclusive QGroupButton styling for Oxygen; my early proposals, need fixes but the 3rd is somewhat acceptable. The mockups use Kexi's view switchers as a base.

On the technical side, I think the look can be either set default or can be supported via K* overload of QGroupButton or addition to KStyle or by setting a Qt4's dynamic property (so developer can decide to alter the look only for some group buttons). Whatever we recommend, it could find its way to the HIGs first.

There's also one note that we agree on, that since the Oxygen now employs fade in-out when you switch between tabs in QTabWidget, this effect should be measured and switched off when there are too many delays. The goal is not only to support slower machines or conserve power but also cases when there are large Konqueror's (or Kexi's, which is indeed my test case) tab areas much harder to fade in-out than small ones. So there could be some logic employed depending on the size of the tab widget.

Given the pile of awesome that was Camp KDE 2009 in Negril, Jamaica, how could I not attend this year as well? I'll be presenting and doing some Qt training sessions again, like last year, on whatever topic the audience wants. There'll be sun, there'll be hackery, there'll be merriment. You must not miss this, so make sure to sign up now and meet us in Sand Diego in January.

Hi there. In order to keep the tradition, an introduction in this first post. I'm Raphael Kubo da Costa, a 20-year-old Computer Science student at State University of Campinas, Brazil, and also part-time employee at ProFUSION Embedded Systems (a very nice place for any free software developer, I'd say).

My first contact with KDE as a developer was in 2006 when I sent two small patches for Konversation. Curiously and frustratingly enough, when I started university in 2007 I found myself with much less time to dedicate to my own free software interests than before -- even though I did to go to the International Free Software Forum that year and happened to be one of those "new and interested developers" to whom aseigo showed off the soon-to-be KDE4.0 desktop on the exhibition floor.

Since the beginning of this year I've been contributing to KDE in a few different fronts: I do some occasional bug triaging and commits to kdelibs, but most of my KDE time is spent maintaining Ark, our old and beloved file archiver, with Harald and helping the KDE-FreeBSD team (I'm not a full-time FreeBSD user, although I'm writing this post directly from FreeBSD 8.0-RC3). So expect me to write more about these activities in the future.

Now let's try to make this post a little less "hello planet-ish" and talk about Ark, KDE's file archiver which lives in kdeutils. I believe it's one of the longest-living programs in KDE (the first commit shown by svn log is revision 12097, which was actually a CVS commit and dates back to the end of 1998). It has survived our four major releases and has had quite a few different maintainers (curiously enough again, most of them were Brazilian).

So what's the state of Ark today? As I write this post, Ark's bug count in Bugzilla is at 72, which I consider a small number to be honest. However, we have been mostly in bug fixing mode for at least a few months, and some bugs need pretty big changes in code to be properly fixed. Being a university student, working (even when it involves using Qt) and also having a life means I don't have that much time for big changes at the moment, and neither does Harald, who's also losing his hair to graduate from university.

I don't want to end this post in a negative mood, though. So my dear reader, you have been watching the KDE "scene" for some time, you would like to contribute and you don't know where to start. Well, Ark needs you! Despite its age, Ark has a small code base, and both Harald and I are (presumably) nice guys and we are more than willing to help you. And you, my dear reader who already contributes to KDE, how about doing something completely different?

Oh, yes, just in case you haven't noticed, it's out. However, since I maintain this image of seriousness, purposefulness and so on (which I only occassionally spoil by something like doing strange things to my hair, eating way too much icecream or doing silly things at SUSE outdoor events), I would like here to reference the KDE release notes for openSUSE 11.2. We recalled at least the Pulse Audio thing a bit too late, so maybe right now the actual release notes do not mention it yet.

Default Web Browser - yes, we default to Firefox with KDE integration, see the notes for switching back. Nothing more to say here, if you still don't know about this, you apparently don't know about KDE and openSUSE (in which case you're kindly asked to fix that ).

KDE3 - boy, I'm getting really tired of this topic . It's really simple: Apparently there is nobody caring about KDE3 enough to do something about it. So, if you are in the minority that still doesn't find KDE4.3 good enough as a replacement, either just stick with an older release, or try to use the unsupported KDE:KDE3 repository, which right now looks like it still builds, but may not anymore tomorrow if anything changes, since, as I said, everybody feels like having more important things to do than spent time on it (really, we tried to find people who'd be interested in it, but apparently all people capable of doing so already work on KDE4 or are too busy complaining on mailing lists). So, just get over it. KDE3 is dead. It is no more. It has ceased to be. It has expired. It is an ex-KDE3. (Thinking of it, I will skip that is has gone on to meet its maker, just in case).

Strigi/Nepomuk - they are disabled by default. With Beagle not enabled by default being asked a lot for, and generally considering the situation, we decided this would be a better option (and upstream wasn't really against). Those who want them enabled can easily do so in systemsettings. Well, almost - unfortunately a problem slipped in that prevents starting Strigi in default installations. See comment #6 in the #548007 bugreport for an easy fix.

PulseAudio - since KDE not only does not have a hard dependency on PA but also there is basically no integration of PA, having PA with KDE doesn't buy anything to most users, so we decided to disable it by default in KDE installs. This is not the broken PA that was in 11.1, but still, why force it unnecessarily. Those that have a use for PA need to enable it in the YaST Sound module (note that this includes everything running on a system that has KDE as the default desktop).

Now, onto the goodies!

I often say that my hypothetical user for Kubuntu is my non-technical girlfriend. Unfortunately I'm between girlfriends at the moment but the intent is still there. Someone who uses the computer for everyday tasks of web browsing, chatting, watching videos, listening to music, writing some documents, storing photos. But also someone who doesn't care about computers any more than I care about my car, it should do the job but I don't want to have to fiddle with it to get it to work. Unfortunately I rarely get the chance to try out Kubuntu on such users, my family have all been using computers far longer than I have and are just as stuck in their ways as I am in mine.

But yesterday I did get a chance to install Kubuntu on a dying WIndows machine. The worst part of the process was booting up Windows to see how much disk space there was, it took 20 minutes to boot up loading all the half broken vendor apps and anti-virus software. Then it took 20 minutes just to shut down, every 30 seconds interrupted by a "missing .dll" or similar dialogue.

So up boots Kubuntu from the CD in half the time than Windows boots from hard disk. All hardware working perfectly. The disk partition resizing is a breeze, installation works without problems.

We came across two small problems. Knetworkmanager doesn't give much feedback if you use the wrong wifi encryption or password method, and the Firefox installer claims it has nothing to do if you don't have an apt cache first. Both known issues which I expect will be fixed before long.

So far one very happy customer, off to browsing the web in 1 minute beats Windows by a factor of 20. But that is just the install. I'll find out in the coming days how someone who doesn't care about computers manages with the everyday tasks that we all expect to work easily.

Now that the mention of the Firefox KDE integration I've done has reached also the dot, I guess it's time for a couple of things that don't quite fit into an article but I should probably say them somewhere anyway.

First of all, this is nothing against Konqueror. I still use Konqueror. In fact when a couple of months back there was a wave of "let's ditch Konqueror" voices on the planet and kde-core-devel, I was one of the people opposing that (and I still think it's not an option, as Konqueror is still the best KDE browser there is - Aurora is Qt-only, Rekonq is at version 0.<somesmallnumber>). For the next openSUSE release we will evaluate the possibilities again and Konqy may end up as the default again if it's considered to be up to the job. Speaking of which, Konqueror has never really been 100% default in openSUSE, as the desktop icon, which is what the common user uses, has always been Firefox, so we can also say the we just fixed the inconsistency (and it's really simple to switch it back). But the real reason was that many people are simply not satisfied with Konqueror, so we decided to try to not ignore the reality for a change. I myself use Konqueror, but if somebody else wants to browse the net on my home machine, they get Firefox. I don't like this, but what the hell, c'est la vie.

So, when we decided to make Firefox the default, we also faced the problem that we switched to something that from KDE user's point of view sucked in pretty much all aspects except for the browsing itself. The idea of Firefox desktop integration on Unix ranges from not bothering with it at all, over using generic not-really-desktop stuff like mailcap, to thinking Unix==GNOME. Normal Firefox in KDE offers to open PDF files with Evince, shows /usr/bin in a filedialog when you decide you'd like to open the PDF in some other application, has inconsistent (not just reversed) button order in dialogs and other yummy things. There have been attempts to solve this e.g. by creating a Qt version of Firefox, but those AFAIK have never led to something usable in practice, and with WebKit now part of Qt I somehow fail to see the motivation for anybody to try once more. And in this situation we had just a short time before openSUSE 11.2 feature freeze.

The trick, of course, was using magic. The Firefox with KDE integration is still the same Gtk Firefox, just with a bunch of hooks calling an external helper. I don't have the ability of some other KDE developers to have clones, and I'm not crazy enough to try to mix Gtk and Qt in one process (which, despite the possibility of a shared event loop, should be nowhere near trivial). So it's nowhere near the extent of the Qt port, and maybe that's why it has worked out (as we all should know, perfect is the enemy of good).

The helper and the patches at available in a Gitorious repository, they are made to match the openSUSE package so they may not possibly apply cleanly to upstream sources, but feel free to play with it. Actually, you are more than welcome to do anything you want with it (wanna be the maintainer of it? no problem). With the problem more or less solved, and with other things to do, I don't have any further big plans for it. I will try to push this upstream if possible (I have no idea what faces will Firefox developers make when they see it), but besides that, there are still many other areas that need some magic. And, after all, the ultimate plan is still that Konqy will one day rule the world .

On a related (to my other blog post today) note, while I'm giving credit where credit is due: my personal KDE hero at the moment is Anne Wilson, who has been helping KDEPIM users for years on our lists and at meetings and has been a voice of reason, courtesy, constructive feedback and positiveness that makes a huge difference in the atmosphere of our community. I much admire her work with the documentation team (userbase, anyone?) and the community working group and ever since I first met her in person (in Glasgow, I think) I have been impressed by the fearless and all embracing manner in which she has found her way amongst us weirdos and become a gentle, well respected leader and wrangler of geeks. I don't know when exactly it is, but happy 70th birthday, Anne, all the best from us PIMsters, we thank you and look forward to many more Akademy meetings with you.

9.10 is out. KDE 4 is really taking shape now with more of the important gaps getting filled. We ported OpenOffice integration to KDE 4, the installer got some beautiful love from Nuno, social apps integation in various places, there's a handy message indicator and notifications work cross desktop. We have the latest KDE apps of course, K3b gets a KDE 4 port, user config got ported too. Rather importantly network connects work and intel graphics drivers aren't rubbish.

There's a shiny new Netbook edition thanks to the Plasma Netbook guys, it's not complete yet but it shows off a lot of nice ideas.

Looking at the future there's still some obvious gaps in the KDE 4 stack, some are being worked on like kbluetooth which has a new maintainer, some don't seem to go anywhere like file sharing, others its less clear what to do such as the web browser question. But I'm confident that in six months time we'll have something worthy of being LTS.

Hugs to everyone who helped develop and test this release. Go and download or Upgrade and let us know what you think

Ladies and Gentlemen, introducing Adam:

Once again we need testers, this time for the candidate images for Kubuntu 9.10. CDs, DVDs, netboot and upgrades all need going through their paces in triplicate. Join us in #kubuntu-devel to coordinate and log your results on the ISO testing site.

This weekend I visited my parents in law, because my wifes paternal grandmother celebrated her 90th birthday. I noticed that the laptop they use was still running Kubuntu Feisty with OpenOffice 2.2. On this machine, reading emails, managing photos, surfing the internet and working on office documents are most important. Digikam is used for photos. Kmail and konqueror from KDE 3.5 are installed and a mix of OpenOffice and Microsoft Office 97 on wine is in use for editing office documents. in short, a horribly outdated setup of more than two years old. IT is still moving fast. Feisty was not a long term release and no updates for it anymore.

So in a slightly reckless move I decided to update the machine to the next Kubuntu: karmic koala. This meant going to KDE 4.3. To my relief the install went very well. All important settings for digikam and kmail were migrated automatically. Dolphin is really nice and more intuitive for non-professional users. The kwin effects add a nice touch of class (translucent wobbly windows). Plasmoids on the desktop (photo frames and weather forcast) were very well received.

In short: good karma! Thank you very much, Kubuntu team.

(my last two blogs were written on the Nokia N900 which has a good keyboard)

One important feature for photo management is missing in the FOSS world:an application for creating photo albums that can be sent away for printing at a printing service. There is however a pretty slick closed source application that works on linux. It can be fiound at for example Pixum (also in.nl and .de). It is based on Qt 4.4 and installs using a perl script which downloads the artwork and the required libraries. The application is customized for different printing companies that have these customized downloads available from their website. Not all of them
offer the linux or even the macintosh version. This is a shame and probably done to limit the number of different questions users might have. A standard for these photo album ordering services would be great, but I'm not holding my breath and will recommend Pixum for now.

Kubuntu 9.10 CDs are now available for pre-order on the Kubuntu Shipit site.

Can't wait a month for the CD to be delivered? Download the release candidate now for one last round of testing. Thanks to everyone who helped test the RC releases, see you again next week for the real thing!

You may remember two of my recent blogs. One was about a project to parse powerpoint files and another one was about porting hexdump to the browser.

So how about a combination of those two topics: parsing powerpoint files in the browser. It is quite a feasible task. The powerpoint file format is largely described in an xml schema now. From this scheme one would need to generate a parser like there is for c++ and java already. The parsers for java and c++ are both less then 700 lines of code.

We have not reached that stage yet and I do not have time to implement a powerpoint parser in javascript soon. I have written some requirements for it. To parse the individual data streams in a ppt file, one must parse the OLE2 file format. Currently we use pole for this in c++ and poifs in java. Now I could port either of these libraries to javascript, but there is another nice OLE parser: strigi.

In Strigi, the OLE file format is treated like other container formats such as zip, tar and mime. Porting parts of Strigi to javascript seemed like an interesting challenge. In Strigi, we use low level c++ to ensure speed. Most of the techniques used in the c++ are not available in javascript. So the javascript version is bound to be much slower. Still, I was curious what Strigi would look like in javascript.

And now it is ready. The parts required for reading OLE files have been ported. The result is one html page of 600 lines. It can read ppt files and list the streams in there. When clicking the streams, you see the stream in 'hexdump' style display. The speed is not even that bad. It takes about a second to parse a megabyte of file.

enjoy the demo!
(firefox 3.5 or recent webkit browser required)

All hands on deck for the release candidate CD (and DVD and USB and upgrades) testing day. See the ISO tracker for what needs tested (duplicates tests always welcome) and join us in #kubuntu-devel to coordinate.

A feature that has been floating around in a few places but hasn't been a
significant feature in KDE is web slicing. This is the ability to take a piece
of a web page (commonly a div) and render it as a standalone object. It's
useful for stuff like putting a weather forcast on your desktop, watching new
comments on a forum etc. This weekend I made a start on implementing it as
tool for Project Silk.

The first version I wrote was pretty simple - it lets you specify the element
you want rendered, then presents it to the client application as a
QPixmap. This was fairly easy thanks to the new QWebElement API, the core of
the code is as simple as this:

QPixmap Slicer::renderElement( const QString &selector )
{
    QWebFrame *frame = d->page->mainFrame();
    d->page->setViewportSize( frame->contentsSize() );

    QWebElement element = frame->findFirstElement( selector );
    if ( element.isNull() )
	return QPixmap();

    QRect rect = element.geometry();
    QPixmap result = QPixmap( rect.size() );
    result.fill( Qt::white );

    QPainter painter( &result );
    painter.translate( -rect.x(), -rect.y() );
    frame->render( &painter, QRegion(rect) );

    return result;
}

This is enough to let you specify a CSS selector and render it to a pixmap
thanks to the nice API of QWebElement. Doing the same using the DOM API would
be simple enough, but a lot more verbose (and probably less flexible). The
code above was enough for me to make it trivial to write tools that present a
slice of a web page as part of their UI.

As ever in life, some people are never satisfied so a common response was
to ask if I could make it so the slice is interactive. This is a bit of a can of worms
as everyone has their own definition - eg. simply responding to requests from
the page to repaint could be trivially added to the code above and would offer
the same functionality as that I'm told MacOS offers. Rather than try the
half-way solution, I wrote a prototype that actually gives you a fully
interactive slice - eg. you can type into the form elements. It's not
production quality, but it proves the point. You can see the result below:

Around the point I got this working, Kenneth let me know that a commit had
just landed in QtWebkit that would make the earlier version even simpler -
there's now a render() method on QWebElement that does exactly the same thing
my original code did. This is great news, as that solution is the correct one
for a lot of use-cases.

Of course, by this time, I was quite tired but Sebas was still feeling
lively. The result is that 'live slice' code gained support for being embedded
in QGraphicsView overnight using the new QGraphicsWebView. There's a support
class that makes it available as a widget like before, but the implementation
is using this (new in 4.6) class. All in all this means we can nicely
integrate this functionality into apps using QGraphicsView like plasma or
amarok, and into QWidget based apps too.

All in all, a successful couple of days in the stealthy advance of project
silk.