irving writes; brain trusts; nyc speaking op; release team

the kde4 release team is organizing itself; there's a mailing list that was announced on kde-core-devel and hopefully we'll see some public direction for the rest of us to use as guidance for our efforts. this turn of events makes me happy =)

if you're a kde developer in the new york city area who'd be up for a speaking opportunity this year, email me. i've become aware of a nice venue that would welcome a presentation.

last night after i got off the phone with a friend where we discussed (well, i listened mostly as they had a number of very interesting insights to offer) strategic things that the free software desktop needed to accomplish i began to think how nice it would be to have a "brain trust" of sorts whose area of concentration was free software client side computing. we have a number of participatory groups that concentrate on tactical and implementation details but we have very little in the way of strategic thinking and highly focussed groups that aren't agenda driven. they do great things for the community, but i think we would also benefit immensely from small groups of people from upper achievement echelons around the community being able to work in affiliation and apply resources to "big picture" issues while still being involved in their respective focus projects. i think this gap is a big reason why we don't have a coherent directory service infrastructure or why media integration (think entertainment appliances, not codecs =) hardly gets much attention. they require a different sort of approach than the kind that is good at producing things like d-bus, portland, graphics advances or menu specifications ...

i'm currently reading john irving's "until i find you". i'm a huge fan of irving's early work but have grown increasingly impatient with his insistence on retelling the same stories with more words and less punch. so when i got "until i find you" for christmas i was hesitant. nearly 300 pages in and i'm still not sure. it's a clever book and there are certainly passages that elevate this effort over most of his post-owen-meany novels. i want to believe in his ability to deliver again.

tech wiki redux

my post yesterday about the dev wiki came off as rather bitter. that's because i was feeling rather bitter =) which is not the best mood to communicate in. a walk in the evening air last night helped, as did an unexpected phone call from a friend in the free software community.

i ended up considering why i was in such a bitter state. quite simply, i have personal limits as to how much negative response i can witness before it affects me. i really felt bad for the people who were involved in this particular set of situations and unhappy to be associated with those who would counter enthusiasm that was creating great things with "that's crap".

it happens too often that someone comes up with a 90%+ good idea, shares it openly and receives a needlessly discouraging response. unsurprisingly, they often get discouraged, possibly defensive, and conversation goes nowhere quickly except to alienate people. often times the original person walks away questioning if what they are doing is worthwhile or even wanted at all.

i know that recognizing the mental and emotional states of others in the course of creating technology isn't the most common of considerations, but it really does have an impact on people. yesterday i reached an internal limit for dealing with this pattern of behaviour.

there are ways of honestly sharing that you don't agree with someone or that you have another set of thoughts on the matter that also include taking into consideration the other person's hopes and feelings. it's really hard to have a well coordinated team that isn't constantly falling apart without doing so. i failed at that myself yesterday, ironically in the context of dealing with exactly that sort of failure.

i'm hoping that danimo will be able to broach the topic of the wiki name again with more progressive results this time.

nobody does it better

those working on the new dev wiki have a clear set of shared goals. during the process of defining these goals, it was decided that "developer.kde.org" is not a good domain name for the site. the new wiki is aimed at more than just developers and should be able to grow into a resource area for open source developers, independent software vendors, systems integrators, operating system vendors, sys admins, etc.. technical information about kde for those creating things with it, with separate entry points for each group that warrants it.

for example, we hope to set up an isv.kde.org that has the information currently in the isv section of the wiki and which points appropriately to the new wiki (and vice versa).

danimo suggested that as a solution we could name the wiki "techbase.kde.org" instead which doesn't have quite the same "this is only for programmers" ring to it. it also has the nice attribute of also avoiding the issue of link disruption that might happen if we reused the developer.kde.org domain. the idea seems sound enough and there are no objections amongst those actually involved thus far in creating and arranging the content.

it gets brought up on a kde development irc channel and great bikeshedding ensues. the clamor is for techzone rather than techbase, because that's just so much better and different, right? so danimo, being the reasonable and flexible guy he is, requests "techzone.kde.org" from the sysadmin team....

... who instead create devzone.kde.org. wtf?

remember that we started with developer.kde.org, so now we're almost back to exactly where we started. brilliant!

backward compat is good, bad

i read ian murdock's blog entry on the importance of backwards compatibility i found myself at once agreeing and wincing.

