ebn and docbook sanitization

on my recent blog entry about kde api dox metering on ebn, frerich raabe posted a really interesting comment about docbook and ebn. it was too good to let languish in the comments section, so with his permission i'm "promoting" it to its own blog entry:

I'll take this opporturnity to point out the way which the DocBook Sanitizer on EBN visualises the results of the nightly runs.

The site consists of a few "navigation" (each of which mainly consists of a table showing some 'product' and the number o issues in that 'product') pages and lots'n'lots of "reports" for the individual application.

The page for KDE 3.5 gives you the totals plus the issues within each KDE module. Note that this table can be sorted by clicking on the column headers: in particular, clicking on the "Issues" header will generate a nice "curve" of bars (the length of each corresponds to the relative number of issues), which gives a pretty good idea of whether there are a few really nasty modules or whether it's spread relatively even over them.

Clicking on e.g. kdenetwork shows you the stats for each application - clicking on each application shows you the actual "report", where you can see which checks it did, whether/what failed and (in case something was b0rked) telling you why you should care about what the report says. ;-)

Since all of those pages are generated from the very same PHP Script (which in turn reads all the information from a SQL database), presenting this information in other formats is quite simple to implement. For instance, at the bottom of each page you will find a link to a corresponding RSS feed, which contais the same information as the page you're viewing.

Since those RSS URLs actually refer another PHP script, you can just stick them into your favorite RSS aggregator (*cough*KNewsTicker*cough*) and they will always be up to date.

Okay, enough advertising. :-)

thank's frerich!

for those who aren't familiar with him, frerich is the fellow responsible for knewsticker (the only news feed app that comes with it's own desktop environment! ;) among other things in kde. these days he works over at froglogic which is very cool little company staffed by a number of kde "old timers".

poverty: everywhere and unfunny

as a child in a single-mom family with a deadbeat dad and then later living in an economically depressed community in the united states, i grew up in and around poverty. one learns to go without, to find other things to keep one's self busy. it also becomes rapidly apparent that poverty is not an issue in some far and distant country: it's right here, right now. and it's not about lazy people, stupid people or "bad" people either.

fortunately for me, my experience with being poor was head and shoulders above what most people in this world endure. that's a pretty sobering thought. in any case, i moved on and live a decent life these days (for certain values of "decent" anyways ;)

the other day, via a friend's website i came upon this blog title "welfare mum". it's one woman's story of leaving a bad situation (abusive, alcoholic marriage) for the betterment of her and her kids but being left relatively poor along the way. she's on welfare, working and going to school so she can get back on her own two feet again. for those who have never been through such a thing, it can be quite enlightening to read about what its like. if nothing else, it helps one realize how fortunate most of us truly are. i also came away remembering how hard some of the people in this world work and struggle just to make ends meet in an honourable way.

"welfare mum" even manages to do volunteer work to help others in even worse situations than herself. this makes me ask myself, "what am i doing for my community? what can i do for my community?"

300+ schools in namibia

chatting with uwe thiem via email today about an article being written in a mainstream south african computer magazine about kde, he happened to remind me with one of his interview answers that kde is currently used in over 300 namibian schools. i know it's been covered before on kde's official news site but it's easy to forget about things like that.

over 300 schools. that's thousands and thousands of children. wow.

i know in the "big scheme of things" (aka the millions of economically valuable systems in "enterprise installations") that's not earth shatteringly important. but in the little scheme of things (aka "humans being not just doing") it's pretty hard to top.

side note: my cat has taken to insisting on drinking water out of a glass. preferably a pint glass. ffs.

autostarting apps in kde4

the what

as an application developer, you'd like your program to start up automatically when the user logs into their desktop. usually this is because your program is a desktop service type of application that should run from the time the user starts using the computer until they are done, such as a clipboard manager, password caching system or calendar notification daemon.

the way of accomplishing this has been standardized on freedesktop.org for open source desktop environments running on various unix flavours, but it has been generally left up to application developers to each follow that standard on their own. moreover, it really doesn't do much to answer the portability question.

in kde4 there is a new class that addresses this issue: KAutostart

the how

using KAutostart is intentionally pretty simple. for instance, if your application is already registered with the autostart system on the platform, to make your application start up at login one would simply write:


KAutostart autostart("myapp");
autostart.setAutostarts(true);


this assumes your application is set up for autostart already, however. on unix that would mean installing a .desktop file to $PREFIX/share/autostart/. but if you want to be rid of all of the details of dealing with .desktop files directly and would like to ensure future portability, you could do something a bit more thorough, like:


KAutostart autostart("myapp");

