oxygen renaming; krunner fun

jonathan riddell put together a nice spreadsheet that maps our current icon names to the new icon names from the xdg icon naming spec. you can find it in playground/artwork/Oxygen/docs/. he based his spreadsheet on one i'd put together cataloging icon usage in kdelibs. seeing as we seemed to be playing leapfrog, i figured it was my turn and, based on his spreadsheet, threw together a small script that does the renaming of the icons in the oxygen theme. i'll be running it over the theme sometime in the next day (whenever the artists give me the green light) and then we'll be on our way to moving the icons into kdelibs.

changing the icon names will be one of those annoying tasks, but there it is. i just wish we'd done a naming spec 10 years ago so we wouldn't be dealing with this crap today. oh well.

if you'd like to help with the kdelibs porting, find me on irc and i'll give you some pointers. it's pretty easy stuff, essentially grepping for KIcon, loadIcon, SmallIcon, etc. and changing the text in there to the proper names as recorded in the spreadsheet.

someone asked for a screenshot of krunner and someone else asked what happens if they had a control panel named the same as a command on disk. well, they say a picture is worth a thousand words:

in the above shot, were one to press enter then the first item in the list would "execute" (whatever that means for the given runner). it's all qaction based, so really anything could happen including nothing if it's purely informational.

gael added a list widget as you can see so we can actually see results returned. it will be replaced with something a bit more bling and useful, but i'm waiting on some art direction for that.

a new background that fits with oxygen is also on its way. =)

there's another half dozen or so todo's with krunner that relate to design issues that i'm going to try and kill over the next week or two and then i'll probably hand it over to a couple of the people who have been working on it lately to flesh out and, if they are up to it, maintain.

text editors: and then there was one

the most recent commit digest reminded me of a nice little bit of news: the base kde installation of libs+base now includes exactly one text editor application application, kwrite.

kate (the app not the part; the latter is still in kdelibs, of course) has been moved to kdesdk since it is aimed more at people doing things like, well, programming. this also means that the kate plugins are moving out of kdeaddons and into kdesdk with kate itself. so if you use kate you'll get all the plugins too.

so a minimal desktop gets exactly one text editor and kate users get more functiona by default. the "multiple text editors complaint" was a bit silly at the best of times, but now there's no reason for it at all anymore.

techbase updates

techbase continues to roll along as well. but as always: we need more content!

i added a bunch of explanatory text to the building kde4 tutorial and condensed some of the initial setting-things-up bits a bit. there was some action on the qt-dom tutorial and a number of nice edits here and there.

the development page needs to be reworked so it looks more like the front page, e.g. a pretty list instead of a blocky table.

danimo installed an image map mediawiki extension so that i can hook up the pretty picture pinheiro did for the isv section.

my contribution this week to tutorials will be on plugins using kservice, kservicetypetrader and kgenericfactory in combination.

krunner update

worked a little on krunner this evening, including integrating a few patches. since the plasma project has essentially adopted this part of the desktop as well, a number of people who were waiting for things to do have jumped on the opportunity to work on this. hopefully this trend passes over to plasma itself as we're raring up that road now and even continues post-4.0.

as of tonight krunner loads plugins at runtime (the stubbed-in search runner is such a plugin) and you can run commands via kservice. which means you can type "Mouse", hit enter, and the mouse control panel pops up. neat.

i also finally implemented the inexact matches bit of the api, so that each runner can display possible matches that aren't exact. it still doesn't show up in the user interface, but you can see them in the debug output on konsole. this way, for instance, a math runner might return an icon of a calculator showing the result of the current text which will (eventually, anywways) get shown in the middle third of the dialog. runners take care of doing whatever it is that should be done by listening to the triggered() signal for the actions it creates.

i've been leaving off the user interface bit for the inexact matches of krunner as i need to both bug the artists for some ideas/concepts as well as decide exactly how to arrange the results. for example, informational "matches", such as the calculator example, should probably appear first in the list.

at the next oxygen meeting (tomorrow evening, i believe) we'll be discussing art needs for krunner so perhaps that will start to address the first issue a bit.

ordering of plugins is another unsolved issue at the moment: what order should runners be called?

so far the non-screensaver/locking/startup code in krunner is less than 900 lines. that includes the runners (3 out of 4 of which actually do something useful =), the display code, the restarting application stuff, dbus interface glue... so i'm pretty happy with that.