i agree that backwards compatibility is down right important, particularly for our users not to mention third party developers. the example ian used from joel's blog about sim city causing microsoft to patch their allocator so it behaved differently just for that one app (!!!) is so amazingly bad, though, that it's a bit unfortunate. a number of the comments on his blog got sidetracked by this poor choice of an example.

however, backwards compatibility, like most things in life, is neither all good or all bad. (dualism: blech!) with all the upside of it, there's also the drawbacks that come with it. namely increased engineering costs due to increased complexity of both development and testing, greater exposure to security risks and a real stunting of innovation since you can't just change things willy nilly.

we all want quickly developing, solid and innovative software ... but we also want backwards compatibility. how do we get both? that's a very good question.

this is an interesting conversation right now for kde as we're about to screw the backwards compat pooch with the release of 4.0 since there are so many api changes. for third party developers, the api changes will require changes to their source code. we've tried to limit the pain with documentation and tools but let's face it: kde4 isn't backwards compatible with kde3 and that's not the nicest thing if you are a third party developer.

fortunately, however, you should be able to run kde3 and kde4 apps side by side just as running kde1 apps alongside kde2 apps was possible. this addresses much of the issue for our users, at the cost of additional memory usage and disk space consumed.

so why do we do not just stay the conservative route? because we can provide a significantly better experience for both application developers and users.

at the same time we strive to provide binary compat throughout major revisions of our public API. we've messed up once or twice in the past on this, but generally we've done pretty well. so it's not like we don't care, we just see the both/and rather than only an either/or =)

that said, i think it would be really interesting for ian to point out some of the hot points of incompatibility that he sees and has to deal with. concrete examples are so much easier to work with than abstract philosophical meanderings.

for instance, g++'s incompatibilities year after year were insanely difficult to live with. that seems to be better now and, i'm hoping, all but solved so we won't have to deal with this nightmare in the future as we have in the past.

distros that swap bits and pieces about which results in unpredictable levels of quality and loss of knowledge investment for users are also maddening.

then again, in each of these scenarios there were often good reasons for taking the path that was taken. simply switching to a conservative methodology of backwards compatibility would address one set of issues and deliver us another.

perhaps we can find ways to evolve a system while keeping compatibility over time. you know, something in the middle. a middle way. =)

kdecore.reorganize();

it wasn't what i intended to work on today, but i ended up taking up where olivier goffart had left off last week rearranging the files in libkdecore. a few items moved into kdeui, mostly little bits of utility code that don't even get installed (exception: fixx11h.h, which i think is the header with more repeated letters in it than any other =). the classes are all in their little homes.

there are a few classes in there that we need to get rid of or at least limit the use of: kstringhandler, kidn and kstaticdeleter.

kstringhandler has a bunch of static methods that are useful for manipulation strings, but many of them are now provided for by qstring quite nicely. some aren't. we need to pick through these methods and figure out which is which and then removed the few dozen places they are each used. finally changing it from a class to a namespace and we'll be all good.

kidn was used to translate international domain names to strings and vice versa. well, qurl does all of that for us. in particular the QUrl::fromAce and QUrl::toAce static methods can be used to replace pretty much all remaining uses of kidn we have.

kstaticdeleter should be abandoned due to qt providing a couple of useful macros: Q_GLOBAL_STATIC and Q_GLOBAL_STATIC_WITH_ARGS. these macros are thread safe and will let us limit our public api exposure in libkdecore.

the above would make nice slightly-above-beginner-but-not-quite-intermediate jobs for people to sink their coding teeth into. let me know if you're interested in taking on any of these items.

i also got good news the other day regarding dbus adaptors in qt 4.3: it will be possible to access the dbus message and connection that called a slot in a class (as well as tell if the slot was called via dbus) in much the same way qscriptable, part of the spanky new qscript stuff, does. why is this good news? it means that we can now avoid most reasons to hand-edit dbus adaptors. yay! thiago said he'll also be backporting this qt-copy so i can start using it sooner, in specific to replace the dcop transaction based code in the screensaver/locking code with delayed dbus responses.

right now i'm watching kdelibs compile as i'm about to tear into a veg platter from the falafel king down the street. i was talking to seele earlier about the human interface guidelines and toolbars and we got talking about food ... and then fallafels. and then other med food. and ... i just had to have some. damn you seele! damn you fallafel balls for being so good! damn you! =)