if (!KAutostart::isServiceRegistered("myapp")
{
const KAboutData* aboutData = KGlobal::instance()->aboutData();
autostart.setName(aboutData->programName());
autostart.setExec(aboutData->appName());
}

autostart.setAutostarts(true);


to check if your application will autostart the next time the user logs in do this:


KAutostart autostart("myapp");
bool willAutostart = autostart.autostarts();


KAutostart also reveals further features, some of which are KDE-specific, in the autostart process such as start phases, executables to check for as an autostart condition, which environments to start the application in or not and more. see the API documentation for complete coverage of all the bells and whistles.

the why

up until now, if an app wanted to engage in the wonders of autostart they'd just provide a .desktop file that looked something like this:

[Desktop Entry]
Encoding=UTF-8
Exec=huzzaboo
Name=Huzzaboo!
Type=Application

and throw it in $PREFIX/share/autostart during application installation ...

well, this produced several problems that have cropped up as the open source desktop has matured. first, there is the issue of multiple desktops. if everyone installs their autostart entries into, say, /usr/share/autostart then you can only imagine the lovely mish mash of kde, gnome, $RANDOM apps that start up, often innapropriately.

we do have OnlyShowIn= and NotShowIn= so if something is kde-only (e.g. the kde panel application: kicker) you can restrict it that way.

but what about apps that might want to be run on any desktop? (that would cover most apps, actually). usually we only want this to happen if the user starts that application up explicitly or if it's the "home" environment for it. today we recommend either using OnlyShowIn or NotShowIn or shipping with Hidden=true in the .desktop file and changing that to Hidden=false when the app is first run by the user (or configured to autostart). not exactly pretty.

and what happens when we change how autostart works (such as introducing a setuid binary that is responsible for handling new autostart requests for security purposes), or the app is ported to a platform that handles autostart completely differently? how will kiosk integration be handled?

the KAutostart class is intended to address these issues. by using it in your application you can avoid having to provide a .desktop file at all if you wish, which will help ensure portability or future proofing. as the autostart mechanisms evolved within kde, so will your application's use of it.

the disclaimer

KAutostart is a new class. the API will certainly evolve on its way to being an official part of kde4, so the contents of this article will probably change as well. i'll keep it up to date and eventually publish an official article on it.

(p.s.: yes, i'm abusing my blog as a way to start writing documentation about the bloody thing. blogging i've come to grips with. i'm still working on documentation writing. so sue me.)

random()

just threw p.'s laundry in the dryer ... he puts his laundry in a little cart which he designated as his laundry cart some time ago (it's a little toy supermarket buggy) and puts it out by the door to the laundry whenever it gets full. i never taught him this, he just figured it to be a good idea and rather enjoys doing it.

i always thought you had to teach kids that stuff. nah, i thought you had to pound it into their heads, threaten them with the removal of desserts and what-not. apparently not. you just need to give them some half-decent guidance in their (thankfully relatively simple) lives and enough creative space to explore things.

he's also started reading more on his own now, recently having put it together in his head that letters go together to make sounds and strings of those sounds make words ... and, for anyone who has met him can attest, he knows how words work so the rest is pretty easy from there. this was another aspect (education) that i thought might be challenging. but he's picking up some reading skills at kindergarten and his mom and i have been doing is reading to him, helping him along with his adventures in sounding things out and encouraging his writing/reading with praise and interest (which, i'll admit at the end of some particularly hard days, is a huge effort (and one i probably sometimes fail at))

when i first discovered i was about to become a father some 6+ years ago i was pretty concerned about the effort it would require to properly raise a child who had any sort of chance in hell of having a good life: lots and lots of hours, lots of Doing Things Just Right(tm), etc ... turns out it's pretty simple, though the lots of hours (hardly noticed, though) is generally true.

but even on days where i feel particularly drained, like today, i can certainly attest that it's all worth it. but please don't take that as a call to go out and populate the world like some modern day adam or eve. there are enough people here already; we need to learn to take care of what we have first. were i to aquire another little life to complicate my own up some more, i'd probably adopt.

(p.s. i had something of a backlog of drafts in my blog. just noticed that today. so some of these postings are a few days old. but unlike good bread, they don't stale quite that quickly. or maybe they're like bad bread: stale when they leave the oven. ;)

kicker mellows; krita heats up

fixed a couple of bugs today and a few more yesterday in kicker 3.5, many around the new-in-3.5 "lock panels" feature though some (such as the "don't show kicker tips if there's an app in fullscreen mode) are just usual polishing type fixes.

anyways .. locking. if you haven't noticed it, there's a new entry in the panel context menu which is available by right clicking on a clear area of the panel, on a button or on an applet handle.

when "lock panels" is selected, you can't accidently move buttons, applet handles disappear, context menus shrivel up ... this (admittedly inspired by MS Windows) feature was really easy to add since kiosk support was improved in 3.5 fairly dramatically. you can now lock down individual buttons, applets, panels, menus, etc... so turning on "lock panels" simply activates kiosk controls at run-time.

unfortunately this was a bit of a "blunt instrument to the head" approach as it meant you couldn't drag objects out of the kmenu onto the desktop (one of the kiosk controls), right click menus on kmenu entries disappeared (instead of just shrinking to remove "add to panel") or drag new items onto panels if it started in locked mode and then you unlocked it .. you get the idea. it seems the "lock panels" feature is fairly popular because just about any possible screw up with them was reported in the last few weeks. which is great, i really appreciate the time taken to provide feedback.

and now because of those reports things work much more smoothly as the panels now differentiate between being locked via "lock panels" and via kiosk in certain key areas. it still uses the kiosk framework for everything, which really shows the flexibility of it.

something i've been toying with is the idea of making the arrows that are added to buttons that show menus when clicked shown on mouse hover or when the associated menu is being shown only. obviously the arrows need to be there as they are a nice visual cue that it's a menu not a launcher, letting one know what will happen when clicked on. but do they need to be there all the time? i dunno...



the idea came when playing around with some button stuff for plasma, and at first i thought it was a really bad idea. so i tried it out on my local build of kicker so i could get a feel for it. and i kind of like it =) it makes the panel less busy, doesn't screw with the icons as much and still reminds me which buttons are menus when i hover on them.

if you want to try it out, i've uploaded the patch which applies against 3.5. let me know what you think.

and meanwhile, whilst kicker is mellowing in its old age (no new features, just polish and stability) krita is positively searing hot when it comes to development. a quick glance in my svn commits folder in kontact showed some 400+ commits in just the last month or so. that's impressive!

and it seems to be having a nice positive effect user base wise as well. not only did krita appear on the linux questions 'member choice' awards in the graphics area for the first time it scored 8% of the votes! wow... this is obviously a simple reflection of it improving so rapidly and therefore getting more attention and usage. even this art profressor noted he'll be teaching krita next year (in addition to scribus, quanta plus, gimp and inkscape).

hats off to the krita team ... it's great to see the koffice motor really revving, of which this is but one example. harkens back to the days around kde2 when devel on the then-brand-new koffice was white hot as well.

linux in the oddest places

today i stopped by the datacenter of an old client. they were swapping out the ldap, home dirs 'n local dns box on their network with a new one and since i'd designed that part of their network for them a few years back they asked if i'd stop by before lunch just in case anything went bad so they could ask questions. it went without a hitch and the new machine was humming along quite nicely and the rest of the network was quite unaware of the switch. all they had to do was copy over the right files (rsync is awesome =) and voila.

so they took me out for lunch (it was that time of day, after all) and while enjoying my veggie burger at the unicorn on stephen ave a technician came in to do some work on the golden tee video game machine that was near the table we were at. part of the process involved a reboot of the system and up came ... linux. what's also interesting is that the top monitor is placed upside down in the cabinet and attached to the same computer in some sort of dual-head mode so all the init script text scrolling by was upside down in the smaller overhead screen while it was right-side up in the main video game display.

it also seems they may run X as it entered runlevel 5 and then did the usual telltale switching of video modes on the monitor before snapping up the familiar golden tee logo.

never ceases to amaze me where linux will pop up next.

tricking people is easy, but so is not tricking them

so the boys over at the english breakfast conspiracy network have a cool way of aggregating our failings in API documentation. an oh, mea culpa, are we sinners. or at least so i'd heard. see, i'd never actually looked at it. i know, that's horrible. and eventually it ate at my soul (or what's left of it) and i just had to go look. or maybe i was suffering from insomnia that evening. guilt, insomnia ... whatever.

anyways ... here is what i found.

boy, they look like log files. now, maybe this is why i'm not a sys admin (wait, no that's because i generally dislike dealing with the average human being in their daily attempts to stuff up the network as quickly and thoroughly as possible; i prefer writing the applications they enjoy using in their attempts to stuff up the network as quickly and thoroughly as possible), but i have to say i really don't like log files. they take so long to go through and figure things out in. *whinge* *whinge* *whinge*