if you'd like to write a krunner plugin, just implement a subclass of Runner as found in workspace/lib/runner.h. i need to find a better home for Runner, which may end up being libplasma, actually. yet another thing i need to investigate this week.

i'll be primarily working on libplasma guts (engines) and the kdebase reorg this week, so the krunner stuff will mostly fall to the gaggle of contributors in #plasma who have been hacking on various bits of it over the last week. =)

krunner and user switching

after working through a pile of email today (days after releases are usually more busy in that respect for me) and going through a bit more "how to reorg kdebase" thinking i dove into krunner for a bit.

well, first i did some work on devnewtechbase: finish out the "introduction to kconfig" tutorial and punt around on a few other bits and pieces. discovered we need a mediawiki plugin to do imagemaps, which i need for the isv section and the cool image that pinheiro whipped up. the image is modelled after the "complete product" concept, which inge wallin brought up while he and i were talking about isv and system integrator information issues a few weeks ago.

runners in krunner can now return a list of actions that may match the text entered thus far. so one can type in an exact phrase, press 'enter' and have it work as expected; or one can type away and select from options that will be shown in the middle 70% or so of the dialog. there's a lot of interaction possibilities that open up with this.

i also added some api documentation to the runner class which is now in libkworkspace (kdebase/workspace/lib) so people working on runners can figure out what i was thinking ;) runners are pluggable, well, almost: thanks to work done by gaël ebaudoin it's fairly easy to write a plugin that contains a runner and they are seen (though not yet instantiated) by krunner. runners can also supply matches in an async manner.

an interesting side effect is that when the "switch session" (aka "fast user switching") keyboard shortcut is pressed the krunner dialog will pop up and the SessionRunner populates the list with actions to start a new sesion or switch to existing ones. in other words, the same interface for picking approximate matches for commands or files or * is re-used as the interface for fast user switching. yay! =) i didn't think of this when designing the runner class, but once i came to the problem of having to provide a facility for fast user switching, which kdesktop used to do by showing a popup menu in the middle the screen, it was the immediate and obvious answer.

if i get to work on kde stuff tomorrow (it is saturday, but that doesn't mean much really ;) i'll start hooking this all into the krunner interface. so that one can actually see what's going on behind the scenes. then i can put away my mind/computer interface and start using my eyes again ;)

once the runner api is proven a bit more i'll write a tutorial for techbase so people can go nuts:i really don't care to write every possible runner myself (e.g. a calculator, contacts integration, etc), i just care to make it easy enough that other people will ;)

this may also become a place to try out the scripting strategies we'll be putting into plasma on a smaller scale. "smaller scale" usually means "easier to get right, and fix what you get wrong", so that could be a useful exercise to avoid bigger pain as the tricker needs of plasma are handled.

and finally: the kdebase re-org will happen monday afternoon GMT. there will be one or two items (such as libkonq) that don't end up tidied away but we should end up with a more orderly kdebase with clear purposes to each area. i'll blog about that in detail on monday post-move.

kdebase, here we come

yesterday's plasma meeting went rather well. we're putting notes from the meetings as well as open tasks up on the plasma project wiki pages. i've discontinued the wiki on plasma.kde.org for a few reasons, though it will remain as a public site. someone has also stepped up to help with the content there, so once i upgrade the cms software we'll be digging into that as well.

it's kind of like a feeding frenzy, too: tasks get put up and people start working on them. personally i'm finishing out the engine/visualization bits so that by next week's meeting i can demo them and kevin can start working on the solid engine. the number of people milling about is pretty impressive, and it is taking a bit of my time to organize everything, help with questions, etc.. but it's worth it i think.

this email by bryce herrington just about says it all for me when it comes to building community and free software projects. it's one of our unique features in the technology world and we need to leverage it. it's not coincidental that making the desktop easily extensible with scripts and drag 'n drop customization is a big part of the plasma vision.

now that krunner is doing the screensaver activation duties, the screensaver dbus interface has moved to org.kde.screensaver from org.kde.kdesktop.screensaver as well so that it can survive future changes. so if your app was using the screensaver dbus (or dcop, if its a kde3 app) then you'll want to switch it over... we may end up going with a org.freedesktop.screensaver thing eventually; coolo and i talked about it today and he's going to pick up a thread on xdg from last may started by one of the gnome power management guys on the topic of screesaver dbus interfaces. whee.

