With the Sonnet library for KDE 4, developer Jacob Rideout hopes to reinvigorate the field of desktop linguistics by adding automatic language detection and other innovative features. Sonnet is to be for KDE 4 what KSpell 2 is for the current version of the K Desktop Environment, providing spell-checking facilities to applications as diverse as the Konqueror Web browser, Kopete instant messenger, and KWord office software. Unlike KSpell, however, it will also provide grammar checking, multilingual tools, and perhaps even translation, dictionary, and thesaurus functionality across all of KDE.
KDE 4’s Sonnet Will Turbocharge Language Processing
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I write in both english and french, and I like the idea of Sonnet determining which language I’m using on-the-fly.
System-wide spellchecking, thesaurus, grammar-checking and (one day) translation is a *big* plus for KDE. KDE 4 is looking more and more like the “killer desktop” everyday!
One thing to remember is the fact that these projects – the many KDE 4 projects – are all concepts for now. The goals have been states, but the coding is still in early stages. I wouldn’t hold your breath…
Edited 2007-02-08 23:05
Well, the article states that this is 75% done, so I wouldn’t say that it’s “just a concept”.
Granted, KDE4 won’t be ready for a while yet…but I’m still excited about it!
75% done is programmer code for 30% done generally speaking. We have a tendency to get too excited about what we’ve designed and implemented and forget all of those details we haven’t yet accounted for, not to mention how long it takes to hammer out those final ugly glitches.
I’ve been developing most of Sonnet and you are correct. The 75% figure represents lines of code, not time to completion. There is significant Q&A work to be done among other things. However, the fundamental technology is already there, thus this is not vapor-ware.
> all of those details we haven’t yet accounted for
agreed. kde 4.0 will be a lot like kde 2.0: lots of interesting new technologies, things learned from the past revisions of kde, etc… but lots of work left to really polish it out and to bring all the apps together getting the most possible out of what’s going on.
4.0 isn’t the end of development, it’s the end of the beginning. it’s where we get to start realizing the potential of it all.
kde2/3 didn’t really gain traction until 2.2 imho, and 3.5 has been pretty remarkable. i still enjoyed 2.0 (it’s what converted me to kde, actually =) and i’m sure i’ll get my kicks out of 4.0, but you’re absolutely right that there’ll be lots more to do post 4.0 that’ll be important and exciting.
that’s actually why we usually refer to it as kde4 rather than kde 4.0 =)
The coding isn’t in as early a stage as you might think. Language detection and spell checking are up and running in sonnet, and they both work in background threads to optimize performance. Here’s a link to an article from the developer (with a screenshot even):
http://blog.jacobrideout.net/2007/01/language-detection-works.html
Also, just today Decibel (the communications framework) 0.2 was released. It’s feature complete and (from what I understand) the main things left to be done are integrating it with the other kde4 technologies. The release announcement is here:
http://basysblog.org/index.php/archives/decibel-020-a-pillar-of-kde…
In fact the many KDE4 libraries projects are at a pretty much advanced stage in code. Now what is lacking most for this libraries is polishing, and determining what is wrong in the API to insure its stability over the KDE4 lifetime.
But, the integration in applications is lacking, and that might not happen in 4.0, and that will probably not be finish before 4.3. And that’s only reason to hold your breath
Having a good technology doesn’t mean it will be used by all immediately.
> are all concepts for now
so we’ve had articles showing the current working state of phonon, sonnet, advancements in various apps (sysguard, games) etc .. in the last month or two and you still think they are just conceptual? hum. well, the code is in svn and its at the state where people who like to write about these things can actually build it and show it in action. to me that’s a bit beyond conceptual =)
There are many people who complain about things not being adapted for integration in their favorite platform. I haven’t been one to care much simply because most platforms haven’t offered programs as much capability as what KDE is moving toward.
For example, I would like Firefox to have better integration with KDE for printing because I like Firefox for browsing, but I can’t print a page to a PDF from it using Kpdf like I can from Kopete. Fortunately, I can work around that since it is the only issue I can think of off the top of my head.
Lack of integration in the future could mean giving up on practically free features. I’ve found spell checking to be nice in Firefox, but grammar and a thesaurus would be even nicer, not to mention the troubles when using multiple languages.
I guess the KDE developers have responded in a very big way to the negative comments about KDE 4. Sonnet and all of the other projects discussed recently are making me excited to see the eventual combined package.
“For example, I would like Firefox to have better integration with KDE for printing because I like Firefox for browsing, but I can’t print a page to a PDF from it using Kpdf like I can from Kopete. Fortunately, I can work around that since it is the only issue I can think of off the top of my head.”
Sounds more like a feature request to the Firefox crowd. I admit that this is really nasty. And by the way, Firefox does not support language detection. Time for them to team up with KDE developers.
I wasn’t trying to rip on the Firefox crowd. I realize that it is often considered better to try and provide a consistent experience within an application across platforms than to have the behavior change from one platform to another, and I realize that one way of doing that is to provide features within the application rather than relying on a platform to provide features.
I like Firefox. Unfortunately, the developers seem to allow it to be a second-class citizen on KDE by not striving for better integration.
. I realize that it is often considered better to try and provide a consistent experience within an application across platforms than to have the behavior change from one platform to another
Ah, true, but it depends on your definition of consistent behavior.
For example if you have desktop integration on one platform (e.g. Windows) and not on another, isn’t this also a behavioral change?
I am afraid the “consistent across platforms” mantra has been meant to be a noble goal, but I have seen it being used as an excuse way to often.
Well, on Windows the integration between apps is often less than in KDE anyway… So I use Firfox there, works good enough. But in KDE, I expect integration to be better (eg drag tabs from one window to another, drop a folder on the empty tabbar to open it, or throw a tab on the desktop or in a folder to make a link etc) so I don’t use Firefox there.
“Fortunately, I can work around that since it is the only issue I can think of off the top of my head.”
I don’t know what your work-around amounts to, but it is possible to get Firefox working with the KDE print system.
http://www.ubuntuforums.org/showthread.php?t=205050
It’s not exactly automatic, but it works quite well.
For example, I would like Firefox to have better integration with KDE for printing because I like Firefox for browsing, but I can’t print a page to a PDF from it using Kpdf like I can from Kopete. Fortunately, I can work around that since it is the only issue I can think of off the top of my head.
That low-level of abstraction is the kind of thing the Portland project is working on; the idea being that third-party apps shouldn’t have to code for either KDE or Gnome, or both. Rather, for common desktop functions like file selectors or opening a browser or email client, one of the portland applets is called instead and it will determine the user’s DE and call the appropriate function.
But that fdo-type compatibility layer is suitable only for commonality between different DE’s. Attempting to integrate higher level functions, particularly if each desktop lacks an equivalent to the other, is probably beyond the scope of DE-agnostic layer.
Plus, there’s always Konqueror.
> That low-level of abstraction is the kind of thing
> the Portland project is working on
indeed. and now that the first phase of capabilities provided by scripts primarily for non-runtime needs is drawing to a close and the second phase of an API to a dbus driven set of services is being developed, this is getting closer to a reality each day.
in another year or so firefox on linux could quite easily just call the print system via the portland api and have the correct (for the given user) dialog appear and communicate with firefox.
this seems to be a much saner way of dealing with the integration issues than patching each app for each permutation, ala openoffice.
exciting times =)
I’ve never tried it with Firefox (works with OpenOffice.org, though), but couldn’t you just configure it to use “kprinter –stdin” as the default printer? That way, Firefox would send it’s data to kprinter, which would pop up the standard KDE print dialog.
Everything we need is there and KDE 3.5.x is already great.
Language detection algorithms were published in the midth nineties.
What’s really important now is to reduce the complexity of Desktop Linux. One option is that unified solution/interface.
Well, by avoiding duplicate work through using generic libraries which offer high-level functionality, writing and maintaining apps for KDE is greatly simplified. The desktop becomes more consistent and complete. So I guess they are working on it
Honestly, that screen shot is awesome. At first I thought it may just allow for spell-checking in text boxes, etc which many DEs do already – but, multiple languages in one “input field” is insanely great.