but you know what gets me going? besides a hot date or good vegan food (or a hot date with good vegan food .. mm.... hot ... vegan .... foood....

...
*drifts off*
...)

ah, where was i? right.. hot vegan food. what also gets me going are graphs that give me good overviews along with the ability to drill down and search and see progress in the components i work on. if the ebn stats were pretty like that, i'd probably be very easily tricked into using it and getting my api docs into order.

but the log files trick me into running away to blog instead. and lord knows i don't need to do more of that.

to ade, with love and squalor, aseigo... *kisses*

p.s. adridg / ade / adriaan de groot does a lot of great things for kde. he takes on a lot of what i'd consider "shit work" but does it with great gusto and an amazingly wicked sense of humour. he also spent several years in calgary at one point in his life (though not at the same time as myself). the canadian kde conspiracy continues!

there's a hole in my sock, dear liza, dear liza

have you ever gone to a an important meeting wearing socks that were, shall we say, in less than prime condition? you know, those ones with that hole in the heel or the big toe? i'm sure lots of us have, either intentionally or otherwise. thankfully we usually get away with it because people tend not to care all that much about the continuity of our socks. perhaps if you are going over to someone's house where the custom is to take off the shoes it could be a little embarrassing, but otherwise who cares, right?

it's a trait of technical communities to fixate on the proverbial "hole in the sock". engineers and software developers are notoriously bad for this, largely because that's what we get paid to do: our livelihood comes from being stupidly picky and detail oriented, hunting down bugs that turn out to be one-character typos, obsessing over the precise algorithms used, etc ...

