i am posting this from inside a wallabee wallaby

since lions have already been done, i decided to hop inside a wallabee wallaby for this one. i'm sitting in its pouch typing away. yes, i am that tiny, especially when i suck my gut in and hold my breath. the wallabee wallaby, however, remains unimpressed.

(if you're wondering what the above is about, so am i. i'd heard of jonah and the whale before, pinnochio and the whale, captain ahab and the whale (man, whales got such a bad rap in literature), dogs inside of snakes, snakes inside of airplanes and airplanes inside of naval vessels (to keep the free association there going) ... but not until now had i heard of ades inside of lions. once i had, though, i just had to get into the $PERSON in $ANIMAL bandwagon. i'm a hopeless follower. no animals were harmed in the making of this blog entry, though the wallabee wallaby continues to be unimpressed.)

my sleep schedule has been completely messed up this week. more so than usual. maybe it was the appearance of Zack. he has that kind of effect on people.

i took him to the airport this afternoon as he has a company meeting to be at in Spain. i'm hoping he'll come back to Calgary when he's done there, but that's all still up in the air.

the good news is that we made progress with quasar, huge progress with packages and webkit in plasma and ate tremendous quantities of kick ass vegan chinese food. you may not care as much about the last bit of information there, but without that .. there would've been less code written, so in a way you probably do care. (the wallabee wallaby has just informed me that it doesn't care and that i've got another five minutes for this entry, max.)

between sleeping (or, rather, often not) at the oddest times and being busy writing code and driving people to school, airports and what not i have been ducking communicating with people (so if i owe you an email or a phone call: sorry, i'll get to you over the next few days here) as well as avoiding doing that screencast. i really wanted to be able to show more of the cool things that we were working on actually working properly and what not, so kept putting it off. well, Zack's gone and things work so it's time =)

i'm going to ping Danny to see if he's interested in including it in the next commit digest. if not, i'll post it here instead. if he is, then it'll appear on the weekend in the commit digest.

in the screencast i show kickoff, installing plasma and webkit packages through the Add Widgets dialog, webkit based widgets (two kinds: one with plasma and one with MacOS apis) and a little bit of quasar stuff.

it's this kind of productivity that makes me ponder what would be possible if there was a little villiage somewhere that i and others like Zack could hang out in, enjoy good food and just hack on free software all day. well, enough pondering for now, my time in this wallabee wallaby is up.

good day, love and hugs.

animating lots of things simultaneously

there's a new game in kdereview right now called kdiamond, writted by Stefan Majewsky. it's a fun little game that is much like the classic bejeweled. with any luck it'll move from kdereview into kdegames for 4.1.

while playing it, i noticed that sometimes the animations weren't overly fluid. this was something that others had noticed as well. i did a quick valgrind and saw that the actual drawing and game mechanics code wasn't really significant, though there was a lot of time being spent in driving the event loop. without even looking at the code i could guess at the problem: each diamond on the canvas was animating itself. indeed, that's what was going on.

i wrote an email to Stefan suggesting a fix (which he implemented very quickly; sweet! =) and Zack suggested that i should write a blog entry about this general issue since it may be of use to others as well. this is that blog entry. there's nothing new or even overly interesting to graphics developers, but for the rest of us ... it might be helpful.

so... why is it so nasty to have individual items animate themselves? the obvious approach to animate a bunch of items is to give each item a timer (e.g. QTimeLine) and move the animation along in time to the progress of the timeline. in the case of moving an item, this is a simple matter of taking the start and end points, the current progress of the timeline (e.g. from 0.0->1.0), figuring out how far along the item should be on a given path between the two points based on the progress value and setting the location. the math is trivial and everything gets nicely encapsulated in the animated item's class.

here's the problem, though: let's say that the item is being animated at a nice smooth 25 frames per second. that gives us a 40ms delay between frames. (that's an oversimplification: the delay will vary depending on actual system activity and other processing in the app itself, but let's go with this generalization for now.)

if we have two items animated then we have that same 40ms window, but now it is divided into two pieces averaging 20ms in length. (the real intervals may be 10ms and 30, or 6 ms and 34ms, or whatever; again, this will vary from interval to interval ... but the average in the oversimplified scenario is useful information here.)

obviously, as we add more and more items, if the distribution is somewhat random (and in practice it will be) then our time slice between animations gets smaller and smaller and as we approach 40 items we end up with an animation happening every millisecond (again, going with the oversimplified generalizations). over 40 items and obviously we're into the sub-millisecond range. the problem, however, is not in animating the movement of those 40 items (that's probably very fast) ... it's the "in between" part that causes us grief.

with every item having it's own timer, each animation step of each of those items implies going back to the event loop, checking the next timer and if it's scheduled to trigger emitting its signal (or put another way, calling the connected methods) and then returning to the event loop. suddenly there's a lot more time variance and the animations will start to appear sluggish and completely uncoordinated as the individual frame timings drift about. but that's not the worst of it.

what's really bad is that while in the event loop other things will happen. really expensive things, like repaints. using a canvas such as QGraphicsView, it will eventually decide to update its contents on one of those trips to the event loop and trigger a bunch of repaints. if this happens when N out of M total animations have stepped through their frames, then not only will you get a paint with some of the animations in step and some not, but a (relatively) huge delay will also be introduced as all the data structure traversal, math and then resulting painting necessary to update the canvas happens. while fast in the general case, this can end up being detrimental to the fluidity of the animations if triggered too often and without coordination with the animations.

besides canvas paint, user interaction events and other input data processing will end up getting in between the individual animations. it just all gets very messy and animation frame latency starts to suck.

(firing all those timers randomly without aligning them is also rather bad for power consumption as it wakes up the cpu more often, but for most apps doing animations that's often not really a priority issue.)

the solution, thankfully, is really quite simple: share an animation tick. this is nothing new, really, and has been done in graphics programming since the days of yore, when the grass was green and amigas were still impressing people with that stick figure guy juggling three ray traced balls. ;) but it's still something that i noticed gets missed, especially as more people are adding them to their apps, often for the first time.

how it works is really simple: most animations are simply updating an internal state and then using that state to affect some sort of visual change, such as the start/end point interpolation of the above movement example. so you start a single timer that triggers a step forward in the animation ("the next frame" or "a tick") and on each of those ticks every active animation is iterated over and their state is incremented (whatever that means for the given animation).

in this way the event loop is exited and entered only once for all the animations. upon re-entering the event loop the scene or canvas is free to update itself with all the animations having been updated and ready to go in a coordinated fashion. so for each 40ms slice there is one animation tick, the time required to update the animations elapses (that should be very fast, even for good numbers of items) and then the repaints needed can happen.

the end result should be a lot smoother and just "feel" better since things will be moving together at the same semi-random interval rather than each at their own semi-random interval.

loading random widgets

one of the main things i worked on today was support for loading widgets plasma doesn't know about at build time. this is to allow us to load various sorts of widgets that aren't appropriate or possible to stick into libplasma itself.

all widgets are, at their most basic level, housed within a Plasma::Applet. libplasma itself provides support for native Plasma widgets, aka "Plasmoids". a Plasmoid is a collection of scripts, images, configuration, UI and widget specific data files that are bundled up together into a package.

the package itself is defined by a PackageStructure which informs a Plasma::Package what should be and what could be within a given Package.

Package provides the ability to install the package locally, query the packages, fetch a given resource from them, etc. Package is how we are able to list non-c++ widgest in the Add Widgets dialog, among other things. now, Package is nothing like the packages that software applications come in for your operating system (e.g. rpm, deb, pkg, tar.gz, etc....). they are both simpler and more about accessing resources rather than managing installation (though Package does that) and calculating dependencies.

this system is all well and good for Plasmoids, but what about other packages ... like MacOS Dashboard widgets? or any other widget of this style, for that matter. the widgets have their own structures; while Package can handle this it does need a way to get at the package structure. so Package can read the structure of a package from a config file. unfortunately, this isn't enough: some widget package formats are just stupid and have no predefined structure whatsoever which makes dealing with them far more annoying and code-laborious than necessary. yes, MacOS widgets are in that category, and as such can't easily be codified in a config file without adding some flexibility that would amount to a description language of sorts.

so rather than subject myself (and those who would use this) to that sort of pain, Plasma::PackageStructure can now also be provided as a C++ plugin, giving us all the flexibility we could every hope for, need and want.

the end result is that when a widget (regardless of type) is accessed (installed, listed, opened, etc) it looks like any other widget to libplasma based applications.

behind the scenes when the Package is loaded, Applet looks to see what PackageStructure it uses. if none is defined, we assume it's a native Plasmoid. if there is one then we look for a plugin and if that doesn't work out then we try for an installed config file description. assuming that goes well, we now have the PackageStructure, which directs Package, which provides a standard interface to Applet, which makes all widgets look the same to libplasma.

neat.

the last bit of work i have to do here is to add Package install pre-processing for widget archives (most of them are just zip files) so that when the user installs a new widget we can create the proper metadata that Package needs and deal with whatever compression system the widget uses. this is the easy bit, though, compared to getting the above working. once it is done we'll have the full round-trip from the Add Widgets dialog (via Get New Widgets) to disk to applet listing to desktop/panel/etc placement.

over the weekend Zack got WebKit based widgets working, both "native" plasma ones as well as MacOS widgets. the native plasma widgets have access to things like DataEngines from javascript embedded within the webpage. this is a little different from the qscript plasmoids where the javascript is stand-alone and is the widget for all intents and purposes; with the webkit based widget the webpage is the widget and javascript to manipulate it lives inside the webpage itself.

the Dashboard stuff basically came along for free. it was neat to watch the hello world, clocks and Chuck Norris MacOS widgets load up and work without any prodding. we will need to provide some additional javascript API that some dashboard widgets assume to exist, and we'll likely never be able to satisfy the macos bundles bridge that is available on MacOS due to how tied into the platform that is but thankfully few widgets seem to use those.

there are patches upstreamed for WebKit that are required for this to work, so until they hit qt-copy the code will remain in playground. we also ran into more of the same WoC (widgets on canvas) bugs with the web applet support that we had already run into with the general WoC porting of libplasma. gotta love living on the edge of development ... constantly. ;)