spent part of the day getting kdebase back compiling, fixing a crash in klauncher (which made testing kde4 stuff a bit hard ;) and taking care of peyton who is home sick again. a few kids in his class are out right now with pneumonia, which is not a settling thought. so we're taking good care of him.

there was also a discussion (still on-going) about how we're going to arrange things in kdebase. it was half-moved from an amorphous collection of stuff into a few directories with somewhat clearly stated purposes. we're now trying to define that a bit better and i've tasked myself with seeing it through to the end. the growing order in our codebase is really doing it for me, i have to say =) maybe i do have a touch of the type 'a' personality after all.

i also spent some time with the author of mathusalem, a gnome project with similar goals as the kuiserver stuff rafael has been working on (with help from kevin and dfaure =), and rafael on irc to see if we could share some dbus-foo. seeing as we're both in the process of breaking/fixing our respective implementations of job monitoring, feedback and user interaction it seems like the perfect time to do this.

so it's been a long, long day. but it's coming to a close with tomorrow beckoning.

this past friday i went out to a restaurant with some friends. we had dinner and some drinks and talked too much about technology. (surprise! =) whilst dining one of the guys insisted that the waitress was flirting, though i wasn't so sure: i tend to banter with most of the people who bring me find food and good drinks. it's my nature. =) he thought i should ask her for her number, and i just kind of laughed it off. not being one to let that daunt him, he was there again tonight and asked her for her number on my behalf. she said she has a boyfriend but would give her number anyways. now it's in my inbox and i'm wondering what that phone call would be like. probably pretty funny =)

and speaking of restaurants, it's now time for me to go and cook some dinner ...

tidbits

i've had to shift the plasma meeting back an hour to 18:00GMT due to a morning appointment i forgot about until i looked at my calendar this evening. i need to learn to look at my calendar before setting times. *sigh* my bad. =/ hopefully this doesn't screw things up to badly for anyone. a summary will be posted to the panel-devel list in any case.

p., who'se 7 in a scant 2 months, informed me tonight that anything that ends in the word "mode", such as the "voice mode" he's going to put in the video game he will be writing when he's older, belongs in either the "options" or "settings" area of a program. "did you notice it ends with the word 'mode'? that means it belongs in 'options'. or 'settings'." says the p-man. boo-yah.

devnew passed 100,000 pages viewed this past week. a month ago we were at half that. can't wait to see what happens when we flip the switch and go all-lights-on. i also wrote most of a tutorial on kconfig which reflects the new kconfiggroup goodness and all. i have three small sections to write at the end of the tutorial to wrap it all up, but it's mostly there. i'll need to go through it for errors and what not as i wrote it in the middle of the night. hello insomnia!

the last three articles on theDot are about people in the kde community attending shows and hackfests to represent kde to the public and work with other free software devotees. the level of community participation in this community is just inspiring. thank you to everyone involved for that.

semi-random cohen quote: "whenever I happen to see you / i forget for a while / that I am ugly in my own eyes / for not winning you"

anoter random bit, but not cohen: "you said you'd stay / and wait for me / but you didn't mean it / literally"

i've also decided to submit a talk for akademy 2007 on the marriage of visuals, usability and a discussion on holistic experience goals for the kde4 line called "beautiful features: having our cake and eating it too". i plan for it to be more of a vigurous discussion with the audience than a presentation, per say ;)

i found vegan frozen pizza in the supermarket today. it was actually marked as "vegan" and this is just the regular local markets not one of the specialty ones. in an episode of "the batman" peyton watched tonight cat woman ordered in a vegetarian pizza. while we were eating our vegan one. the world is evolving around me and syncopating. its contractions cause my breath.

and there we have a it. a collection of odd tidbits from the day. now let's see if i can get some sleep. =)

konqueror not vanishing. news at 11.

i really didn't want to blog again today, but then i read that "we may see konqueror vanish" due to dolphin being in kdebase. some other sites picked this up, of course, because it's sensational. like many sensational headlines, it's also wrong.

i blogged about this once already a while back, but let me state it again really clearly:

konqueror is a power user's application that can not be fully replaced by something like dolphin (and vice versa). they have different use cases and different target audiences. both are valid concepts and both will be sharing the vast majority of their code, sort of like how kwrite is little more than a shell around katepart.

what is on the plan right now is for dolphin to become the file manager that gets launched from the default panel buttons and by apps requesting to launch a file manager. and just like in kde3 you will be able to configure all of this quite easily so that it uses konqueror (or whatever other tool you prefer, e.g. krusader) instead.