so it's often hard for us to step back and look at the pile of bugs we call software and honestly say, "wow. that's pretty damn good." there's always some way it could be better; and for sufficiently complex software there's usually some defects. so we tend to fixate on those holes in our socks, even when the rest of the outfit is pretty damn tight.

so, when are these problems holes in our socks versus, say, holes in our heads? that's a good question; the answer depends on the context. while a bug is a bug when developing the beast, it's ok to say "wow. that's pretty damn good" if it actually is.

people who follow my blog may notice that i occasionally go all creamy about a certain feature ... say, printing in kde, for instance ;) ... those who spend more time around me also know that i incessantly bitch about those same bits of software. there are times i look at the holes in the socks and they piss me off, particularly when it's my code ;), but there are times when i figure it's time to step back and look at it with some perspective.

why does it matter?

maybe it doesn't. i know it makes me feel slightly less stressed out about the things i'm doing if i give myself that space once in a while to appreciate the upside of the efforts put into it, and i also know that being able to say "this is what it's good at" (and do so honestly; lying about that is a completely different thing) is a far more effective way of introducing people to your work than saying, "yeah, i know the shirt and pants rock and the shoes are gorgeous, but... let me show you this hole in my sock..."

(p.s. the song i borrowed from for the title is actually "there's a hole in the bucket". but even though the topic was metaphorical socks rather than buckets it still seemed like a good idea. well, for certain values of 'good')

better than watching paint dry: watching widgets paint!

with qt4 we got the much anticipated arthur painting engine/system. then we got the backing store which provides nice double buffering everywhere and makes things like transparency and other effects like fading in widgets rather easy to do well. well, here's another cool trick that's come along with the backing store: QT_FLUSH_PAINT.

what does it do? it shows you what's being painted by first filling in the about-to-be-painted areas with yellow:

move your mouse around, interact with things and you get a good idea of where painting is happening, such as here where i was mousing over a toolbar button:

since painting is expensive and something that really impacts the experience of using software (flicker, latency, etc) this can be very useful to see just how well your qt and kde apps deal with painting, particularly if you have custom widgets.

best part is that it doesn't require any recompiling or fancy footwork: just export QT_FLUSH_PAINT=1 and start the app from that environment... for the above shots i simply went to a konsole tab and did `QT_FLUSH_PAINT=1 assistant`.

enjoy.

(and speaking of enjoy, the season finale of battlestar galactica kicked ass. so much so that i'm really not happy i have to wait until the fall to get my next fix ;)

hump day

well, it's hump day again: the middle of the week as marked by wednesday. did a bit of kde4 porting work today as kdelibs_snapshot was updated due to hamish rodda's huge reworking on kaction. the gap between qt-only code and kde code is diminished, we have fewer kde-specific lines of code to maintain and this will likely pave the way to other nice things like giving us a path forward for (or even away from) xmlgui as it currently is.

this update means a lot of stuff in trunk/ doesn't compile again, so the more people working on helping port the better =) the next big change in the pipes that i know of is the improved internationalization support that the localization team has been working on for a while now.

today i received my brazillian ... travel visa ;) so i can make it across the border legally in april. huzzah! given when i mailed the forms to them and how long canada post takes to deliver registered mail i'm guessing they turned the app around in ~10 business days. not bad =) george staikos apparently had a bit of a harder time with the process, but since he applied before i did i'm going to assume he paved the way for smooth sailing...

i had to re-book my flights for the qt developer roadshow event i'll be attending. i was supposed to be in chicago then houston, but now it's just houston. since they had purchased non-electronic tickets i had to drive to the airport today to get them changed. if you're in the houston area and want to hook up for a dinner or drinks one evening (i've got two free evenings, i think) let me know =)

it also appears rather likely that zack will be popping up for another visit next month. given that the kdelibs reorg is just around the corner, it looks like it'll be prime hunting season for plasma.

also of note: the technical working group (twg) announced today a slight relaxation on feature commits for 3.5 so that patches that already exist and are well tested can go into 3.5 as long as a few conditions are met (e.g. not breaking other freezes such as string freezes, must already be developed, must get some testing in an independent release, etc) so the next couple of releases of 3.5 should be more interesting than usual. they did remind everyone that the prime target is still kde4, of course, and that's where we are putting our main efforts.

changing my name ;)

ok, that's it: i'm changing the spelling of my name to "siego" and as an extra bonus for the boys at lug radio (and 90% of people who introduce speakers at conferences) the official pronunciation from "s-EYE-go" to "SEE-ay-go". there's just no point in resisting when people are so wonderfully consistent in sticking to their preferred permutations.

today is also the first day the year that has felt like spring. well, at least to me. but i've been spelling and saying my name wrong for years, so what do i know? ;)