and the screencast will have to wait to tomorrow, as p. is back and fast asleep in bed. i don't want to wake him; in fact, i should probably head to bed soonish myself as i have to get up at 07:00 to get him off to school.

i haven't forgotten about you

what a jam packed few days. tons of work on kickoff, zack's been ripping it up on webkit integration in plasma, import of quasar to playground with some initial work on it towards the direction we want to move it, getting kconfig backend plugins to actually work, krunner matching improvements (some of which required a bit of hacking on the sycoca query language), the port to WoC patch is shaping up (not my work, i'm just the reviewer) and sooo much more .. including going out with zack in the evenings to dance and what not .. it is the weekend after all and p. is at his mom's.

we're going out again tonight and i'm way to mentally tired to do much other than enjoy it not thinking ..

tomorrow i'll be putting out a screencast showing some of the stuff we've been poking at. but i wanted to let you know that i hadn't forgotten about you, the reader of this crazy thing i'm told is called a blog, and that i still think of you fondly at night. ;)

a simple but amazingly useful contribution

today i wanted to set up a key shortcut so i did what has become natural for me: alt-f2 (to pull up the krunner window) and type "shortcut".

nothing.

ok, so i try again: this time i try "keyboard". keyboard layout, keyboard accessibility preferences, system wide key mappings ... no keyboard shortcuts. damn.

how about "keys"? kde3's input shortcuts, kde4's keyboard shortcuts and accessibility. yes! there is it! but .. no. it's the kde3 kcm. uh-oh. why did i have to guess three times? because KServiceTypeTrader's syntax doesn't do what i want. so i've fixed that (commit pending approval of syntax addition on kde-core-devel) and now typing "shortcuts", "short", "keys", etc returns the shortcuts control panel but ... "keyboard" still doesn't work! why?

because "keyboard" does not appear in the keywords for that control panel. doh!

this problem does not just affect krunner, but also system settings (and kcontrol when/if someone finishes the kde4 port of it), search indexers (e.g. strigi, beagle, etc).

but despair not! an industrious soul or two could save the day by going through the control panel .desktop files and audit the keywords. this is something anyone who can read and write english (that's you!) with a text editor (also you!) could do. interested? the read on to find out how!

in $PREFIX/share/kde4/services/ there are .desktop files that represent control panels. i've put a tarball of them here (it's 255k in size), though you could also find them on your local kde4 install with `grep kcmshell4 *desktop` in $PREFIX/share/kde4/services/. if you grab the tarball, uncompress it somewhere locally.

i'd recommend making a copy of the original set for each diff'ing later on.

then open a .desktop file and do the following steps:

1. find the Exec= line


2. run the command (e.g. `kcmshell4 xserver`) and take a look at what the control panel actually provides


3. go back to the .desktop file and find the Keywords= entry and add to, remove from or modify the list of phrases. the list is separated by commas and entries can have more than one word.


4. save your changes

