KDE 4: Sonnet

The KDE promotion teams gains momentum with the weekly “The Road to KDE 4” news. Hidden in this weeks release about Koffice you will find some words about Sonnet – the KSpell replacement and therefore the framework that will support you with spell checking.

The basic idea was to replace KSpell with a full linguistic framework capable of grammar checking, dictionary functions, translation – and of course spell checking. For me one of the most promising features will be the GuessLanguage function: in short, as I understand it, Sonnet will be able to detect the language you are currently writing in, and will chose the background according to the language (spell checking libraries, grammar libraries, and so on). While this does not look very promising for a native English speaker, almost everyone else really needs this function!
As an example: I write this blog in English, but my mails to my friends mostly in German (well, to the German friends 😉 ) – I cannot quickly change the spell checking language, so I keep it in English and just hope that I get the German errors by myself. Now imagine to add just one more language (like French) in your daily usage, and you are totally lost with the current KSpell system. You will only get the errors in the texts written in English – all others will pass by.

This language guessing function is, btw., already in heavy development. The last commit digest reports stuff like “Added Khmer detection to GuessLanguage.” which is a pretty good indicator for the state of the system, I think 😀 You will also find this comment: “Sonnet language detection now ignores minor segments of other languages within the text to be checked” which shows that the developers mean business.

One of the biggest architectural changes of Sonnet will be the change the spell checking engine. While KSpell used its own plugin API Sonnet will use the AbiWord engine “Enchant”. The hope is that Sonnet is easier to maintain and that some of the developers work can be shared between AbiWord and the KDE team.
The grammar will be done by the “Elixir” engine which will come from a cooperation of KDE with the Enchant guys, I think.

You can find more information about Sonnet in Jacob’s blog (who is a professional linguist, btw. – yeah for KDE!). A short note about the how-it-began can be found in a comment from Zach.

OpenOffice.Org thoughts and things

The planet is very quite at the moment and I’m afraid I will not get any usable information and slides about the talks given at this years akademy before Monday or even the end of the coming week. Poor me. But anyway, there is other software worth writing as well: OpenOffice.org.

As a previous explanation: I do not really like OpenOffice.org. Despite the fact that it technically introduced the Open Document Format to the masses there are not too many good things I could leave on it. Ok, that’s probably a bit too hard: Sure, OpenOffice.org is the only competitor for MSOffice at the moment, and it delivers what most people expect. It also seem to be good enough so that quite a lot of people are backing it.
But: from my point of view OpenOffice.org is more bloated as the most other pieces of software around, and there are too many ways where you can just not compare it to MSOffice – like the start up time. The same is true on the Linux platform, btw., where you could compare it to KOffice – which starts up much, much faster. Also the desktop integration is less than perfect – on Windows as on Linux. Again you can not really call it a competitor in this field.

So the question is what to do – for me I expect quite a lot from the upcoming KOffice 2.0 – it will take its time, but it looks like that this Office version will have quite a lot to offer. But there is still hope – OpenOffice.org will be further developed of course. This article is quite interesting in this regard, it talks about the OpenOffice.org conference OOoCON 2006. The author mentions that OpenOffice.org will get extension support like for example Firefox has it. The idea is to add much more user developed functions through a stable and open plugin interface. Sounds interesting, but it has to show if such a thing is really useful for an office suite – and if the plugin API is done right to fit the needs.

However, after reading this entry I checked the conference page and found some more slides for interesting talks. For example the talk “Comparing ODF and OOXML” (PDF) explains pretty detailed what the difference between ODF and Microsoft’s preferred document “standard” are. It’s worth a read if you are interested in some figures and facts.
Also “OpenOffice.org 2.x… and beyond” (PDF) sheds some light at what we can expect from future versions. For example there are plans to expand OpenOffice.org to a full personal information management platform – with the integration of Mozilla Thunderbird / Lightning.

Fortunately there are also talks about topics like GUI design and speed of OpenOffice in different situations. These are key topics for normal users – they need a pretty designed GUI, and a fast working program. And, yes, OOo has to focus on these topics because it lacks there much too much. I hope that OpenOffice.org will reach a state where I can recommend it without any doubt because it is nice designed and works fast.

KDE: KOffice, D-BUS, svn digest, Kopete, Akademy etc.

I’ve just been some days away, and very much happened in KDE land – but I will try to gather as much as possible.

KOffice

First of all there are exciting news about koffice: after Flake, the graphic object library of KOffice found it’s way into the official development branch, the color management of krita will find it’s way into KOffice also. The reason for that is pretty simple: imagine that your are designing a paper/report/flyer/presentation which looks perfect on your screen: since every screen has a different color profile the same result will look different on printers or other monitors. To get rid of this problem there is a principle called color management which is already well implemented in krita (but not in gimp, which is one of the main reasons why gimp can not really competete with professional graphics applications for years now, unfortunately ).
This library from krita is now ported to the rest of KOffice to make sure that every file will look exactly like it should be – on every monitor or printer!
The question which came up quickly is if this stuff (as well as Flake) is compatible with the OpenDocumentFormat, and the developers reported that they will make sure that this will be the case. If you have similar doubts in mind, remember that one of the figures in the ODF teams was a KOffice developer – they are on the subject!

Besides this new library, called Pigment, there is also a vision paper posted at the dot, it gives a pretty good impression what the KOffice developers are planning and also what exactly Flake is all about.