get cozy with cmake

in the last few years we've moved to a number of new project tools such as bugzilla and subversion to support new needs due to growth and dissatisfaction with the existing tools that were used. few people really enjoyed working with autotools, either, but they were what was available.

in prep for kde4, we had no less than 4 different build tools supported in the code base. two (make and unsermake) used autotools, but the other two didn't: scons and cmake. due to developer interest in cmake (e.g. people were doing the work to make cmake support a reality) and the active support of the cmake development team, it now appears that we're moving to cmake for kde4.

now, i hate build systems. like popcorn kernel husks that get stuck between my teeth, they've always somehow found a way to annoy me. hopefully cmake eases that pain, but i have to admit i have been hesitant to spend the time learning this new system. fortunately, alexander neundorf has written a nice intro text using cmake to build kde4 code. it looks pretty straightforward, though i'm sure there'll be more details to add to that howto over time...

in any case, thank-you to all those who are working hard at liberating us from autohell.

slow launch times? blame drepper.

so i came across this little gem of a thread on the bin utils list from last october. in it, openoffice hacker michael meeks provide a fairly extensive patch that improves start up times dramatically for c++ apps that rely on dlopening libraries. what kind of apps might benefit from that? well, openoffice and pretty much every kde app for starters. and how much of an improvement does this patch provide? it achieves somewhere around twice the current performance. yes, that means that many apps would start up twice as quickly (though not all, of course; there are other things that can wreck start up time ;)

we have a nicer fontconfig start up profile, lots of optimizations happening in the desktop applications and libs and it's all helping; wouldn't it be nice to see this patch in the next glibc and binutils releases? well, keep dreaming for the time being because ulrich drepper, the maintainer of this package, apparently doesn't understand the patch and is letting it bit-rot. rather disappointing to see such an improvement that would help so many projects in a real-world manner get blocked due to one person acting as a (blocked) bottleneck in the process.

apparently some distros are going to be rolling out binutils/glibc's with at least parts of meek's patches, but that's hardly the best way to go. here's to hoping someone wakes up and gets this contribution pushed into upstream so everyone can enjoy the benefits of it, including users of red hat linux who happens to employ drepper.

KAutostart, KPresentationControls

future proofing and cross-platform assurances seem to be pretty high on the kde4 list of things to accomplish. take phonon for instance: it's giving us an API that allows kde4 apps to use different media backends without backend-specific code polluting them. so as media backends change both between platforms and over time, kde4 apps are protected.

i think this can be extended to other scenarios, including much more trivial ones. i have two classes on disk right now that fall into this category: KAutoStart and KPresentationControls. the latter's name sucks; i just haven't thought of something better yet.

KAutoStart allows apps to, you guessed it, register an app to autostart or not in a platform independent way. well, right now it only contains code appropriate to unix/linux systems following the xdg specs with some extra kde goodness sprinkled in there, but it hides it all behind an API. this guy will be making it into svn (pending necessary blessing) on monday; i just have to finish the unit tests for it.

KPresentationControls right now wraps screensaver deactiviation and eventually will be extended to cover other things one might want to deactivate when showing a video, fullscreen audio visualizations or a slide presentation (as three examples that leap to mind right now). these "other things" would include turning off desktop notifications (e.g. passive popups), network messaging services (so you don't get potentially embarrassing IM popups when in front of a crowd *rolls eyes*), etc.. not only are the ways to do this different from platform to platform, but they even change on our "home" platform of X11: frederikh just recently contributed a patch to x.org that adds an api for screensaver activation. for x.org's that have these, we'll be able to use that (more efficient and correct) way of doing it and for those that don't we just fall back to the usual "send a fake key event every 55 seconds" approach.

i wonder what other sort of system services need wrapping ala phonon, solid or these two classes? and i wonder if these "system services" classes should be in a separate library or wrapped into kdecore or...? hrm.

i heart kde: printing and playing media

if you had asked me a half-dozen years ago what i thought about setting up printers and media playing on linux i would've said that it was in a miserable state and the future looked rather bleak.

well, yesterday i had the opportunity to use a closed source operating system for a bit and discovered that kde and linux have progressed to the point where we are kicking some ass when it comes to these two tasks.

sure, we need to install binary codecs post-install to get media playing working, but once that happens ... holy crap!

apparently windows media player isn't on its own able to shift the audio or video streams in case of a clip where the two streams are out of sync. while it seems you can get 3rd party tools to help with this, i like how the media players i have installed for kde support this out of the box thanks to xine and mplayer. huzzah. windows media player also does a craptastic job of scaling video from a usability perspective; it's far more intuitive with the kde players: just resize the window.

it also reminded me of a situation at a lecture i attended last year where the presenter wanted to show a video clip on the overhead from their laptop and ended up struggling with windows media player for a good 15 minutes to get it working properly. would've been quicker for me to have driven home, grabbed my laptop running linux, drove back and hooked it up ...

as for setting up printing, it's no contest. setting up a network printer under microsoft windows is the most unintuitive thing i've seen in a while. our printing system in kde, thanks to the kde-print hackers (hey michael!), are simple and easy to use. the scanning feature in particular is a winner. a recent kde convert remarked how straight forward it was to set up printing compared to windows, and i have to agree. printing to pdf is also pretty sweet. all that's really needed at this point is some polish to some of the dialogs (e.g. the setup dialog for scanning starts out too small by default, resulting in a line edit that's too short to hold a network address) and more hardware vendor (IHV) support in the form of quality drivers and q/a testing.