repeat until you're tired, bored or happy that you've done your part =)

now generate a diff between the old and the new version (this is why i suggested to make a copy of the directory above). you can do this with the `diff` command line application, e.g.: `diff -u kcms.orig kcms > kcm_keyword_changes.diff` (without the backticks). this will leave you with a kcm_keyword_changes.diff file that you can then email me. i'll apply your changes from there to svn and searching for control panels will become that much more accurate and easier.

we have a general policy of including the contributors name in the commit log message when merging contributions, so this is your chance to get your name in KDE's hall of fame commit logs. ;)

leaving, coming and hacking

zack arrived yesterday; p. left today; we hacked all day, then had dinner out and hacked some more. i spent my time trying to make kickoff a bit more pretty and less broken feeling in a few places (so much more to do though), working on virtual desktop awareness in Plasma::Views so that we can solve some of the interesting problems that come with compositing windowmanagers and to make it easier to do per-desktop effects in Containments and answerin gtons of email and going through patches on review board.

zack's been working on webkit<->plasma integration (after finishing some "day job" work he had to do). interestingly someone has made webkit paint a white background ... no matter what. this is Obviously Broken(tm): it really should be up to the host application/widget to decide what the backcground is (in a web browser white makes sense, in plasma is makes as much sense as me hitting myself on the head with a hammer as hard as i can just to find out if it hurts or not) so he's trying to track that one down in the code base. fun.

so an effective day, if not a change-the-world-day. getting closer to that though ;)

oh, and Celeste, if you have questions you can ask them on panel-devel@kde.org. much more likely to get a quick and informed answer there than on your blog, to be honest. in any case, the answers you're looking for are: those are both TODO items for 4.1. the point of zooming is to allow switching between Containments (which the user will know as "Activities") and eventually discovering network offerings (e.g. via zeroconf). c.f. Jeff Raskin's ZUI work, which i'm sure you're familiar with.

if you're wondering why we shipped it with 4.0 even though it doesn't have all the features, here's why: we recieved a number of interesting bug reports that pointed out various flaws in the basic zooming system that have all been fixed since. release early, release often, have fewer bugs in the long run.

and again, panel-devel@kde.org. house of goodness, if not pancakes.

convenient quiet days

been somewhat quiet the last few days, doing mostly maintenance coding type stuff. monday was Family Day here so everyone had the day off, then yesterday p. and i kicked around and what not: it's the only day of his spring break that we'd have together just the two of us. today i pick up Zack from the airport (in about 3 hours) and then tomorrow p. flies out to see his mom. so this morning i'm doing some housework and prepping for the movement of bodies in and out of the house =)

with zack here and p. gone until next week we should all sorts of time and focus to get to working on some of the harder issues ahead of us. i've also been looking through qt 4.4 more this week to gather some ideas of what we can do. for instance, items on the canvas can now have "window decorations", sort of like real dialogs. which is, in fact, really what the applet handles essentially are, except that they only appear on hover and aren't like real window decorations in the services they provide (rather different use cases after all). so it looks like i may be able to get rid of some of the larger, but previously necessary, uglinesses of the applet handle code by using this new facility.

on the review board front, we have 6 items on the board that are marked for committing, several of which have been sitting there for a few days and one of which doesn't really belong there. so if by tomorrow after p. has flown out those patches haven't been cleaned out and applied, i'll be going through them and doing so myself.

family day

today was family day, a statutory holiday, where i live. the p-man has the whole week off from school and will be visiting his mom in vancouver in a couple days during his time off. this will be nice for all involved, particularly he and his mom. Zack arrives tomorrow, the day before he leaves, so it'll be lots of visits to the airport for me over the next week.

the p-man went to visit a friend today while i visited with his friend's parent (singular, so many single parents in canada; lots of single fathers, too; i seem to remember reading something about canada having one of (the?) highest rates of single fathers in the developed world?). that was nice as the sun was shining and the snow was melting away.

i did find some time to hack today, and spent that time refining the AbstractRunner API further so that it's a bit easier yet to write runners and more memory efficient at that. the API had sort of evolved a bit "naturally" over the last year and so this time spent combing through it has been well served.

items are sorted much better now, combining exactness and relevance. i haven't yet added in runner priority, but that will be next. along with some tweaking in the runners themselves, the sorting is already much more sensible.

a couple of the guys (tagx and hydrogen) have been working at porting Plasma::Widget and Plasma::Layout to WoC over the last couple of days and apparently are nearing success. with that behind us we can charge forward with expediency with new features and more bugfixes.

the 4.0.2 backports have been settled in and seem to be working well. thanks to ruphy for the backporting barrage and binner for helping ruphy get everything compiling and working in branch.

if you are running kde from the 4.0 branch, your feedback is very desired to make sure this huge amount of backportage didn't break something subtle. i have a 4.0 branch checked out and compiled, but i run trunk/ daily, which makes it harder for me to notice subtle breakage in 4.0.

tomorrow, another "falling in love all over again" entry.

quickies

• in case you haven't already seen it, the Software Freedom Law Center released a Legal Issues Primer for Open Source and Free Software Projects. it's a little Amerocentric and certainly a primer or overview rather than a exhaustively detailed document, but quite worth passing around as a great introduction.


• the 4.1 branch (aka trunk) has moved to Qt 4.4. it's going to be an interesting time as we adapt to things like Aliens and WoC. some issues have already arisen, but are getting addressed as we rebuild with 4.4 and start testing. some of the bug fixes are very welcome, though, such as QSvgRenderer not leaving gaping margins where they aren't supposed to be (the bane of the panel painting in plasma, krunner and plasma popups) among many, many others.


• i'm suffering from the sinking-in-the-gut-feeling i get now and then when i look at my TODO list at the early part of a devel cycle: so much to do! finish up Plasma::Service, port LayoutAnimator to Phase and merge it with Layout, WoC, timeline, widget snapping, zooming, extenders .. hopefully i can get it all done for 4.1 with a little help from my friends (cue the music, you know which song!)


• we're holding a plasma developer sprint in April in Milano, Italy. Ruphy will be playing host and KDE e.V. is helping with funding travel (full disclosure: as a board member, i obstained from participation in that decision due to obvious conflict of interest). 4 days of plasmaing, right in the middle of the dev cycle... sweet!


• i've been distracted by krunner more than i had planned on this week. trying to kill my 4.1 desires as quickly as possible so i can move on to plasma. krunner gets lots of interest, but not too many people hacking on the core of it. it's not that complex and actually a lot of fun to work on. i need to do a webcast of krunner soon, i think.