he's ahead by a century

m. is out on the town tonight and i owe her a weekend night (we do week-about with p. and last weekend she was good enough to take him when i had an urgent need) so she brings p. by.

he walks in wearing a swank jacket with a soft-shell guitar case containing his acoustic guitar and an iPod in his ears. the boy is friggin' 6 years old. i thought he was supposed to start trying to out-cool his dad in his teens. i figured i had another 8-10 years. nooooooo.

best yet, i'm totally not cool with the drm crud that apple pulls with their iPod, iTunes, etc... this is why i don't own one. and what does the little guy do? walks in the house in a state of complete rebellion, white earplugs flowing from his ears. rebellion's not supposed to start until the pubes do, right? apparently not.

and then he proceeds to wax me at battleship.

suddenly i feel 50 rather than 31. thankfully, i have a bottle of aquavit from my last trip to norway to console me.

---

it's nights like these where i watch in wonder as he unfolds before me beyond my wildest expectations that i feel that fulfillment that they always say parenting will bring.

good news on a friday

i've spent part of this evening reading some of this lengthy report on free and open source software usage in european government. it's a fascinating read in many ways and has several useful insights ranging from usage stats to world demographics of developers to economic impacts to the difficulties inherent in measuring some of these things.

if you're at all interested in such topics, this paper is a good read; even though it's over 287 pages long it's rather readable with good amounts of whitespace and graphs. (sidenote: it's funny how papers for politicians and marketroids are so easy to read while academic papers tend to be these multi-columned, tiny font monsters.)

i just have to share some of the money shots in the paper regarding usage of free software on the desktop in european government. now, we've been getting hit harder and harder by the press for not making numerical progress in the market. (which i've always taken to mean we're succeeding; i mean, if we aren't, why care to spend breath and column inches on us?)

i've pointed out numerous times that our growth is not going to be even across all demographics and that this is completely expected and not a sign of failure. no growth anywhere would be failure; moderate growth in one or two places would be disappointing. lackluster results amongst certain groups while doing well with others, however, would just mean we have more work to do. remember, on the desktop we're the late comers to the game.

so that said, how are we doing in government? they note on page 20 that in Sweden, Britain and Germany use ranges from 3.4-13.7% in small companies and 2-6.5% in large companies. oh look, we're doing better in smaller firms. again, no surprise. many of us have been saying that's the case for some time all while too many continue to obsess over the "enterprise" when that is not where our bread and butter tends to be, by a factor of 2. still, even 6.5% penetration is pretty good.

on the next page there is a graph showing that some 16% of respondents in an end user survey done in western europe had "significant live use" of open source personal productivity software, with another 7% or so (the graph is a bit hard to read) having "some live deployments" and another 4-5% having "limited live deployments". those are numbers that stack up quickly.

and there there is this graph on page 29 showing the use of foss in european governments as measured in a survey of over 900 such bodies:

kde is used in 10.2% of these places; heck, we're tied with perl for usage. if you add on gnome's 5.5% we end up with a nice foray into the teens for the free software desktop. firefox is doing even better having topped 25%.

and that's where my heart fluttered a bit. because up until this point i was telling myself, "these are places that use kde. these may not be reflective of market share since they may reflect mixed environments." but then i looked at the firefox numbers later on as measured by actual web usage and there it was: the numbers lined up.

the sceptic in me argue that perhaps firefox is more apt to be deployed throughout a governmental department and so the numbers line up, but even then how much could that skew things given the other numbers? it feels pretty good.

and so this was a very nice way to end the week: news of a market where we are making real strides. they even seem to be rather proud of the project, mentioning kde a few times as a sign of innovation and experience in this arena for the european market. even though i personally hail from canuckistan, it still warms my heart =)

i look forward 5 years and ponder what we'll think about these numbers then. i'm betting that we'll chuckle and go "remember when 10% of europe's governments was reason for cheer? ooh, those were the innocent days weren't they."

p.s. today is also the third anniversary (+1 day) of being pronounced dead by eric raymond on an internet radio show. what a maroon =)

run screaming

this upload to kde-apps.org made my day. though i'm not sure that's what people had in mind when they asked for more eye candy. (har, har! "eye" candy ...)

i shudder to think of it actually being on anyone's desktop but the lark of it is pure brilliance, though i figure the instructions sum it up nicely:

1) Make sure you have Python, Qt 4 and PyQt 4 installed.
2) Unpack the KEyes archive somewhere.
3) Run KEyes.py.
4) Run screaming.

run screaming indeed! and to think we have ade to blame for planting this idea.

the discussion on irc went something like this:

[11:50] * dfaure considers doing 4) first :-)
[11:51] my original idea, which I had suggested to [ade], was to be able to switch the faces with RMB->Guru, RMB->Coolo, etc.
[11:53] and occassionly they woould speak . aseigo would say "undulate your wontoness"
[11:53] hahahahaha
[11:54] that would be really creepy and awesome as an easter egg, actually
[11:54] having a little app that will randomly pick the face of one of the devs and play back a recorded clip of something that dev said
[11:54] I think that would be really fun :)
[11:54] yep
[11:54] nice idea
[11:54] my saying would be "hrmph". or " time to walk the dogs"

oh my.

unexpected benefits and sandpaper

while the title makes it sound like i'm going to expound on the heretofore unrealized benefits of sandpaper, i'm not. the 'and' in this case denotes two separate topics.

unexpected benefits: an unexpected benefit of dividing up the libraries in kdelibs into internal hierarchies is that it makes it much easier to work on alternative versions of them. one can now branch just the one subdirectory, say kdelibs/kdecore/config, and work on it. one can even move that branch into the directory next to it with a different name, modify the CMakeLists.txt file in both kdelibs/ and (in this case) kdelibs/kdecore slightly and boom easy parallel devel. swapping one version for the other is a matter of swapping directories about, e.g. config <-> config_new. very, very nice.

and yes, this means i'm back to working on the kconfig update. it's been holding up too many people so i'll be working on that until it is done, barring dev wiki fridays (that's tomorrow folks! join us in #kde-www on irc.freenode.net) and libs mondays (which is on a tuesday this week... again.)

sandpaper: in my last blog i mentioned fixing kurt's bug in trunk/. my intention was not to take away an entry level job (a new coder is actually working on the fix in kde 3.x; i'm really not touching that branch much at all anymore these days). i did it because the printer interface was in really, really bad visual shape in trunk/. it's going to be hard to get people using kde4 as their play-about desktop until things look a little less hamma-janged (as we used to say back in nanakuli =). until people run kde4 as their desktop, even on their non-critical play about systems, it's going to be hard to get real q/a information.

so i was interested: how much hell would i be wading through to fix this appearance? are junior bugs still junior bugs when there is all this mess about?

turns out the mess was pretty easy to get straightened out. i actually got to delete an entire 40+ line method in the process (qt4 now Does The Right Thing(tm), and the old method no longer did. heh.) and otherwise it was "little fix here, little fix there."

for instance, qgridlayout's concept of row and col span has shifted slightly since the initial port was done and so some items were misplaced.

but now things look not all that bad. a little sandpaper applied to the finish was all that was really needed. now, this isn't to say that the printer configuration and manager dialogs don't need work. they could use love. but now i can imagine someone looking at it critically and saying "i'm going to fix that..." and actually doing it. whereas before it really gave the impression of being broken beyond broken, even though it wasn't.

for those of us working on kde4 we need to start taking a moment here and there when we see something truly broken visually to fix it. this will help us get more people developing and testing as they won't run screaming at first sight because the text overlays the icons or whatever.

bonus topic: the oxygen team is gearing up to replace icons in kdelibs with oxygen ones. this includes renaming them in accordance with the fd.o naming standard, and extending the standard with new names as appropriate. i'm excited about that.

why did i even look

when i read kurt's blog about the printer driver dialog i thought "hey, i'm near that code in trunk/ why not pop in a fix for it."

the source of my foolishness? i had just gotten back from yoga and felt ener-friggin-jized. the 7-block walk each way in -20C with strong winds whipping up the snow, skating it down the streets creating trails reminiscent of the those in a wind tunnel, was beautiful, passable but still not enough to take the edge off.

so i fired up kde4, popped open the control panel and immediately thought, "oh. my. goddess. this sucks more than i would have figured." i'll spare you the screenshot.

but 15-20 mins later and it's back in shape and better than ever. (excuse the jaggies and horific rendering in general in the screenshot below; xephyr doesn't run on my amd64 kubuntu box, it just crashes, so i have to use xnest *barf*)