side note to jim gettys: next time you decide to comment on printing support (or any other desktop sub-system) in public as you did in december, try catching up with the state of the art. printing guis on linux are pretty damn good at this point.

of course, this begs the question why people seem to have so many problems with these things still. the answer, i think, is pretty obvious: right now everyone plays the part of their own systems integrator. given a properly installed kde on linux or bsd system there just aren't that many problems left that aren't IHV related.

house party

went to a house party last night. haven't been to one of those in a couple of years, actually. seeing as it was t.'s group of friends, there were a lot of tech people there.

in fact, the host of the party is a sys admin at a local printing company. their printing systems are all controlled by linux and they use kde as the gui on all those machines. i found this out during conversation when someone asked what i did and i started to explain and during the explanation asked if they'd heard of linux (yep), then kde (yep!). it just keeps popping up everywhere =)

of course, they aren't using it for "corporate desktops". the front desk systems, for instance, are all windows. but they wouldn't consider using anything else for their printing systems apparently. interesting how diverse our user base is.

i also managed to talk to a software architect from intuit. we talked about cross platform applications. result? well, we have a long ways left to go with isv's to help them see the value in writing applications that are easily portable (or even cross platform) even if they still target primarily windows right now.

there's a lot of fear, uncertainty and doubt out there about the future of open source desktops ("what if the company that makes a given library goes out of business?"). there's also a lot of short sightedness currently ("linux isn't on our radar.."; me: "and what is your plan once it is?"). there's a lot of confusion over cross platform development ("writing cross platform code is too expensive and difficult." me: "well, perhaps ten years ago, but today " him: "yeah, it was probably about 10 years ago that i last looked at it"). there's also a lack of recognition that not getting on the platform sooner rather than later that they may end up having no place on the platform (witness scribus and page layout apps)

these are all educational issues. we know we aren't doing a good enough job in this category, but last night's conversation helped confirm that for me.

to make up for it a half dozen of us jumped into the hot tub sans clothing. it was freakin' cold outside but the water was awesome ... ah.. nekid hottubbing. =)

call on me

if you've ever questioned why you'd want to purchase and get comfy with a yoga mat since you don't do yoga ..... i suggest watching the video for "call on me" for inspiration. even if you've never asked yourself that question, i recommend the video. i swear that the guy in that class is a thought leader in the field of male fitness. damn.

there is no year of the linux desktop

listening to jess hall's interview on the linux link techshow tonight (which i quite enjoyed, btw, jess =) i grimaced inside when a question was asked about next year being the year of the linux desktop.

this bad boy really needs to be put down: there is no year of the linux desktop. and there never will be a year of the linux desktop.

see, every time someone spouts off about this mythical year it just gives more fodder to the doubting thomases and plain ol' anti-open-source-desktop people. and i don't blame them: it amounts to crying wolf.

this is because not only has it not yet happened, it never will. it's a matter of slow growth over a large number of years. we've been doing this for a little under a decade now and have just recently gotten the serous attention of big movers in the industry. open source on the server didn't take the world by storm over night either (except for categories where open source was one of the only mainstream solutions available from the beginning, such as in web serving or mail). these things take time and constant growth is all that matters.

and we're doing that, but all over night success stories are years in the making. ;) so please, for the love of $DEITY, let's stop this "year of" nonsense.

instead, why don't we concentrate on the positive and real growth we're experiencing instead of wanking off at the tongue about some "year" that won't materialize? i think in part it's because our growth is hard to see. when a new deployment happens, we usually don't know about it, whether that deployment is one machine in someone's living room or 5000 machines in a fast food chain. this is because they don't have to come to us begging and paying for licenses: they can just use it and do so without getting involved with upstream people like kde. and the linux vendors are generally tight-lipped about sales. but growth is happening. i know this first hand from traveling and seeing what's happening on the ground in the places i go. it's amazing where open source desktops are popping up (and it's generally not "the enterprise")

sebas from the kde marketing working group is attempting to fix that with better market research, and i hope he succeeds because we could really do better if we knew who our user base really was and no, it's not mostly the wonderfully important vocal minority who reads our blogs; that segment is a small part of our user base, though very valuable. and besides, what fun would blogging be if nobody read it.

it'd be like trees falling in an empty forest. *meditates*

heeeere's barbara!