• ktorrent for kde4 is working out rather well, except for a crash i'm getting when selecting "Download" directly on a torrent file instead of saving it first to disk then openning it. i need to update my svn and if the problem persists, report a bug (or if it's a trivial issue, just patch it =)


• the deep freeze has left Calgary, at least temporarily. it's actually 9C and sunny outside. so much nicher than the -10 to -40 weather we've had for much of the last month. my mood has improved commensurate to the temperature.

KDE Utils: Falling in love all over again

Today we're going to look at the little tools in KDE4, or at least some of them. There are far too many to be able to cover in one blog entry, and so I've decided to cover a few of the ones that I personally use and which have had visible improvements over their KDE3 counterparts.

What blog about software would be any good without screenshots, right? Documentation also requires screenshots, and both patch reviews and bug reports are helped when accompanied by screenshots. Sounds like we need a good screenshot tool to take pictures of our desktops, and thankfully KDE4 comes with one of the nicest ones around: KSnapshot.

KSnapshot in KDE4

As in KDE3 we have a picture of our snapshot on the left (which you can drag and drop), our main controls to the right of that and our snapshot settings at the bottom. As in KDE3 (and just about any KDE application), you can save your files to a remote system (that's how I got the snapshots online for this blog entry, in fact) and KSnapshot lets you define how you want your snapshot taken. Don't want window borders? No problem! Need X seconds to set up your perfect shot? Can do! If you put a number or a date (!) in your snapshot name, it will auto-increment it for you on your next take. Such a handy little app.

It sports four snapshot modes: full screen, full window, section of window and region. The "section of window" is very cool in that it allows you to click on an area of a window, such as a toolbar or the document area, and it will grab just that portion of the window. So far, other than the nice Oxygen stylings, things are the same.

In KDE3 there was one recurring theme from users of KSnapshot: "we want more control over the final result." Some wanted to print (which was supported in KDE3), others wanted to crop, put drop shadows, annotate .. and on and on. If the KSnapshot maintainer, Richard Moore, hadn't been careful KSnapshot would soon have become a full image editor! What to do?

The print button was removed and replaced with an "Open With" button which lists every image manipulation application that is registered on your system. So with one click you can open your snapshot in Gwenview or Krita or KolourPaint or whatever app you want, really (sure, go ahead and edit it in KHexEdit ;). From there you can manipulate the snapshot to your hearts content without restrictions. This decision helped keep KSnapshot itself small and focused in its mission.

Another nice touch in KDE4 is the region mode. In KDE3 you could grab a region of the screen, but there was virtually no feedback as to what was going on while you did so. Not any more!

KSnapshot in region grabber in action

When you click "New Snapshot" a little timer (which, of course, follows your colour scheme! ah, details!) appears in the upper left corner counting down the seconds left until the snapshot is taken. When in region mode, once the time has run down to zero a snapshot of the whole screen is taken and you can now click and drag an area to snapshot. The selected region remains clear while the rest of the screen is grayed out, as you can see in the screenshot above. You don't have to get it right the first time, either: little translucent drag handles appear on the edges and corners of your selection that allow you to adjust the selection to your heart's content.

It is that one feature alone that has me falling in love all over again with this handy tool that I end up using so often.

KSnapshot isn't the even the beginning of the parade of small tools in KDE4, though. Take KCharSelect, for instance: in KDE3 it was very, very basic and very, very cryptic. You could pick a font and it would list all the characters in it. And I mean all. So if you were looking for the copyright symbol ... you could be hunting for a while.

KCharSelect in KDE3 .. a wee bit cryptic

Besides allowing one to pick both the font type and size to peruse, KDE4's major improvement comes in the form of search and metadata in a more pleasant layout:

KCharSelect in KDE4 .. much nicer!

Selecting a character will give you some information on it in the information panel. The information includes details on the character itself, it's representation in various formats such as XML/HTML encoding and even cross references to related characters.

Where this gets really useful is when using the search bar. Located at the top of the widnow, the search bar allows you to sift through this text quickly. Typing "copyright" at the top brings up all the characters which have the term "copyright" in their information blurb. Finally I can find special characters quickly and without even necessarily knowing their exact name! I love it!

For those large Unicode fonts which may have hundreds upon hundreds of pages of characters, KCharSelect allows you to define the set pages you'd like to look at. This is done via a pair of selection lists right next to the font selection. This lets you select a font, a size and then narrow down which characters are displayed by simply moving through the fields left to right (or right to left if using an RTL desktop).

For quick note taking, KDE4 comes with KJots. If you want a full-meal-deal kind of note tool, I recommend checking out Basket. It's an insane app that can do pretty much anything with notes and does it with an extra helping of style and eye candy. But sometimes you just want a simple note taker (as I often do), and that's what KJots is for. Like KSnapshot and KCharSelect, KJots got its start way back in KDE1 and it still with us in KDE4.

It's gone through a few UI revisions in that time, as you can imagine. It started out as a useful if slightly ugly duckling with a menu listing your note books, a row of buttons at the bottom for bookmarks, and a list of pages in the currently open book on the left. This obviously didn't scale very well if you had lots of note books or bookrmarks. In fact, it gave the app an downright odd use pattern: open a menu (or call up the book dialog by keyboard shortcut) and select a book, move to the left pane to select a page, move to the right to edit; or mouse to the bottom to select a book, uhm, bookmark, move to the left pane to select a page, move to the right to edit.

The file format also left some things wanting: you couldn't have more than one level of pages and no nested books and it was a bit brittle.

When I took maintainership of the app in KDE3 times I cleaned up the UI a bit by harmonizing the navigation into the left panel, added printing, a book overview so you could view all your pages in one scrolling view, proper bookmarking, autosave and cleared up a bunch of bugs.

Then along came Jaison Lee. We met a conference in Ohio shortly after Jaison started contributing patches to KJots and if I recall, it was during the conference that I tricked .. er .. convinced Jaison to take over maintainership of KJots. Under his hand, KJots really stepped up.

KJots in KDE4

He swapped the file format to XML, added rich text editing, made it possible to nest books and added a bunch of other nice touches. Auto-bulleted lists, being able to mark pages in the left side with colours and content search are nice features as well. Pradeepto Bhattacharya and Stephen Kelly are now looking after KJots, so the legacy continues, hopefully for another 10 great years.

The rich text editing alone is enough to make me fall in love all over again with KJots. Colour marking is useful if a bit rough still, the overview HTML looks straight from 1992 (my fault, I take the blame) and could use a nice facelift (any HTML/CSS gurus out there? ;) and being able to add images or other attachments to pages would be nice. Even as it is, though, KJots is approaching a very nice balance of power, reliability and simplicity: the configuration dialog has all of three options in spite of being able to do so much with it!

As a closing teaser, if you've ever wanted to clear out the tracks your web browsing and file editing has left behind, look no further than Sweeper from the KDE Utils package:

Sweeping out my usage tracks with Sweeper

Simple, fast and powerful. Beautiful!

I could go on and on about tools like KGpg or KCalc or ... but I'm out of time. Suffice it to say that there are a lot of very nice tools in KDE4, many of which have improved noticeably from KDE3 to KDE4. I hope you take the time to explore the various nooks and crannies of KDE4 long enough to discover these jewels; remember: KDE is more than a desktop shell and a file manager .. it's also a collection of truly great applications (.. and a development platform, and a community of terrific people, and ... ;)

ktorrent represent

logged into a general interest (read: not free software centric in the least) bittorrent community i'm a part of and they've taken to banning many clients which are just way too broken, as defined by "kills the trackers". in the announcement they say: "Currently, we recommend current versions of : uTorrent, Azureus, Transmission, ktorrent, rtorrent, tomato." (emphasis mine)

aw, look! there's our very own baby, ktorrent, fourth in the list! moreover they say, "Most torrent clients are NOT banned, too many too list." yet ktorrent made the short list. congrats to the ktorrent team, who've created an amazingly flexible client that routinely gives me terrific download rates and all the control i could ever hope for in a very reasonable resource footprint. apparently others are noticing and using it. to think that just a couple years ago there was no good, let alone great torrent client written using the Qt/KDE framework.

i'm building the kde4 version right now to test it out, with hopes i can leave one more kde3 app behind. maybe ktorrent will be the first extragear app to get the "in love all over again" treatment? =)

a quick little update

p.'s been ill the last couple of days. nothing major, just a cough that was bad enough that i didn't want him going to school, both for his sake and that of the other kids in his class. he's great though: very self-contained, will amuse himself for hours and is always up for a game of risk ;) so it's a bit less quiet around the house, but i've still managed to get things done.

i've been working on Plasma::Service which is a compliment to DataEngine: while DataEngine publishes data, Service will allow interaction with things such as online activities (e.g. twitter) and local actions (e.g. media player controls, ejecting media..). Service and Engine obviously need to work together and it needs to be elegant. hopefully i'll succeed =) the reason for not putting it all into DataEngine is that not all Engines have associated Services, and unlike the sources in DataEngine which are one to many, Services are inherently one-to-one (publish<->consumer). it seems best to separate the two.