as you can see it's right about back to where it was in kde3 minus the fugly group box and plus a splitter.

to kurt, with love, esme.

hump day

it's wednesday. hump day. and boy do i feel it right about now. i'm still not in an overly communicative mood but there are a few things i wanted to blog about. so i'm going to do a michael meeks impersonation for just this one entry and give it to you ("ung! ooh, yeah! give it to me, ow!" - james brown, RIP *tear*) in bullet list form.

• libs monday was another great success. iconloader moved again just to be funny. ok, really it's because i screwed up and put it in the wrong place. there's now a KIconLoader::global() which does exactly what you think it does. there's also now a KIO::Part::iconLoader() now too for the KParts in the world. hooray.


• this coming monday's highlight is going to be the action merge. third time's the charm, right boys? =) somehow i missed that the merge actually happened. that was pretty smooth. i quite like the more readable api even if there are a few more lines of code here and there; i'm most interested in finally getting to play with the next part of this work: xmlgui++


• dbus tutorials on devnew are coming along decently. two down, one to go. feedback appreciated.


• dell is selling desktop computers with kde on them in china. of course, in traditional fashion the pr states the name of the OS (congrats to red flag! =) whilst kde gets nary a mention. but hey, at least we're helping power those beasts. kde: the software you don't even know you're using.


• kedit is no longer in trunk/. it's been moved to the extragear repository where it will be maintained for kde4 by Bertjan Broeksema. so it will be maintained but not part of the default packages as katepart now does bidi.


• speaking of katepart and bidi, Hamish Rodda is looking for feedback and testing of this feature in kate. so if you need bidi, please hook yourself up with a kde4 install post haste and help the man out =)


• don't know how to get a kde4 install? follow the directions on the dev wiki. there's even a rather nice start to a build guide for macos x


• looks like i'll be attending the red hat fudcon in boston next month. i'll be rooming with kde aficionado and fedora board member rex deiter. i wonder if he knows what he's gotten himself into by offering to share a room with me. ;) i'll be there for 3 days, so if you're in the boston area and want to meet up drop me an email.


• easing back into devel and coordination i'm starting to feel my mojo again. tonight i'm going to yoga in an atempt to keep the blood flowing.


• -16C (the current temperature outside my window) is too cold, esp when the wind kicks it down a few more notches. i don't care what the eskimos were thinking when they claimed the arctic for themselves, no matter how much seal blubber and polar bear that came with that deal, it's just not worth it man.

ok, so that was a rather verbose michael meeks.

all of which are american dreams

today is libs monday. things break. mayhem ensues, such as the alarm not going off and peyton waking me up with 20 minutes to get him to school. so i figured a little rage against the machine would be the perfect mood music today. thus far, it has been. just another bomb track.

the global icon loader moved once again. this time from kapplication to a singleton within kiconloader itself. so now one calls KIconLoader::global() whenever they want that and there are no deps on kapplication. you still need a global KInstance around, of course, just like in kde3. KIconLoader also has become a QObject in the process to handle updating itself when the icon settings change. this should also make handling the lifetime of the icon loader nicer as you can just pass it a parent object.

lots of other activity going on in libs today as well which is nice to see. busy days these mondays.

i tried moving my blog from the old blogger to the new, but blogger isn't letting blogs with lots of content move over just yet. apparently my blog is over that limit. sorry, clee. =/

last night p. pulled out the go game i got for xmas and asked to play a game. i've been teaching him how to play this month. the rules are simple but it's a fairly challenging game of being able to look ahead and see patterns. he can make it through 2/3rds of a complete game or so before losing interest, which is pretty good given the length of the game whose 'action' consists entirely of placing black and white stones on a board. we don't play overly competitive (and i'm not that great of a player in general anyways due to not enough practice); i generally set up little puzzles for him to identify and solve as we play.

as you can see from the follow pic there was also a bit of a star wars theme to it all (those light sabers are freaking cool, btw)

developer wiki friday every day?

[12:47] I think the channel topic should be "The place where it's Friday everyday" :)

that was said in #kde-www on irc.freenode.net the other day, and it couldn't be more true given the fire that's boiling on the new developer wiki. yesterday there was a flurry of activity with over 70 edits and a handful of new entry-level tutorials. the big gun today was matt williams who burned up the kde4 development tutorial, while i counted at least 8 others who made edits. it's great to see people who are evidently reading the content making little corrections and fixes along the way as well.