when i blogged about kde needing someone to help organize event attendance i thought it was an outside chance anyone would show up for duty. well, i should doubt less. we have a great community, and often times people just need to know they are needed, welcome and (given some effort) appreciated.

barbara irwin, who also does the lots of linux links website, volunteered to be that person. and i have to say i'm might impressed. not only is she a fellow canuckistanian (and she lives in one of the most beautiful parts of canada, imo: vancouver island), she's already doing a bang-up job of collecting and categorizing our events. it's no small job, but she's whittling away at it and making good progress.

now if we can just get the event management module working on spreadkde we'd be golden... and apparently there's been a volunteer step up for that, though i know for a fact that tom needs more people to help out with this great initiative. hopefully the other spread* projects (firefox, gnome, openoffice) will also chip in efforts to improve this shared infrastructural bit of software so we all finally have more kick-ass tools.

is it wednesday already?

holy crap it's been a while since i blogged. a combination of being busy and just not being in the "sharing my life" mood this last week or so. i've really been enjoying my time home and having a more quiet, private existence again. anyways, enough about me (i can already hear the "booooring!" from homer simpson in the back row)

i rearranged the konqueror tab context menu here locally a bit:

very small changes but it feels just so much more right now. it's more in line with firefox's menus (though that wasn't intentional; i checked w/firefox after i made my changes. huzzah for thinking similarly). the idea is that reload is probably next most common after new tab, and that all the tab manipulation items belong in a menu section. so it's a bit more orderly and there is one less menu separator.

but i'm hesitant to commit this to a stable branch though: changing UI elements from minor to minor is crappy, but i'm also unhappy to let 3.5.x continue on with a crappy menu here. i'm torn!

i've also whipped up a class for kde4 called KAutoStart which abstracts away the process of adding/removing applications from the autostart process. i'll be committing that this week to trunk/kdelibs/kdecore/, though i need to touch base with seli about what he's doing with the autostart phases. he has improved them for kde4 slightly and that may mean we don't need start-after anymore.

it occured to me that a similar class for screensaver avoidance would be good. i'm thinking of a class that you new and delete only, and on creation it prevents the screensaver from flicking on and stops doing that when you delete it. sort of like a mutex for the screensaver. i just see a number of kde apps doing this manually, and once we get some standard mechanism for doing this (e.g. via ipc, standardized on fd.o, supported in x.org) our apps won't have to change any code. until then we can just provide a fake key press event mechanism.

these little utility "abstract away a specific system behaviour" classes ought to, imho, be thrown together in a module in kdecore once we divy that stuff up.

besides tracking down and killing yet more bugs in 3.5 in kicker (along with matt broadstone), kconfigskeleton and kmail, i've also been working on kconfig, which needed more work than i anticipated. but the result will hopefully be better than what we have: multiple backends (including pluggable ones), configuration of backends done in /etc/kderc (and hopefully one day /etc/xdgrc?), ldb, elektra/uniconf?... and tobian koenig suggested a nice way to get change notification on the cheap which i'll try and get right ;) and seli provided a number of interesting optimization suggestions. we'll see what comes out of all this (besides me becoming way too familiar with kconfig internals ;)

and finally, i've also been hacking on kaffeine here and there. they have a new startup ui in svn that i think is a nice improvement:

it's still a bit busy in places, but getting better compared to previous releases. it's also the only kde vid player that i can get to do everything i need right now (such as play video fullscreen on my laptop screen and external monitor simultaneously). but there are some issues with it still: the systray icon on by default, screensaver prevention that is always on when kaffeine is on (rather that just when video or fullscreen audio visualization is on), sub-optimal config dialog and lack of kconfigxt (== no kiosk support in the config dialogs and more hand coded stuff in the app). in return for allowing me to turn off the systray icon by default (which is not something most people need or want for playing video) i'm helping fix those issues. there are some other bits of UI improvements that could be made, but i'm trying not to get overly involved in kaffeine hacking as i have enough other stuff to do. and i think christian is doing a pretty nice job here anyways in incrementally improving things in noticeable ways.

i'd really like to see this app get more exposure as well since it is rather good and i noticed it wasn't even up for voting in the recent linuxquestions.org member's choice awards nor is it often mentioned in the "video app" category where it most naturally fits. (yes, i know you can also use it to play audio)

other stuff on the burner include looking into kross for making it easier to open up plasma to scripting languages. i really wish people writing new frameworks would include decent design concept documentation so it didn't feel like reverse engineering so much of the time. we must improve on this in kde4. no ifs, ands or buts on this one.

doing the 180

attention all organized people! i bet i've lost 90% of readers right there ;) but seriously, we have a small organizational need in the project that could be easily filled by someone who is good with dates and following up with people who has a few hours a week to help out with. there are a number of tech shows that we really need to be at each year and organizing our attendance is currently left up to certain developers; in fact, it's usually the same half dozen or so of us year after year.

we don't particularly organize our efforts in this regard, people just charge after whatever they can when they can. some people have adopted specific shows and try and do them every year. others step up when the call is made, etc. as you can imagine, due to this non-robust mechanism, events fall through the cracks.