D-BUS

One of the most important things happening these days in the kde base libraries is the port to D-BUS: with D-BUS the communication between different programs of difefrent desktop environments is no problem anymore. It is like DCOP which was available for KDE for years now, and is a kind of a replacement for KDE, but is alos heavily used by Gnome applications.
The integration takes time though, but that is quite normal for such a complex library – and the developers are working quite fast: D-BUS can already control KDE applications, so the main work is done, and the developers can now concentrate on their efforts to polish this and make it perfect. There will be probably some development on D-BUS side also to make sure that it does not only extends the possibilities of DCOP at some points, but covers all old functions also (at least, which are sensible, I think).

From the user point of view this step does not change so much, but this impression is wrong: from know on every application can talk to every other application (as long as they support D-BUS) – think of gaim informing kontact that a buddy in ICQ went online. This makes it possible to integrate even non-KDE apps directly into KDE almost as close as pure KDE apps.

Commit Digest for 4th June

The commit digest for 4th June is out and comes with a lot of very interesting information (as usual):

• The first oxygen-icons found their way into KDE svn
• much work is done at the kdedeveloper-teamwork modules
• kstars can now project the sky maps in different projection-ways
• oKular can extract embedded files from pdf documents
• oKular can now handle document and paper orientation
• The KDE hardwaremanager can handle basic power management
• Kitten, a promising new attempt to get closer to the Tenor-aim, is now able to choose it’s backend on runtime; a GUI is also evolving
• Akonadi is already able to work together with a simple mail client
• amarok gets inotify support – that would mean that we do not need regular directory scans anymore

Besides that you will find information there about all other topics discussed here.

aKademy

The next KDE conference will be aKademy 2006, September 23rd to 30th 2006 in Dublin, Ireland. The conference homepage is now official announced and the call for participation can be found there.
The topics which should be the main topics on the conference and in the presentations are very interesting and I would love to go there – unfortunately most certainly I will not have time, but I will definitely read every single message and blog post about the meeting – and will probably try to get a KDE 4 compiled at that time to see what will be presented there (because I’m pretty sure that they will show what is working right now and how it looks like – yes, read this as: screenshots!).

Kopete

Last but not least: kopete has released a new version. While the release page does not unveil much about new features the roadmap page does now something more about the new release:

• Adium style chat window themes
• Yahoo: New Protocol Implementation
• Jabber: Experimental support for Jingle voice chats
• Jabber: Support for Offline Messages
• Jabber:Support for Jabber Transports
• AIM: Support for AIM Chat Rooms

Besides that, another kopete developers is now writing on kdeplanet together with the other kopete developers.
Blogging is one important way to communicate with these developers as a user and to ask them the questions which I really would like to be answered: Which role will kopete play around Decibel and the new IM intiatives of KDE? What are the main aims of kopete for KDE 4? Will there be improved jabber support (conferences, chats, file transfer with jingle-like p2p, jingle-like video, etc.)?
There are already posted as a comment, I’m confident that there will be answers soon.

Flickr, KOffice und KDE 3.4.1

Es gibt ein paar neue Sachen, die sich ereignet haben.

Einmal ist da mein flickr-Account – nach langem hin und her habe ich mich dann doch dazu entschieden, alle meine Fotos dort zu sichern. Flickr bietet die besten Möglichkeiten, Bilder in verschiedenen Größen in Forun, Bloggs, etc. einzupassen – so viele und einfache Möglichkeiten kenne ich sonst nirgendwoher.
Der Nachteil ist bisher das Fehlen einer Funktion, ganze Foto-Sets runterzuladen, aber das wird sich demnächst ändern – noch wird dort viel entwickelt, es ist eben noch ein Beta-Stadium.
Interessant ist auch zu sehen, wie die Programme rund um flickr aus dem Boden sprießen – wegen der offenen API gibt es diverse Tools für alle Betriebssysteme, um Bilder hochzulanden.
Wenn man das etwas weiter spinnt, wird es hoffentlich irgendwann die Möglichkeit geben, z.B. digikam und flickr zu synchronisieren. Das wäre mal wirklich nett 🙂

Eine andere Sache ist, dass leider KOffice 1.4 laut diesem Posting wohl ohne standardmäßige OASIS Document Format Nutzung daher kommt – das bedeutet, man kann zwar Dateien in diesem Format erstellen, aber es ist nicht das Hauptformat von KOffice.
Schade, denn das war das von mir erwartete Killer-Feature von KOffice 1.4, um eine vollständige Kompatibilität zwischen KOffice und OpenOffice herzustellen – ich könnte dann ohne OpenOffice arbeiten, und trotzdem mit Leuten problemlos Dateien austauschen
Es bleibt aber zu hoffen, dass KOffice 1.4.1 schnell folgt, oder aber die Implementierung weitestgehend vollständig ist.

Die letzte Sache ist, dass KDE 3.4.1 so gut wie draußen ist: wie hier nachzulesen ist, wurde es an die Packager übergeben, die das nun verbauen.
Demnächst dürften damit neue Pakete bereit stehen, was ich sehr angenehm finde, da ich vor allen Dingen in Sachen Kopete viel davon erwarte.
Naja, und es wäre nett, wenn die massiven Probleme von Konqeuror mit JavaScript aufhören würden, denn die vermiesen mit zur Zeit das Schreiben gewaltig ….

Aber alles in allem: eine nette Aussicht 🙂