besides plonking on that i've been smacking down the bugs, from xinerama issues to zooming issues to various crashers in plasma and krunner. i also pulled out a 750+ line patch yesterday to fix a number of layout issues, but that can't go in until monday as it introduces binary incompatible changes in libplasma.

tomorrow p. should be back at school, but i'll be up at the school helping with a field trip in the morning and then have some phone meetings in the afternoon. i plan on fitting in another "falling in love all over again" entry tomorrow, though.

i was hoping to do it on kwrite and kate, but code completion seems to be rather broken at the moment. i've popped a mail off to the devel list, we'll see where it goes. if that doesn't sort itself out in time, though, there are several other options for me to choose from =)

krdc: falling in love all over again

Today's KDE4 application love session is all about remote access via VNC and RDP via the somewhat cryptically named krdc (which stands for "KDE Remote Desktop Client", in case you're wondering).

I remember back in the day when it only did VNC, and did it fairly slowly at that. At least it had a GUI, and it did get faster over time. A real watershed moment was when it gained RDP support: the rdesktop project accepted a patch to make it easy to XEmbed the rdesktop window in another window. This allowed krdc to provide some user friendly window dressing to the otherwise bare rdesktop window.

In fact, I remember applying the rdesktop patch manually to rdesktop and building it from sources before it the patch was available in their repository. I did this so I could keep using KDE on Linux where I was working. I would logg into a Windows terminal server box and using that one pesky Windows-only, doesn't run in WINE, but required app from there. Thank you, Tim Jansen for krdc and the rdesktop team for that wonderful little RDP tool!

Sounds like I was already deeply appreciative of krdc, no? Well, I was. However while functional, the krdc user interface wasn't the most gorgeous thing in the world. It looked like this:

krdc in KDE3

If you are wondering what to put in the text box there, if you clicked on the "Examples" line edit you'd get some instructions. So it wasn't all that bad, and it had a history of the machines you'd previously connected to as well. It could also detect VNC and RDP systems by scanning a given network block. Not bad ...

So when it looked for a while like krdc was not going to get any attention for 4.0 and it ended up rather broken I began to quitely despair. But then: enter the dragon .. I mean .. Urs Wolfer. Urs stepped up and gave it not only some interface love, but also made some important internal changes and added some truly sweet features.

krdc in KDE4

You notice that there's the breadcrumb widget (again!) at the top of the window. You can select between vnc and rdp from the drop down, and type in the address of host next to it. As usual, clicking to the right of the breadcrumb gives you the traditional unadorned line edit.

But what if you didn't notice that little edit? Well, that's where the rather nicer looking intro screen comes from. (And yes, you can turn that off if you like.) It makes it really clear what you can do and clicking on one of the buttons sets up the breadcrumb, pops up a little help box and sets you on your way.

Once connected, though, that's when things start to be a bit different. In the screenshot above, you can see how the start page is in a tab. This is because each connection you make is put into a tab, allowing you to keep multiple sessions open in one window and switch between them easily. Tabbed browsing, meet vnc and rdp. Tabs were my first reason to fall in love all over again with krdc.

In both versions of krdc, as with most vnc/rdp tools, you can switch to full screen mode. In kde4's krdc a rather pretty little widget sits atop the screen in full screen mode offering a selection of tools. When not in use it slides out of the way (though you can also "stick" it open so it doesn't slide out). There was a top-of-screen widget in KDE3's krdc as well, but it wasn't as pretty, nor quite as functional. krdc in KDE4, for instance, can take screenshots of the running session. Easy access to the special key input interface, minimize and other such tools makes using vnc or rdp rather nice and easy.

I also noticed that KDE4's krdc doesn't try and scale connections to lower resolutions in full screen mode. In KDE3 the tendency to scale by default led to pixely slow views.

Speaking of speed ... krdc now uses libvnc to do it's vnc magic. It is noticebly quicker than it was in KDE3, and I'm guessing it's at least in part due to this switch. Speed is goodness, and I love goodness. =)

krdc now also sports bookmarks, session management (so you can restore your open connections automatically when it starts up again) and much more via its configuration dialog. Just as in KDE3, it can use KWallet to store your authentication information as well.