we could really use someone who could reliably maintain a calendar of the more important events, get in touch with the event organizers 3-4 months in advance of the event and arrange for a booth (we generally get them for free being a "dot org") and some speaker slots and then turn around and help organize the developers: ensure someone is set to go to the event, that presentation proposals are submitted, etc. this is just one more of those "non-developer task" contributions that is so valuable to the project.

if you are that "someone" please get in touch with the kde marketing working group (emailing kde-promo@kde.org is probably a good way to do that) and you'll probably be an instant hero with them.

starting tomorrow i'll be temporarily living on german hours to remotely attend the e.V. board meetings happening there. i just couldn't manage the travel this time around; i'd seen enough airports for the first 2 months of the year. so i'll be up at really odd hours (and sleeping for part of today). =/

i spent half the day yesterday tracking down a bug in kconfigskeleton which would prevent kconfigxt generated objects from being used as simple "setup 'n save" config objects due to reading in default values rather than actual values on addItem(KConfigSkeletonItem). the original problem reported was "kmail's reply phrase tab can't be changed once you change it once". it was a long journey from there to libkdecore. i sent a patch to waldo for review for application to 3.5.2.

think tank?

a group of 70+ people got together in santa clara recently to discuss open source and called themselves a think tank. they published a report titled SDForum - The Future of Commercial Open Source Think Tank Summary Report.

i started reading with enthusiasm, then came to page two where they list their "major findings". but if this is what they "found", this is less of an open source think tank and more of an open source think bicycle. here are their findings, with my comments following each:

• ISVs will look and conduct business very differently than they do today and will be much more dependant upon services revenue: ok, perhaps this is news for ISVs. though if one looks around, you can already see it happening. so this is a safe bet in my books, though probably a decent "finding" none-the-less.


• Many of the legal concerns around open source licensing will be resolved or fail to come to fruition: given sco's brilliant lack of success, the lack of other legal threats arising (remember when indemnity was a hot topic?) and even microsoft bitching about patents this is another safe bet.


• Open source is not a business model in and of itself: uuuuh ... maybe by "finding" they meant "we looked it up on google" because this has been common knowledge for many, many years


• Open source will be a standard, core element of most compute environments
  Like Linux, open source will achieve ubiquity: ok... riddle me this, batman ... how can linux be ubiquitous but open source not when linux is open source and therefore a sub-set of all open source software? maybe they just worded it poorly, in which case it's too bad the english language think tank wasn't there.

reading on it turns out the event kicked off with the head of va software (the company that used to do open source) reminiscing about chatting it up with eric raymond. oy vey. at this point i debated closing the document and pretending i hadn't already wasted 10 minutes of life. but on i trudged.

and then the clouds broke, the sun poured down upon my eyes and i broke the code: this wasn't an open source think tank! this was executives from places like bank of america getting their head around this odd new animal called "open source"! reading through the break out sessions it was mostly a series of "well, of course!" type non-revelations, but the fact that the men in suits are starting to be able to come up with these things on their own now says we've come a long, long way towards getting the message out. if managers understand it, it's essentially mainstream (some might say that means it was mainstream a couple years ago ;)

the coverage of doc searl's presentation was worth the read as well. as usual, it sounds like he did a great job of presenting the concepts in a clear and impactful way.

the document wrapped up with agreements, disagreements and potential obstacles. the latter were a mix of hilarity and good points. i wonder if they meant it that way. maybe next time they'll invite a couple of us unwashed developer types they opined so much about in their report to join their think tank session. i think both would get a lot of out of it. they'd get some real insights into the current and future directions of things, and we'd get some real insights into their needs, expectations, hopes and current levels of understanding.

take that sweden!

sure, sweden may have won gold in hockey. and they may have produced abba. but norway is not about to just lay down and let sweden take all the glory, oh no!

not only is norway home to trolltech (which sort of somehow makes up for the hockey thing) but they've arranged the definitive answer to those dancing queen abba poofs: behold! hurra torpedo!

don't miss them performing their, uh, "hit" single cover of total eclipse of the heart. it's inspiring. you'll want to dance to it, make love to it, destroy the kitchen stove to it. they even have their own rockumentary, replete with groupie girls, roadies, busted gigs and moron tour managers.

take that sweden!

(and now you know what i did last saturday due to it being too cold outside to comfortably do something more meaningful)

i wonder if hasbro makes aslag guttormsgaard action figures?

in related (and yet .. unrelated) news .... for valentines peyton made these cool little heart encrusted envelope things with a fancy, glistening plastic sleeve in them for both his mom and me. in the sleeve was a cd with a really great (and even thematic) song by ben harper on it: "everything to me". he even drew up cd covers for them. the kicker: the cd's are burned. apparently one of the teachers or someone brought them in. apparently in canada we teach children how to express their love and "share" music on that hallowed day in february.

take that riaa!