moral of the story: if you have a question try asking the people involved and you'll probably get an informed answer.

plasma meetings commence

tomorrow will be the first plasma meeting on irc. it's to get the small band of hungry developers who are ready to put this puppy together coordinated, and we'll be doing them weekly. everything has its time, and the time has come to get this rolling.

if you are a developer who is willing and able (both are important) to get involved in a meaningful way, you're welcome to join us on irc tomorrow at 17:00GMT. i want to keep the group fairly small though so as not to bog down under the weight of people. we'll be discussing the engine/visualization split, the desktop layer design and look at scripting options we have before us (kjs, qtscript, kross...).

hello mr. roboto, er, roberto

reading my email this morning i saw a ton of commits from roberto raggi. he was one of the mastminds behind kdevelop back in the day and ended up working at trolltech doing a lot of very solid work on qt.

well, he's back in kde land a bit more now. starting this month trolltech is sponsoring him to work a couple days a week on kde; it's really nice to be associated with a company that gives back so meaningfully and intelligently. it's even nicer to see roberto around again. he's an amazing developer, a really good guy in person and is already having an impact on the quality of kdelibs =)

will be interesting to see where he decides to focus his guns when the libs dust settles a bit more...

kde is for everyone

a meme i've come across recently is this myth that kde isn't a suitable option for new users. this is complete rubbish and easily shown as such with this simple bit of logic: if it isn't good for new users, please explain all those new users who use and love kde. i come across them all the time. some pick kde on their own, some use it as part of their school or work duties where it was simply handed to them. and they do just fine. better than fine, in many cases, such as can be seen here.

if kde wasn't good for new users, it would be failing there. it isn't, ergo ... well, you can fill in the rest.

there is something we can do better at, however: first impressions. we're like that attractive but perhaps a bit too serious person who would get a lot more social attention if they'd just let their hair down a bit and maybe wear clothes that were in fashion more recently than 5 years ago. this is the most often repeated reason i hear from new users who pick something other than kde for their new linux installation.

fortunately we have substance, and that attracts a lot of people and with a lot more commitment that looks alone can garner. it just takes a bit more effort to get others to appreciate that substance sometimes.

this is why oxygen and the new workspace in kde4 will be so important. it's what people first see and experience and it needs to be "wow". every application can help by keeping their toolbars clean (it's one of the first things people notice when opening an app) and focussing on the great experience our users have come to expect from kde apps.

i look at ksysguard as an example of an app who has taken its looks to a new level; i recently saw a screenshot of vista's analogous app and was astounded by how ugly it was in comparison.

so we can have substance and look pretty doing it; in turn this will help convince more people to spend the time getting to know kde. many if not most people make the decision to do that within the first hour or two of using the desktop.

meanwhile i look at the new kinds of functionality that kde4 is adding and think, "yeah, now that's us shakin' our real money maker, baby." =)

why api documentation is good but not enough

accurately and thoroughly documenting our application programmer interfaces is absolutely critical to making the work we do in libraries and other components useful to other developers (including those who will take over for us in the future). however, as important as api docs are, it isn't enough.

api documentation is like labelling each piece of a larger machine: each screw, bolt, assembly tool, pipe, driveshaft, etc... one may be able to read all of these labels and after examining enough of the other pieces be able to figure out how to assemble the individual bits and pieces into a functioning whole. but one is just as likely not to be able to because there isn't a "big picture" goals provided to work towards and when there are hundreds or thousands of pieces it can be not only time consuming but very mentally taxing to assemble those bits in your head.