given that this was wednesday, it really raises the bar for making friday a special day for the wiki. join us tomorrow (friday) to help make that happen. there's still content that needs to be migrated from other website and, of course, new material needed.

it would also be great if those projects who have a large number of interesting materials on their own sites (i'm thinking of projects like kdeedu, koffice, etc) could start bringing their materials over. even just a few articles migrated a month from your respective troves would in a short few months lead to a nice re-concentration of information that will serve the target audience, developers looking to learn (or remember, as the case may be =), best.

also, so far pretty much 100% of the new content on the wiki is c++ centric. understandable, but not really what we want. much better would be to have python, ruby, etc articles. i've spoken with some of the people working on kde bindings and they are very supportive of this. it would be great to see people in the pyqt/pykde and korundum communities joining us to author some content.

kiconloader

had a slightly rougher than usual week in the personal life segment. additionally school is out for winter break until this coming monday, so i also have the p-man around full time. it's certainly nice: we get to cook together, put lego together, watch movies until 2 in the morning, etc.. but all told this week's personal load is putting pressure on my ability to concentrate and work uninterrupted.

this didn't stop yesterday's lib tuesday from rocking pretty hard though. there were several people who showed up with their own bits to add. olivier goffart did a ton of work, for instance, on further de-guifying libkdecore. we've been discussing on kde-core-devel what to do with the last few bits that remain; it looks like kconfig is going to be the biggest remaining blocker, which means i have a really, really good reason to finish up the work i started last year on kconfig since it resolves most of the issues already while finishing out some of the design goals of kconfig, such as pluggable back ends.

one of the major changes that happened due to my hands yesterday was moving KIconLoader out of KInstance. previously, if you created a KInstance you got an icon loader too. but the icon stuff relies on various bits of gui stuff (no surprise there, really) and so got moved into kdeui/icons. what now for apps that need an iconloader?

well, instead of doing either of these things:

KGlobal::instance()->iconLoader();
KGlobal::iconLoader();

one would now do

kapp->iconLoader();

this looks like more of a change than it really is. in the previous case you needed a KInstance. calling the static method in KGlobal had the same requirement. so now KApplication becomes "the KInstance for GUIs".

i did consider making KIconLoader a singleton, but it would still rely on having an existing KInstance around and that just seems to be better communicated by having one access it via a KInstance (in this case, KApplication). moreover, it's not uncommon to have more than one icon loader around in the case of multiple components (e.g. kparts or plugins) that have their own icon search paths. so having a singleton pattern could be a bit misleading.

but there is a remaining challenge to this: what do kparts, ioslaves and plugins do now? in the past they'd create their own KInstance and then do something like:

instance()->iconLoader();

now they need to create their own icon loader, such as:

m_iconLoader = new KIconLoader(instance()->instanceName(), instance()->dirs();

this has become a fairly common idiom while porting the kde4 code base over. which led me to think about creating a KParts::Instance class which restores the old behaviour for these cases: a KInstance with a bundled KIconLoader, much like KApplication does.

seeing as it will be pretty much exactly the same code as in KApplication, i'm further considering creating a small interface class with those few methods needed to Do The Right Thing(tm) and have KApplication, KParts::Kinstance, etc inherit that interface. this would allow me to centralize the code in one place and ensure the naming is consistent. this means KApplication would MI from QApplication, KInstance and this new icon loader access interface thing. not sure how i feel about that exactly =)

kdelibs tuesday, sonnet

it's another kdelibs tuesday. the big things happening that i'm aware of today are:

• the removal of a number of ui-dependant components from kdecore (moving to kdeui) as we get closer and closer to a kdecore that doesn't need to link against qtgui or x11. sweet


• the new model/view based uiserver gui for kio jobs feedback by rafael fernandez lopez


• dlg -> dialog


• lots of nice little cleanups and tidy-ups

right now i have to go fix the build in the modules that have been broken by the above api changes ... hopefully will be done by lunch time-ish so i can spend the afternoon on other things.

there was an interesting blog entry about sonnet, the new spell and grammar checker in kde4. it features a lot of cooperation with the abiword people and should be a nice set of improvements in the text checking areas of kde. the blog entry is worth a read =)