Not all is perfectly rosy in krdc-land, though: the scanning feature seems to have gone AWOL. Hopefully this shows up again, perhaps using ddns/zeroconf/bonjour/avahi/whatever-the-cool-kids-are-calling-it-today. The tab bar also lack the usual new and close buttons on it (these are in the toolbar above instead), the welcome page could be a bit more helpful by doing a bit more than just popping you to the breadcrumb ...

... but given than krdc was without home and master for so long, I'm just happy it got such a solid KDE4 port to get things rolling. Well, that's selling it short, really: tabs, beauty and speed also came along for the ride. Thanks, Urs! =)

TechBase Wants YOU!

Here's when I wish I was a ripping cool artist with lots of time on my hands so I could do up an image of Konqi in a top-hat pointing out of a "Techbase Wants YOU!" poster. You know the sort I'm talking about.

Anyways, near the end of November '07 I wondered idly how long it would take the KDE Techbase technical library wiki to hit 3 million page views after making it past 2 million. Well, that time came and went and the last 2.5 months there have been somewhere around 1.4 million page views bringing the total to date up over 3.5 million. I'm going to stop even reporting on that number because it's just going to get silly. "This week: another million!" ;)

So now we know that Techbase works otherwise people wouldn't keep coming back for more. That means ... we should invest more into the knowledge that is there. I'd like to propose a challenge for all of us KDE hackers:

By the end of 2008, Techbase will have an article for every major component in KDE's development platform

Audacious? Maybe ... we achieved the number of articles already there with far fewer people than are now using it, so I believe this is not only a possibility but a realistic goal. And really: we owe it to each other to document our stuff in a human friendly manner.

I don't think we need an article for every class in kdelibs, but we should aim for articles that cover the major concepts. We already have pretty good coverage of things like getting started, i18n, debugging, KConfig, plugins, D-Bus, Kross and more ... but a lot of the other topics are either just plain missing or only have basic intro materials.

If a reasonable fraction of us were to write even just one moderate length article (1-2 pages of text) per month, we'd make it with ease. This is also something that those learning the new technologies and frameworks can get into easily while providing a contribution that will have a long lasting and meaningful impact on the project.

Personally, I have set a goal to have all the Plasma articles written and ready for 4.1 (widgets intro and advanced, data and script engines, runners, architecture overview). Maybe I'll get to a few more articles covering stuff in kdelibs as well.

So here's the mantra: one a month to Techbase glory! ;)

(.. and yes, in Soviet Russia, Techbase writes you!)

stupid patents

I've run into a few Apple UI patents a over the years while developing software. Their software patents, like most other software patents, tend to be completely inane. They are the sort of things that are obvious to pretty much anyone doing UI development who isn't stuck thinking "WIMP, WIMP, WIMP".

Many of Apple's concepts such as icons stacks, parabolic zooming in panels and (most recently) widgets on media centers that they seem to feel are patentable are either unoriginal or just plain trivial.

The widgets on media center patent filing is dated was granted on February 8 of 2008. Plasma has had a MediaCenter form factor for widgets from at least May 25 of 2007, or nearly a year before Apple's little patent was granted. I'm not so full of myself to think Plasma had to be first to implementing that concept, either.

The only thing in that patent filing we haven't implemented yet that I can see, though we have certainly already discussed it, is linking widgets to specific remote control buttons. Global shortcuts for widgets is already on our roadmap, though, and that's pretty much the same thing, just not specific to a t.v. remote. Really, it's a beyond trivial feature add.

If anyone runs into this patent in the real world and is looking for prior art, I would imagine Plasma just might be it. Sadly, the system will probably be saddled with yet another stupid software patent.

addendum: so this leaves us in a really annoying situation of having to figure out how to work around this patent, unless Apple decides to be nice about it. That would be a nice change on their part, but I'm not sure I should hold my breath.

I've stayed away from the whole patent world long enough to forget exactly how one goes about alerting the USPTO about prior art ... and I wonder if they'd really even care.

Future society will look back upon us and cluck their tongue at how stupid we were for having let the patent system encroach upon things such as software on the one hand and become so baroque a system as to be generally lacking usefulness on the other. =/

gwenview: falling in love all over again

So as I mentioned in my last blog entry ... I've found myself falling in love all over again with various KDE apps as I use their KDE4 incarnations. One of those apps is gwenview, by Aurélien Gâteau.

Luis Augusto Fretes also has an excellent article on gwenview over at his KDE4 blog. It has lots of screenshots and covers some features I don't touch on very much in this article. It's definitely recommended reading!

Up until KDE4, we shipped with kuickshow as the entry in the simple image viewer category. That was originally written by Carsten Pfeiffer for KDE1. Yes, '1' as in 'uno' or 'ichi' or "before two". It was ported to KDE2, KDE3 and even now KDE4. It's really fast and has a super simple interface, though it could a fair number of things like rotate images and crop them. It had an 'xv' style of interface, so was rather comfortable for the X11 crowd. I'm amazed that kuickshow is still with us, having been ported through 2 massive rearchitectures of the KDE API (2 and 4) and one other major release (3). These days, kuickshow lives in extragear-graphics.

kuickshow in kde4

This is because, starting with KDE4 we now ship gwenview as the default entry in the simple image viewer category.

A brief aside: I noticed something while making the kuickshow screenshot ... In KDE4/Qt4, if an app has toolbars that don't fit you get the usual ">>" button. Clicking on it, however, does something new: it animates down a full panel that you can pick from. Soooo much nicer than the old drop down menu!

The KDE3 version of gwenview was feature rich but it was your ... typical KDE3 app. Let me show you a picture to illustrate what I mean:

gwenview in KDE3

Yes, lots of features ... but also lots of toolbars, buttons, controls, viewports without much alignment or immediate clarity of purpose. Now, I really like gwenview and often used it to browse images. In fact, I used it in my presentation two aKademies ago when I did that slideshow of photos of KDE people set to music. But .. yes, the UI could be better.

In KDE4 one of the common goals shared by various development teams was to improve the look, feel and usability of our apps. Did Aurélien succeed? Well, I'll let you decide:

gweview in KDE4

Now that certainly looks better. But is it as functional? As easy to use? Here's another shot showing the app in action (click for a larger version):

gwenview in action

The sidebar certainly jumps out at you: it contains all the common contextual actions at a glance. Select one or more files and then choose from the sidebar. Yes, the context menu is still there but as I often point out to people: when it comes to touch screens, which finger is the right mouse button? ;) Interfaces that don't require multiple buttons travel much better to touch screen devices, extra bonus points for avoiding intensive clicking exercises. Gwenview does well here, and gives me a whole new reason to love it.