this is why we need what i call "high level" documentation: articles that cover in a narrative fashion how to use our technologies. these articles (or tutorials, HOWTOs, whatever you prefer) lead the reader along a path to specific end goals. rather than being comprehensive descriptions of the individual pieces (that's what api docs are for) they help the reader get the bigger picture: the final machine rather than the parts.

this makes the api documentation so much more understandable as the reader will now have a frame of reference to apply to the detailed information. it also makes the api documentation reference material rather than source material for learning, which allows us to write it as such and not try and stuff tutorials into our header files.

and why not put these tutorials in the api documentation? after all, we do have the ability to include mainpage.dox files and general sections in headers. the reason is quite simple: it's not easy to do things like provide references to images or other media from these pages, they aren't community editable (which means, in my experience, that they become static documents and bit rot faster than they should) and there are simply some topics which don't belong in any header file.

for instance, the intro to d-bus article i added today: which header file in kdelibs should that go in? or how about information that ties together multiple disparate technologies? this means that at least some of our high level documentation will live in one place, such as the developer wiki, and some of it will be in our api documentation.

spreading our information around like that simply makes it harder than necessary for those researching kde technology to get all their information. the obvious answer is to keep it all in one, community editable place.

and so i make the case that api documentation is vital and critical, that it needs to be augmented with high level tutorials and that the high level documentation should all be placed on the developer wiki. if you are providing a key and/or useful technology for kde4 and you haven't thought about providing this high level documentation, should the project really be shipping that work? personally i don't think so. just as we have complete api documentation coverage as a goal and requirement for public api's, i believe we should have high level documentation for all libraries/technologies in kde as a goal for the kde4 series.

and that is precisely what the developer wiki is attempting to provide. please, do your part in this effort. i know i've been harping on about this for the last few months, but i'm a pain like that: i'll keep on about it until someone either shows me that it isn't needed or until the developer wiki is full of nice articles on the pillars of kde4 from a developer's point of view.

ok, rant over. discuss. =)

d-bus tutorials; guademy

today i uploaded a first draft of an "introduction to d-bus" article on the developer wiki. this completes the cycle of four articles i promised i'd write to document d-bus from a qt/kde developer's point of view.

they are certainly not "final draft" worthy, however. while i did use proper capitalization ;) they are littered with my usual nasty combination of misspellings and odd grammatical practices. it would be most welcome if people would take a gander at the articles and work them over. in the process you could even let me know (via comments on the discussion page for each article) if they are clear enough or if there are things missing, wrong, etc... i'd greatly appreciate the feedback =)

it also appears that i'm going to guademy, which is a combined kde and gnome 3-day hackfest that is being held in spain. trolltech wanted to send someone to it and they picked me. it so happens that i was already heading to norway to speak at an event put on by the norwegian unix users group in kristiansand so was, relatively speaking, "in the neighbourhood". instead of going straight to norway, i'll be stopping off in a coruna first for a few days of free software desktop loving.

if you're going to guademy or are just in the a coruna area and want to hook up for a visit, let me know and we'll see what can be done.

i do have a bit of a hesitation over the whole thing as it means that many more flights and my last trip to spain resulted in nutritional challenges for me: i don't speak spanish (making negotiating in restaurants pretty much impossible) and i don't eat animals (spanish cuisine seems pretty heavy on the animal products). but who knows, maybe it'll work out better for my poor little stomach this time around =) i am looking forward to seeing the atlantic coast of spain, though =)

a bar named sue

found a cool new little hang out that's only a dozen or so blocks from my house called "a bar named sue" (a clever play on the johnny cash song). it's a friendly little place (seats maybe only 30-40 people comfortably?) which a real neighbourhood feel to it. they have live music of the folksy, bluesy tyep. the night i went the bartender played with the band, serving drinks between songs, which really added to the "small cool place" atmosphere.

the people there were friendly and fun as well as generally my age group so i felt neither old nor young (something i find happening more and more as i hit my 30s while maintain my odd collection of interests). i ended being invited to join a small birthday celebration going on at a nearby table and had fun into the morning hours with them. hooray for birthdays and birthday girls!

long story short: i think i've found a new haunt =) whenever i lose faith in this city being able to come up with something new and cool (it's usually one or the other) she tends to find a way to remind me not to judge to quickly.

developer wiki friday

i blogged about kconfig in my last entry so i could blog coherently about this week's dev wiki friday. yes, they are officially on again =)

i don't expect to have all my bits and pieces in kconfig done by friday (particularly since the p-man is hangin' at the house tomorrow, school being out for an extra-long long weekend), but on friday i'll be working on the last of the d-bus tutorials and an intro to kconfig bit that shows the right way to use the new classes.

there's still a lot of tutorial writing needed as well as fact checking of the existing ones. APIs shift here and there, so reading over some of the tutorials again might be in order. for example, the intro to kde4 programming tutorial should be read over to see if the code is still valid and "best practice" given recent changes such as the introduction of KComponentData. for new tutorials, there's a broad range of topics left.