Notice the information area in the sidebar? There's a nice little "More..." link there that pops up a window showing more information than you may ever need to know about the given photo. They are organized into a sensible tree and have checkboxes next to them. Clicking the checkbox for any given item adds it to the sidebar in the main view.

You can also expand or collapse any section of the sidebar just by clicking on the headline. Nice for small screens.

You may notice that little slider at the bottom of the window. What does it do? This is actually my main gripe right now with gwenview: that slider isn't labeled, not even with a tooltip. Not much of a complaint for a "main" gripe, especially for a brand new dot-oh interface, but there you go. Well, when you slide it back and forth the size of the picture thumbnails shrink and grow! This was also in the KDE3 version but it was tucked way up in a mid-level toolbar. The KDE4 version does much smoother transition animations for the resizing and the grid spacing is much, much more reasonable. I slip a bit further in love ...

When you mouse over an image, you get a little minibar that fades in. Right now it has three actions in it: full screen, rotate left, rotate right. These are arguably the three most common actions and now they are right there at my fingertips (again, on a touch screen that's literal ;). The KDE3 version? No such love.

So I can scan through my pictures and rotate and view really, really fast. What happens when you rotate or select one of the other transformations in the sidebar? A little "Save" action icon appears in the lower right area of the icon. You can see this in the screenshot above. But what happens if you scroll away through your picture collection? Won't you lose where that picture was? Not with gwenview!

When a picture is modified a little blue bar animates in at the top. The animation makes it noticeable so it isn't lost on the user, but it's not over the top and distracting. The contrast colours (matching your colour scheme, of course) make it stand out just the right amount. In that box you can navigate to the changed picture(s) and if you want save the changes either one at a time or all at once.

So how hard is it to configure this beast? Well .. the configuration dialog is sort of a joke. Not because it's poorly designed but because it has exactly three options: the view background colour and two options controlling how the thumbnails are displayed. All the other items, such as thumbnail size, whether or not to show the sidebar, etc are all done via the interface directly. This is something I've taken to calling "passive configuration", not to be confused with "passive aggressive". The latter is infuriating, the former is liberating. ;)

Other nice features are the now-standard breadcrumb bar for navigation (yes, click to the right and you get the edit bar ... aren't shared libraries cool? =), the crop feature and the rather spiffy slideshow system. The speed is good as well: I never find myself waiting for it to catch up with me.

Where will gwenview go from here? Only Aurélien probably knows for sure (and anyone who might step up to help him). Personally, I'd love to see some sexy transitions in the slideshow, KIPI plugin support to expand the number of transformations that can be done, the sidebar put into a dockwidget so it can be moved around or even undocked easily ... but already with how it is in 4.0 I've fallen in love all over again with gwenview.

Perhaps most impressively, this application is 10,690 lines of code, most of which is in the gwenview library (some 6,822 lines of code). As a reference point, that's about twice the size of kuickshow. Given what gwenview does, how well it does it and how generally sexy the app is .. that's a pretty decent line count.

Obviously gwenview is not a replacement for something like digikam or kphotoalbum which have different (though related) use cases, but for quickly skipping through images and tidying them up ... gwenview is usually my first stop. Honestly, I can hardly bear to look at the KDE3 gwenview now, the improvement has been that drastic.

And that is one of the things that I keep noticing while using KDE4 in my day-to-day. My hat's off to Aurélien .. but he's not the only one. I'm not sure exactly what app I'll write about next: there are so many to choose from! =)

falling in love all over again

Most of the reviews i read or listen to about kde4 tend to focus on the "4 3 hour tour" (yes, that's a Gilligan's Island reference ... *cough*) stuff: they open the file manager, open the system settings, play with plasma a bit, try konqueror, call it day and whip up a report. After the first few times, this gets b-o-o-o-ring really fast.

If I were a journalist at this point i'd realize that this has already been done to death and I'd try looking for something that hasn't already been said. Fortunately for this mythical journalist, KDE4 is immensely deep already, thanks in large part to the KDE3 pedigree that we were able to build upon. So they'd find lots of things to write about if they looked.

I was struck by this as I was doing demos at the KDE Open Day table at L.C.A. last week. I was showing people gwenview, marble, how phonon and solid work together to switch audio over to my USB headset when I plug it in without any configuration, games, koffice and so much more. I realized that yes, I was showing dolphin and plasma and kwin and what not .. but it was a small part of the whole story and the other parts are really compelling: people were amazed at the wealth of apps that are already there in 4.0.

(p.s. to the phonon guys: we need to find a way to stop N notifications popping up saying that the audio is being switched to the headset or back to the internal card; one is enough. Maybe we need something in KNotify itself like the kernel has which compresses repeating messages and just notes that it's repeated N times in the last X seconds? anyways... i digress)

So I thought, why don't people know about these things? Why aren't people telling each other about these apps? Ok, I understand it's more rewarding to bonk plasma over the head for the Nth time and watch me jiggle, or to whinge on about whether or not it should've been called 4.0 (personally, I still like the idea of calling it KDE4 v0.1 ;) ... but c'mon. Then it hit me: people talk about what we talk about and I'm an endless chatterbox, while the people working on these apps I love are .. how to say .. quiet. I respect that, but they deserve more attention for their work than they get, even if they are the quiet sort.

So I figured I'd do something about it by sharing with you how using KDE4 on a daily basis has been for me what can best be described as a process of falling in love all over again with various applications.

Instead of talking about my own little world of thoughts, ideas and what not, for the next while I'm going to push some of my favourite KDE4 apps into the little sparkle of light that is my blog. Maybe someone will pick these up as inspiration and write a series of articles or something. Maybe something for theDot even? Perhaps it's just me, but when i get something new and shiny and exciting I just can't help but share it ... I hope some of you might feel the same way.

Anyways ... on to the first app: gwenview.

growing up and out

when i used to write KDE Traffic (the ancient mutant ancestor of today's much, much better commit digest) it was quite possible to keep up with all the email traffic on pretty well all the kde mailing lists with an hour or so a day. i'd spend one afternoon a week, usually on the weekend, tidying up all those threads and turning out a KDE Traffic issue covering all those mailing lists. it's a slightly different ballgame today, and i can't even imagine putting out KDE Traffic without spending insane numbers of hours on it now.

i've also noticed that i can't keep up with the kde commits mailing list either. over the last 6 months we've averaged 327 commits per day, 7 days a week. this past month that number was 12 higher (~3% increase over average, though these numbers are somewhat seasonal; we were at this rate in the summer as well). it's pretty hard to read through 300+ commit logs per day.

we thrive on peer review, though. it's a big part of how we keep things together with this crazy group of people frenetically coding and committing around the world 24-7. what to do?

well, that's where commit filter comes in. it lets you subscribe to just the projects you're interested in and get those messages. it's yet one more piece of the really cool infrastructure around the kde project, and it lets us all pay attention to just the parts we care to, keeping peer review alive even in these days of 300+ commits.

there's also kmail's filtering that can separate the niagra falls like stream of commit messages into multiple folders.

so if you aren't already watching the commits, mostly out of fear of drowning, you may want to look into the above tools. help keep peer review alive and well!

speaking of useful tools, Frerich blogged about his backporting script that makes porting changes from one branch to another in svn a one-liner on the command prompt. ni-i-ice!

no rest for the wicked

seeing as i'm obviously wicked, that would be me who gets no rest ;) i've been telling myself for each of the three days since i've been back from australia now, "today, i'll just take the day off so i can catch up with my energy." but i keep finding myself wanting to work on this or that and so end up not taking that day off. i did take a nap this afternoon though for about 2 hours which felt .. marvelous.

i checked up on Kevin Otten's student's work on kscd today. they are working in a branch on a pretty thorough refactoring of the application: solid, phonon, a new UI, interesting new features and far less manual configuration required. the new UI is a lot simpler than the old one and is svg themeable. there are still some missing features and bugs, but it works quite nicely and reliable. it feels much smoother than the old kscd thanks mostly to solid/phonon, and once the students get some high quality artwork for the buttons, i think it'll be a nice replacement for what is currently in trunk.

here's what it currently looks like with the draft artwork:

plasma continues to move forward as well. today i took Marco Martin's work on putting the "paint a box using the svg" code that was getting duplicated over and over and over into a class, cleared it up a bit and merged it into libplasma. over 300 lines of code were replaced with about 80 and we now have one central place to decide how we do those fancy little boxes everywhere (krunner, panels, extenders, etc..).

i also modified Plasma::Theme today to react to changes in compositing. Theme already gives out different svg's depending on whether or not compositing is around or not, and now it will switch on the fly. so flick on compositing and you magically go from having this:

to this:

this way people don't have to restart plasma, krunner, etc just because they changed their composite settings.

i also worked this past week on krunner crashes due to non-thread-safe APIs being used from threads. i introduced a "big lock" that runners can grab when they dive into such things in kdelibs, for instance. seems to be working well. returned items are also sorted by relevance now, and when matches are returned if it matches the name they have a higher relevance than if they match the generic name. matching keywords only provides even lower relevance. more work needs to get done on tweaking individual runners for relevancy ratings, but this shows it can be done and is trivial to do: making the Service runner (which fetches applications from the .desktop files in applications/ as well as control panels and other executable services registered with the system) rank things nicely took all of 5 minutes.

for all the pythonistas out there, a set of ScriptEngines that uses kross is being developed in playground right now. it essentially works with some caveats that need to get worked out before we can move it into trunk for 4.1. the ruby support is broken for some mysterious reason that Petri Damstén, whose working on this, is still trying to work out. hopefully he'll get that licked and we'll have ruby support as well. huzzah.

big changes will be coming in the next few weeks, and we have a plasma meeting this saturday to discuss the upcoming issues.

post-review-plasma

looking for an easier way to post reviews to review board i found the post-review script. neat! unfortunately it's not flexible enough in it's default form.

i had to make some changes to make it work properly with our review-board installation and put the results on the intarweb. it probably makes sense to send the changes i made upstream, but i'm waiting on doing that until the changes are put through their paces a bit more. i'd also like to add fetching various defaults from the config file or from svn props, such as the default review group.

the result is that i can now do this from the source tree: post-review -p --summary='Add Containment contextActions() to widget conext menu', and get this as a result. this triggers a mail to the devel list as well notifying of the review request. neat-o!

(the "-p" is for publish; one can also pass "-o" to open in a web browser after submission)

here's how other plasma devs can use this script to save time too:

• download it and make it executable


• optionally put it somewhere easy to get at (personally, i put it in /usr/local/bin)


• make sure you have the simplejson python module installed
  
  
  
  • one click install for opensuse
  
  
  • `apt-get install python-simplejson` for debianish systems
  
  


• create a ~/.reviewboardrc file that looks something like this:
  

  TREES = {
'svn+ssh://aseigo@svn.kde.org/home/kde': {
'REVIEWBOARD_URL': 'http://matt.rogers.name',
'REVIEWBOARD_PATH': '/srv/kde/mirror'
}

}

  
  replace the svn url with whatever you see in `svn info | grep Root`. (support for REVIEWBOARD_PATH is one of the changes i made to the script, btw.)


• go into the source tree and start posting reviews with ease =) `post-review-plasma --help` has some useful information as well

update: using post-update some more i've come to appreciate how efficient `post-review-plasma -r #` is for updating the patch attached to a review.

almost home

i'm sitting in an airport in l.a. waiting for my last flight to get back home. it's late, of course. i realized something on this trip: i'm very, very tired of traveling. i really enjoyed those couple of months of home time and i think i'm going to try and take as much of this year at home as possible. maybe get back on the travel horse again next year.

but i've had enough sitting in airport lounges, which is what i'm doing right now while catching up on email somewhat. a few minutes ago some random fellow walked up and started asking me questions about laptop power cables. i'm pretty sure i'm not wearing my "will answer your computer questions" shirt today, too. yep, i'm wearing my "i'll try being nicer if you try being smarter" shirt. one wonders how overt one needs to be before people leave you alone. ;)

as brad noted, my plasma presentation materials are up online for viewing. the l.c.a people do a really good job of that stuff. it's one of those conferences where the content quality is really high, the organization very smooth and generally good stuff happens.

as an unrelated side thought: when a fully clothed person comes to you and says, "i'm hungry" it is not a useful reply to say, "here's a shirt. problem solved!" the issue isn't that they are lacking clothes, it's that they are lacking food. addressing a serious question or concern by providing an unrelated but otherwise useful response is just not helpful. i see this odd pattern of behaviour so often in the world around me that i begin to wonder whether people are just not understanding the questions or if they are seriously happy to pretend to fix hunger by passing out clothing. personally, i expect intelligent people to do better than that.

final unrelated side thought: i picked up a book of short stories by Roald Dahl. i knew Dahl from his kids books. well, he apparently also wrote very non-kid-oriented stories. they are impressive, if rather twisted, bits of work. people who can switch genres like that are pretty impressive, imho.