for instance, if you know how to use KFileDialog consider writing a tutorial on it (yes, even stuff that simple is useful). if you felt like learning a bit about phonon, a great way to do that is to read the API documentation and write a tutorial on devnew. tutorials don't have to be long or complex, in fact short and clear is often better (think of what you'd be willing to sit and read ;)

if you are ready to write a tutorial but don't know what topic to cover, join us on friday in #kde-www and one of us there will be happy to make suggestions...

also, there'll be an announcement on the dot in the coming days about a poll for the name for the wiki ... hopefully we'll have the naming stuff behind us in short order.

kconfig hotness

update: to clear up some apparent confusion, this post is about the kconfig class which kde apps use to read/write configuration data, desktop files, etc .. it's not about the control center =)

kconfig is being kicked into shape. first mkretz reworked things so that there is a KComponentData object which holds a collection of KAboutData, KConfig and KStandardDirs. this meant some changes to KConfig, namely using KConfigBase is most places rather than KConfig directly and having KConfig optionally take a KComponentData and letting that determine its lifespan. every app has a global componentdata object while plugins/parts/etc may have their own.

this seems to have inspired others. coolo and dfaure have been attacking kconfig in a branch. bools are replaced with enums in the API, KConfigGroup no longer subclasses KConfigBase and provides all the read/write API while that same API has been deprecated in KConfigBase. exciting times.

tomorrow i'll be merging in changes from another kconfig branch that have to do with making backends pluggable. this has a number of implications, mostly positive =) an interesting example is that KIO::SlaveBase has a subclass of KConfigBase, which dfaure pointed out to me today. looking at the code it's apparent how it's really just mapping the KConfigBase API to a non-file data source; in other words it would be much more suited (and the code read less "funny" =) if it were a backend. which is the plan (after having talked with waldo about it earlier today via email).

if all that goes well the next diabolical plan will be to look at the feasibility of merging KConfig and KConfigBase into one class. this was already accomplished once in that other kconfig branch, so it is doable =) the pluggable bakcend stuff has to happen first though.

end result of everyone picking away at this: kconfig will be extra sweet in kde4. so send cookies to the people who have been working on this rather technical and boring bit of code =)

speaking, wikiing

p. was home with a fever today. on wednesday their teacher (who he says was a substitute) let them go outside for lunch which was pretty daft as it was -12C outside and snowing. after being out there for 40 minutes or whatever he caught a chill and that translated to a fever by the next morning. i'm going to have a talk with the school on monday about this as it really strikes me as rather dumb to let the kids out to play in weather that cold. p. says they usually do inside things when it's cold outside. anyways ...

between taking care of p. i spent some time on the developer wiki since it is friday. i'll start running devwiki fridays again starting next week. today i worked mostly on the sys admin area. now the question is what to do with the old one since the dev wiki will end up being more and more about kde4 so the stuff on kde.org still holds some value as it covers kde3. there already is some divergence.

as i wrote that last sentence, it occurred to me that a KDE3->KDE4 transition guide is in order for the sys admin area. i'll add it to the table of contents and start working on that next week. there aren't many items to go there right now, but i'm sure the list will grow and be quite useful to those who eventually transition existing deployments to kde4.

given that the new site is a wiki, i'm really hopeful that as people make changes or additions to kiosk keys, change how subsystems work (such as the mimetype changes that are upon us; go david, go! =) and otherwise have information sys admins would find useful that they continue to keep the site up to date so it doesn't rot away as kde3's docu has started to.

documenting things also has the side effect of making one ensure that the design and implementation decisions actually make sense. i caught one small thing in krunner today that was a bit odd and fixed it, for instance.

i'm also still waiting for people working on or with various kde systems to provide tutorials for them. we really must have decent documentation for the important frameworks in kde4 for applications to take advantage of them. sonnet might be cool, for instance, but unless there's a tutorial that lets people start using it in their application code quickly it'll almost certainly end up under-utilized and/or take many more revision releases of kde4 to find its potential realized.

i also spent a bit of time lining up the two conferences i have on my agenda between now and summer: one in norway and one in brazil. i'll be giving 5 presentations between the two of them, which isn't too bad compared to my schedule last year.

64,000 copies of kde for french students

while catching up with email, house work (the cats made some messes while i was away), local phone and postal mail and working more on the stuff i started yesterday in the airport, i came across this cheery bit of news that a regional government in france is sending out 64,000 copies of a local kde based linux operating system to secondary school students in their area. awesome =)

now back to grindstone for me.

travel uncurse 2

i totally forgot why i started writing my last blog entry once i got to the part about readable api's. it's been that kind of day ;)

while in boston logan, i spotted a nokia 770 on the television; i spotted what looks like open office (_maybe_ koffice?) using the crystal icon set in an episode of house m.d., so apparently at least the woman doctor runs kde on her laptop =); and the guy next to me while i was hacking started chatting to me and gave me some rather nice news:

he works for a company in the u.s.a. that makes software for hospitals. right now the client side only runs on windows. they are changing that with their next major version with a linux client as well. unfortunately he didn't know what toolkit or language they were using (he's not in development). but it's great news, as it seems to be one more sign of a growing trend: more and more client side software is aiming for linux.

the applications are coming!

the travel curse continues .. or does it?

my flight out of boston was delayed by 3.5 hours and we circled around the toronto pearson airport for a while due to weather. the third landing approach was finally cleared and we landed. my new flight out is delayed by an hour as well, however. =/ at least i have free wifi to enjoy.

not all was bad, however. i took the opportunity to hack on cleaning up kstandarddirs api (die boolean parameters, die!) and started to break out the konqueror servicemenus into a reusable class so they are accessible to other applications without copy and pasting code. i didn't start out intending to touch kstandarddirs, but i saw code like this:

const QStringList entries = KGlobal::dirs()->findAllResources( "data",
                                                               "konqueror/servicemenus/*.desktop",
                                                               false /* recursive */,
                                                               true /* unique */ );
 

and shuddered. when you feel the need to comment api usage, the api sucks. so i went in and cleaned that up... now i'm repairing the build and porting kde svn to the changes. the resulting code is so much clearer and easier to read. we hear about "linux for humans", well programmers are humans too and we deserve api's that make our life easier and better. the compiler and cpu don't really care much about these changes, but the people behind the code sure do =)

i'll get home late tonight, but have a full day lined up tomorrow: working with the fsfe, starting the visa process for fisl in brazil in april as well as working on kde4.

boston wrap up

the labs at boston u. closed for us at 14:00 today so it was an unexpectedly short day. rex had to catch his 17:00 flight anyways, so it all sort of worked out anyways i suppose.

we discussed default package contents and what settings to look into for customization for fedora 7. looks like f7 stands a good chance of having really nice kde packages thanks both to the fedora community expanding their embrace of the community in general (merging core and extras is a nice move, too) and rex and other kde fans putting in the time and effort.

there are still things that could be better, but aren't there always. =) i feel that this was a weekend well spent working due to the gains. i also got to talk about kde4, qt4, greenphone (one of which arrived just before leaving for boston), freedesktop.org, etc... i think a few people were tired of hearing about fd.o after a morning discussion of it involving several of the desktop team members. it's an important topic, however.

interestingly, some view gnome and kde as being analogous to mac and windows: separate platforms, people don't move between them often and so standardizing things such as default application storage isn't very interesting. i happen to agree that not everything should be or needs to be standardized so as not to get in the way of each project's personal vision(s) and innovation, but i'm also sympathetic to those who manage large mixed deployments and operating system vendors who are forced to do more work and trickery to get things harmonized. it's an interesting discussion as to where that balance exists, particularly since there isn't a general consensus on the matter even within projects.

overall i was very impressed by the fedora and red hat communities. they're doing some solid engineering and put a lot of thought and personal passion into things. i'm going to keep a closer eye on the next couple of releases of fedora; it'll be interesting to see what emerges, what works, what doesn't and how their community evolves.

personally i've had a couple of early, though thoroughly enjoyable, evenings. some of the other people have partied a wee bit harder than i (to say the least), but i wasn't particularly in the mood. i did get out last night with a couple of local linux enthusiasts and rex for a couple of pints at a nice brew pub where the beer was good, the conversation interesting and the atmosphere relaxing. i leave for back home tomorrow morning at 11:00 and hopefully things go better on the way back than they did on the way here =)

fudcon boston day 2

today is the first day of the hackathon at fudcon. yesterday there was a series of self-organized "presentations" which were more like status reports and brainstorm sessions. meetings, really, to get everyone on the same page.

i'm not particularly sure why they called it a conference, per say, since it's not really a conference in the generally understood meaning of that word but a series of development meetings. there was probably 70 or so people here yesterday, with fewer people staying for the hackfest. john palmieri, owen tayler, chris blizzard, jonathan blandford, david zeuthen and other red hat notables are around.

this morning i spent some time evangelizing freedesktop.org processes and xdg-utils to people here with the hope and aim of getting more involvement and interest from the fedora and red hat communities. it was progressive with some very honest and very useful discussion. getting the last rhel out the door was distracting for many and coupled with some unsureness related to the direction of fd.o (e.g. few if any had any idea what xdg-utils was, let alone why they should care about it) has made for low involvement over the last year. with the release of 4.0 there is interest to pick up the slack again and start working on a new round of specs.

the kde session yesterday went rather well, too. 9 people came to the session which rex dieter led. rex is the fellow who started the kde-redhat project and who now sits on the fedora board and is heading the kde spin for fedora. exciting times. we came out of the meeting with goals for today and tomorrow, primarily package definition and answering questions around theming, defaults and general presentation.

kde meeting attendees

there are a lot of kde users here which is nice to see. even better is the renewed interest and commitment in kde amongst the fedora and red hat communities. this is largely thanks to people such as rex but also to kde's widespread acceptance and adoption amongst users, both individual hobbyists and in the market place.

for the afternoon yesterday i sat in on the ltsp and education meetings. during less interesting moments i worked on documentation on devnew, in particular the new sysadmin info area which is essentially migrating and updating content from the old one. not the most fun thing to do, but perfect work while listening out of one ear to someone presenting at a meeting ;)

nested dialogs suck

i hate dialogs-on-dialogs, or as i like to call it "matryoshka windows". i did some work before coming to boston to make the password dialog able to show errors right in the dialog so when you mistype the password you get in-dialog feedback. no more matryoashka! kdesu is now a bit nicer =)

i also addressed a few api issues in the new kpassworddialog (e.g. remember to always make constructors that have defaults for all their parameters explicit; a showErrorMessage() method; a method to allow subclasses to check a password before the dialog accept()s); addCommentLine() actually adds lines rather than just show the first one, etc) .. i also fixed a few issues in kdelibs/kdesu which should resolve issues like it not saying "put your password in" when using sudo.

i also stumbled upon a little known configuration option in the process: you can define whether you use sudo or su by putting something like this in a config file (kdeglobals recommended):

[super-user-command]
super-user-command=[sudo|su]

i worked with el and jan on the usability of the new dialog and i hope to come out of this process with some guidelines and thoughts for other dialogs in kde4 as well.

but yeah.. no more password matryoshka!!!!!

boston

it's been close to forever since i blogged last. i needed some silence in my life for a while, a sort of reset. things are back to good and so here we are...

i'm sitting in boston university writing this waiting for the fudcon (fedora conference) to get underway. i'm wearing the same clothes i arrived in because my luggage didn't.

yesterday started with getting on an aircraft for a 09:00 flight. i was sat next to a nice young woman who was looking into universities in the area. she was bubbly and talkative and i thought things were going to go well. until she asked, out of the blue, "do you have peanut alergies?" i said no and she replied, "oh, good! because i have a peanut butter granola bar." this struck me as slightly odd and i started to wonder how good the day would end up being.

which is when they announced there were some mechanical problems they were working on before we could leave. the extent of the mechanical problems became apparent as the firetrucks started arriving and they got everyone off the plane. i went to get reticketted while most people waited for their bags to show up in the baggage claim area (they'd end up waiting for about 45 minutes).

with new tickets in hand i breezed through security (for a second time) which is when looked at the times on the tickets and realized that they had given me an impossible itinerary: there was no way i'd get my connecting flight in toronto. i went up to the help desk and they got me on another flight that was leaving immediately, unfortunately my bags were already on the other plane.

i arrived in toronto pearson airport 5 minutes before boarding for the boston flight was to start, so i ran to customs and explained the baggage situation (they don't like it when you and your bags fly separately, "lost in transit" or not). i then sprinted a couple hundred meters down to the farthest gate in the u.s. departures area of terminal 1 only to discover that the cabin crew hadn't shown up and the flight was delayed anyways. =/

in theory my bag should arrive at the hotel later this morning. and i have US$50 to spend on clothes and toiletries if i want to that the airline will reimburse. what a trip.

i just need to make this conference really worthwhile to make up for the travel horrors. i'm also missing the opera which i was supposed to go to tomorrow with t. it's the world premiere week for frobisher and i'm really disappointed i'm not in town for it; we had platinum class seats and everything. t's going with a friend of hers instead.

*sigh*