keeping it (our source code) together

Why do we have a shared source code repository for KDE development?

That is not a rhetorical question. :) Perhaps even stop reading at this point for a moment to think about it a bit.

Benefits, imho

For me the reasons for having a shared source code repository are many. Some are historical (back in the day, pretty well everyone self-hosted due to lack of credible options elsewhere) and some are convenience related (I always have a place to start a KDE related project without much effort thanks to svn.kde.org). These reasons are not particularly compelling to me because they are either not benefit related or are easily fulfilled via other options out there, particularly as project hosting options such as gitorious.org have gotten as good as they have.

There are other reasons, however, that have everything to do with the source code being close together that can not be so easily replaced in my opinion.

There is, first and foremost, the joint issues of barrier to entry and transferability of knowledge. It is amazing that if I want to hack on a given application or library that is produced by the "central" KDE community, there is exactly one place I need to look to, there is exactly one workflow I need to figure out and there is exactly one set of tools I need to learn (cmake, svn; maybe bugs.kde.org and reviewboard). Even our APIs tend towards, quite purposefully, similar idioms for the same reasons: it makes it easier to get up to speed with them.

What we learn in one KDE experience, we can apply again immediately to another. Even as we lower the barrier to first entry to KDE, there has historically been a near-zero barrier to entering a second, third, fourth, etc. KDE project.

It also means that when I want to fix or improve something, as I did with katepart for the 4.5 series, I could dive in immediately. That was the difference between me accepting a poorer solution, working around the problems and actually reaching out to fix it. Admittedly it wasn't a huge contribution, but for the use of katepart in plasma-desktop it was pretty important and it was, after all, a contribution.

We are able to coordinate things like release management much more easily as well: there is exactly one place to look for the official sources, one place to deal with tagging and other administrivia. We have entire workflows built around being able to land code in playground, move it to kdereview for feedback from any interested party and then into trunk proper. We catch more localization issues this way than probably any other single mechanism. These workflows, in turn, are documented on Techbase for people to read, learn and use as guides to getting involved.

There is also the issue of simple visibility: when something lands in a shared space like svn.kde.org many more people notice than when it lands in gitorious.org. For those who watch the commit lists, or when it was alive the commit digest, the ongoing development of a project really keeps it in our sights. It also helps us notice when it isn't being developed so actively. Visibility is a medium of passive communication.

Without a common set of tools, including a revision control system, all of the above is eroded. We begin to lose the things that allow us to easily behave as a coordinated community when it comes to creating software.

Why this question now?

The reason I ask the above question at this point in time is that KDE developers are voting with their feet and moving to git, one project at a time. Moving to a revision control system that gives us better tools is not a bad thing. Quite the opposite, in fact. We also should not try and shut our eyes to the fact that git is becoming, slowly and surely, the new consensus (which does not mean unanimous :) choice for KDE developers. What is interesting about this trend is that it is happening piecemeal: one project here move, one project there moves.

Fortunately, most projects are moving to gitorious.org where we have a kdedevelopers group that can be added to a project to allow some measure of group involvement again. It is inescapable, however, that our community is slowly dividing into two pieces when it comes to where our source code lives, like two continents moving apart on separate tectonic plates. (What's really unfortunate is that some projects have moved to completely different revision control systems that throws them right to the fringes of our community in terms of cross-project activity.)

Let me open about this: I'd like to see plasma hosted in a git repository. There are, however, no benefits to that which trump being close to the rest of the KDE community's efforts.

Other risks

For those moving to gitorious.org, there are other risks involved. While gitorious.org would be great for a few reasons (proximity to qt, large pool of people who already have accounts there) there are also drawbacks to it. We are currently in friendly discussions with the company behind gitorious.org to have those drawbacks addressed. Part of that solution involves arriving at a financially acceptable agreement for commitments to availability, hosting and ensuring we have access to certain bits of information we must have in case of disaster (e.g. a back-up of user accounts so KDE sys admins could quickly set up a replacement server should something unforeseen happen to gitorious.org). Given that revision control is so central to what KDE does, these are not issues to be taken lightly.

They are, also, not issues that have been resolved yet. I had a conference call during Tokamak 4 with gitorious.org staff and KDE e.V. board members to discuss these issues, so progress is being made towards a decision, but right now it's not a foregone conclusion that KDE will move to gitorious.org. We may well end up hosting a gitorious installation on our own servers.

Having projects jump onto gitorious.org prematurely may end up being more of a hassle than they expect as a result. It is very easy to move a local git repository from one place to another, but then we have to communicate that to all of our contributors and project followers and figure out what to do with things like pending merge requests.

I also see some projects moving to git as a way to work around build system issues: Kate is moving to gitorious because they want to make it easier to build katepart, kwrite and kate outside of kdelibs and kdebase (kdesdk is already simple: just cd into the kate dir and build). That is a huge (and unnecessary) workaround. cmake already supports builds starting from different levels in the host module; that's how we currently manage kdebase as one build vs kdebase-runtime/-apps/-workspace as three separate builds. Working around such issues fixes the problem for some but not for others while causing rifts in our collaboration community.

This is just one more set of reasons to not rush headlong into things just yet.

What are the alternatives?

The alternative is quite obvious in my mind: take the time to coordinate.

There is a git migration project that is making progress week by week. The project is documented on Techbase and can use more hands. It can also use our support, e.g. those two projects who still have svn externals in key places that we can't just ignore (Oxygen and kget) really need to get moving on that (or face more dire results like finding the code migrated one day in a poor state, e.g. with code being copied around or files commented out of the build).

svn.kde.org is not so horrible that we can't live with it for another release cycle. We obviously don't want to live with it indefinitely, however, so a final move-by date must be established, in my opinion, to give all of us something to work with, to ensure all of us that it will indeed be happening within a reasonable time frame. Deadlines rarely hurt. :)

Instead of moving projects one at a time in an uncoordinated, maldocumented mess, let's rally together to coordinate on the move to a new revision control system (which will be git, by popular acclaim) so it gets done well, right and without losing the benefits we've so carefully gathered to this point.

Read More

back home, tokamak ripples on

I'm back home (as of last night) and slipping back into the comfortable routines of home that revolve around a comfortable shower, my own bed and my family members. Tokamak continues to ripple on and outwards, however: Mirko, our friend from OpenWrt who joined us, has posted a blog entry showing Qt apps running on the Qi NanoNote which is a truly tiny (physically) computer that has only 32MB of RAM. There's a video linked to in Mirko's post that shows even the coverflow Qt demo app running very smoothly. Very cool, and means we (or, rather, Mirko :) achieved the primary goal of having OpenWrt at Tokamak. Next up will be to find some time to rip into the configuration system OpenWrt has and write a Javascript Plasmoid for interacting with them that can be shipped on the device and accessed remotely.

Read More

javscript errata update

I just uploaded a new version of plasma-scriptengine-javascript-4.4-errata.tar.bz2 which folds in various fixes and improvements that will be in 4.4.1 which will be tagged later this week for release. Apparently some are using the errata tarball to participate in the Javascript Jam Session with KDE SC 4.3. Neat. :)

Here are some notes and fixes related to this update:

• Painter.brush was read-only


• To fill an ellipse or most other shapes when painting, set the brush on the painter. This can be done by creating a pen and calling brush on it, e.g.:
  

  var pen = new QPen
pen.color = new QColor("red")
painter.brush = pen.brush



• QIcon is now available from scripts, so that using IconWidget is possible


• It was not possible to create layouts that were children of other layouts or even other ui elements. This has been fixed and resolves related crashes.


• Column and row span, along with alignment, is now respected for items placed into a grid layout


• Links in Label elements were not clickable; this is fixed in libplasma for 4.4.1 but the errata tarball is just the script engine itself so it won't address this issue


• Label.textSelectable was not available

Thanks to everyone testing and reporting issues, it's helping get these bindings into great shape.

Read More

tokamak tuesday

Another day of Tokamak, another day of endless work, great fun and massive amounts of progress. While a few more leave us today, we had another of the KDE artists join us and we continue to rock the OpenSuse meeting room spaces.

The presentations last night (which were recorded) went very well with a dozen or so locals showing up to join us for the fun. The recordings will be uploaded at some point (I'll provide links when they are) and OpenSuse provided post-presentation beer, soft drinks and water. As fun as that part was, it was really cool to have a line up of a laptop, a netbook, a tablet and a smart phone all running Plasma workspaces during the presentations.

Plasma stuff was also running on both a Linux and a Windows7 computer. They are now in the coffee area outside the main Tokamak room. Each one sports a 28 inch touch screen panels with the computer bits built right into them. Pretty fun kit to use and shows both the promise and limitations of touch screens for desktops.

Today Tokamakers have been flying in all directions getting probably more done than we've ever achieved at Tokamak. There was a great meeting about animation extensibility (including the ability to change them, ala SVG themes, at runtime), a conference call with the company behind gitorious.org get the next steps in the git migration process sorted, huge strides forward on the mobilizing of kdelibs, the first runs of the Plasma Mobile proof of concept using QML and Plasma together on the N900, more bugs fixed in netbook as well as Javascript, the start of work on the new activities switcher, integration of context with Nepomuk and much more.

I also had a meeting with some of the folks who are working on Suse Studio and the Suse build service and had a fun idea that will be turned into a project. I'll blog more about it at week's end as there is some set-up to do for it, but I think it could be really quite cool. More about that later, though ...

Right now I have to get back to fixes and improvements to the Javascript Plasmoid engine and push out another errata release before we head out for dinner at an organic vegetarian restaurant. :)

Read More

day 2 of tokamak 4 (and a bit about day 1, too)

Yesterday was the first full day for Tokamak 4 with most of us having arrived from near (e.g. right here in town) and far (Brazil, Canada) the day before. We had a great series of presentations to catch each other up on where we are right now and where we are going. I opened the proceedings with the usual "state of the plasma" presentation where, after recapping the motivations and core design values we had defined together over the past couple of years, I likened our efforts to those of a sculptor. We had before us just raw materials, a rough-hewn stone if you will: Qt4 with QGraphicsView in it's earliest infancy, KDE 4's libraries and a simple vision. Inside that block of stone, we envisioned a masterpiece just asking to be found and released from the stone. After working for a couple of years we have something that has real shape, great scale and impressive momentum. We are at the point where we need to "finish off" many parts of this living, dynamic structure with the small, fine details and leave behind a perfectly smooth surface finish. The rest of the presentations, given by various of the nearly 30 attendees, were great insights into what this work before us would entail.

Lubos and Martin talked KWin and window management in general and were followed by Nuno discussing the state of Oxygen. Then came Marco, Alexis and briefly myself again giving overviews of the state of Plasma Netbook, Plasma Mobile and Plasma Desktop, respectively. Ivan and Chani then presented on the topics of context, activities and Nepomuk's role in this. Dario and Lukas shared their work on Shaman, which is essentially what Solid is to hardware but for software installation, with us. Sebastian caught us up on the ideas behind and code available right now for Silk, a long-term project that aims to bring greater access to online and web services to users of KDE software, and Will gave a good presentation about network management (including how we have 3 people working on finishing the network manager Plasmoid this week!). Mirko from OpenWrt gave a short, but interesting, presentation on what OpenWrt is and showed off a very cool, very tiny open hardware device. We finished off with a presentation given by Frederik and Frank on Open Collaboration Services and the Attica library that makes accessing such services easy (and how it has improved the Get Hot New Stuff UI in KDE SC 4.4) and a recap by Savago on where we were with the Plasma animation framework.

As you can imagine, this took pretty much all of the day. Fortunately we had the evening still ahead of us. After dinner, we came back and worked on various things. I ended up falling asleep in front of my laptop sometime around midnight while working on Javascript issues, and eventually made my way back to the hotel after I was woken up by playful Tokamakers. This was the end of day one. :)

Day two saw some code getting written but the real highlight were the team meetings. Plasma Mobile took it's first real steps with presentations on embedded development, build systems and some demos. The group then split into two smaller break out groups, one focusing on getting a proof-of-concept workspace interface built with KDE Plasma for "pocketable" devices. The goal of this break out group for Tokamak 4 is to have something demo-able on the Jax 10 devices that were sent. This will be a fascinating test of the flexibility of the Plasma framework and how fast we can make new things with it.

The other group focused on putting together a survey of the KDE Development Platform from the perspective of usage in mobile applications. They managed to generate dependency graphs for the libraries in kdelibs and worked on strategies for improving the modularity of the individual libraries. It is better than any of us really expected, but there is still room for improvement. They also surveyed kdebase-runtime and picked out the necessary bits from there for a non-desktop KDE foundation. The goal of this group is to have something to present to the KDE libs development community on Thursday.

Five of us also got together to discuss KWin and Plasma Desktop issues, both in terms of being individual apps as well as how they overlap or, rather, should work together more effectively. A good set of plans emerged, including: the need for a tiny xlib based application to manage screen edge interactions so we can unify and harmonize features like panel autohide, effect triggers in screen corners and changing desktops by "pushing" against edges; a list of new desktop effects we need in KWin to get rid of various hacks in Plasma Desktop; a list of new window types that plasma-destop and krunner can use to give KWin more information about what is going on so that KWin can be more sophisticated in its handling of these windows (e.g. dashboard, the krunner window, ...).

Then there was the context-and-activities meeting that was held. Building on Ivan's work for storing context definitions in Nepomuk (so that places, recent documents and more can be associated with an activity), an API draft for context and triggering changes in applications when it changes was formed. Related to this was the application launcher meeting which was all about harmonizing the code between the various launchers and how to get raptor back on the rails. Context also loomed large in those discussions. This year will be a really, really interesting one on the context front in Plasma Desktop, I think.

I also found some time with Mirko to discuss possibilities with regards to OpenWrt. Mirko was able to get Qt built successfully for a MIPS based OpenWrt device, opening up that platform for Qt based applications, and we springboarded from that to discuss the possibilities for Javascript Plasmoids that could accompany OpenWrt devices which can be accessed over the network by computers running Plasma to do configuration, monitoring, etc. Interesting possibilities, and OpenWrt itself is a very interesting project.

A few people had to leave today, but there are well over 20 people still with us. We moved to the hostel just up the street from the OpenSuse offices, which is in an old stables house that is part of the old city wall. It's now 20:30 and I'll be going to find some food soon, but the fact that we still have so much ahead of us is all I can really think about right now. Foundational code written for the topics we've hammered out so far needs to be written and there are other topics we'll be covering in the days ahead such as the next steps for the animation framework and SVG usage advances. We have four more full days ahead of us and it will be interesting to see just how much we manage to accomplish and how much more we will achieve in the months to come as a result.

Read More

sprints 'n stuff

It's developer sprint season again in KDE land. Actually, that's a bit of a redundant statement since it's almost always developer sprint season in KDE land. ;)

I've been watching the combined KDevelop / Kate / Okteta sprint going on right now in Berlin with interest as they are achieving some really great things, from performance improvements to scripting improvement (more cowbell Javascript!) to major strides in stability. If you've missed what's been going on there, here are a few blog links that might be of interest to you:

• Friedrich Kossebau (frinring): Okteta going for KDevelop (and Kate?)


• http://nikosams.blogspot.com/2010/02/css-language-support-update.html


• http://dhaumann.blogspot.com/2010/02/developer-meeting-more-on-scripting.html


• Dominik Haumann: The Power of Developer Meetings (I highly recommend this one because not only does it list a bunch of progress points they hit, it also offers a really nice analysis of why developer sprints are so valuable.)


• Milian Wolff (milianw): Kate/KDevelop HackSprint - Up To Day 4

Just as that dev sprint wraps up, another will begin: Tokamak 4! This juggernaut of a sprint will consist of at least 25 people and three KDE projects. Tokamak started out as a developer sprint for Plasma stuff, but it's grown organically to include those areas that Plasma relies on or which rely on Plasma. I'm really excited to see what will happen not only for Plasma, but also for Oxygen (here's Nuno's take on that topic) and KWin. We'll also have visitors from outside of these three groups as well, including a fellow from OpenWrt.

Due to being large and diverse, we will have several break out focus groups over the course of the week focusing on a variety of topics ranging broadly between Plasma Mobile, Oxygen styling, KWin integration and features, deskkop-wide context and activities, application launchers and more.

Tokamak 4 is the first "northerly" Tokamak, with the last three happening in Italy, Portugal and the south of Switzerland respectively. Building on those successes, we're moving up the map a bit with this Tokamak It is being hosted in Germany. Instead of Berlin where the KDevelop/Kate/Okteta sprint is rocking out, we'll be in the lovely city of Nürnberg. Our hosts are Novell and the OpenSuse team. We'll have lots of opportunity to rub shoulders and meet various Novellians in between our sessions and work (and everyone in the offices there is both welcome and encouraged to come join us when and as you can). Will "bille" Stephenson has been an absolute star in getting this thing organized and making sure we have the resources to make it all happen, something that we owe a debt of gratitude both to KDE e.V. (and therefore everyone who donates to KDE e.V.!) and to Novell for hosting and helping with accommodations.

On Saturday we'll have a public Open Day. Visitors are welcome to join us during the day, and possibly for evening/night-time activities. Presentations will be given by various Plasma, KWin and Oxygen team members and it will also be when we hammer out the exact details for the schedule for the rest of the week (when, where and who are in the break out groups, for instance).

This all means that today I'm gathering details for travel (how do I get to the hotel again? :), getting my presentation for Saturday in order and generally getting stupidly excited about starting out to the airport tomorrow to rock this thing with some of my best friends and colleagues.

In completely unrelated-to-sprints news, KInfoCenter has a new maintainer in the form of David Hubner. He's working on improving that very useful application to show more information more gracefully. Since he's tapping into more and more workspace related technology, such as Solid::Control (which is a workspace library that builds on top of the base Solid library in the KDE Development Framework), KInfoCenter has been moved from kdebase-apps to kdebase-workspace. I'm really happy to see KInfoCenter get more of the love it deserves, and I can't wait to see what David comes up with over the next KDE SC releases. If you have interest in this area and some coding skills, now is a great time to get involved as having an active maintainer around makes that much easier. KInfoCenter development discussion currently seems to happen on kde-core-devel at kde.org.

Read More

daily javascript update

It seems this is becoming a daily event: people report requests for improvements and/or outright bugs in the Javascript ScriptEngine, we fix them and then I write a blog about it. Today we have three items on the table:

• Errors in Plasmoids would only say what the line number was, not what file the error came from. For Plasmoids with multiple files in them, this is less than great. In KDE SC 4.5, the UI will show the filename as well as the line number of the error. In KDE SC 4.4.1 this information will appear on the console. (The difference is due to translation: we can't change strings in the stable branch after release.)


• rect.adjusted was not working; it is now (it was improperly described as as getter in the bindings)


• pixmap.scaled was not working; it is now (and had the same problem as rect.adjusted)

The list of errata is getting longer and I don't want people to have to wait for KDE SC 4.4.1 to become available to them to get resolution to these issues. So I've decided to make a tarball containing the Javascript Scriptengine from the 4.4 branch that fixes all the issues I've covered in my blog over the last week:

plasma-scriptengine-javascript-4.4-errata.tar.bz2

I'll be updating the tarball as needed to catch additional issues between now and 4.4.1. Plasmoids submitted to the Javascript Jam may use the version in the 4.4 branch or in the errata tarball so that they don't have to put up with bugs. :)

To build it, make sure you have the kdelibs devel and cmake packages for your system installed (`zypper install libkde4-devel cmake` on Suse, and `apt-get build-dep kdelibs` on Debian?), and then do something like this:


tar xvf plasma-scriptengine-javascript-4.4-errata.tar.bz2
mkdir plasma-scriptengine-javascript-build
cd plasma-scriptengine-javascript-build
cmake ../plasma-scriptengine-javascript-4.4-errata
make
su -c (or sudo) "make install"


Voila!

Also, there is a transcript of Saturday's Javascript Plasmoid training session available, and physos has also put it on a page on Techcbase.

Enjoy! :)

Read More

implicit conversions, more errata

Getting used to writing Plasmoids in Javascript takes a bit for me, and apparently at least some others out there. One things I'm used to from C++ is being able to watch one object of one class "turn into" another using implicit conversion. For instance, when something expects a QEasingCurve it's second nature for me to use the QEasingCurve::Type enumeration directly (animation->setEasingCurve(QEasingCurve::OutBounce)) and rely on the compiler to figure out what I really meant (animation->setEasingCurve(QEasingCurve(OutBounce))). With the Javascript Plasmoids we have to be a bit more eplicit about these things.

So this doesn't work:

animation.easingCurve = QEasingCurve.OutBounce

but this does:

animation.easingCurve = new QEasingCurve(QEasingCurve.OutBounce)

The Smoke bindings are capable of doing implicit conversions, though, as Richard Dale pointed out in a recent blog post. So there is hope in the long run. :)

Two more pieces of errata:

• If you are using Kubuntu and you are getting errors about not being able to create a Javascript ScriptEngine, that's because of a packaging mistake on Kubuntu. The Javascript ScriptEngine is part of kdebase-runtime, which means we are supposed to be able to be rely on it being there. It used to be in kdebase-workspace which doesn't have these guarantees, however, which I assume is why things got dropped here. The solution is simple, though: sudo apt-get install plasma-scriptengine-javascript. I'm told that future updates will have make kdebase-runtime depend on plasma-scriptengine-javascript which will fix this issue.


• The MovementDirection enumeration for Animations was not being created in 4.4.0; this has been fixed and in 4.4.1 and beyond one can indeed write things like "animation.movementDirection = animation.MoveLeft". Until then you need to use the literal values of the enumeration.

I'm really happy with all the testing the Javascript Plasmoid system is getting, and not just because it's working out but also because it is highlighting problems in the process. I'm fixing the problems as they arise in #plasma, plasma-devel@kde.org or on bugs.kde.org. It (once again :) highlights the value of having users of an API, and the need for a larger number of test Plasmoids (which also tends to help KDE Examples grow) as well as setting up an automated system around those tests to catch regressions ($DEITY forbid! :) between releases.

Read More

javascript plasmoid errata; rekonq

With the Javascript Jam Session in full swing, a number of people are off to the races writing their Plasmoids in Javascript. That's the good news. The bad news is that they've uncovered some annoyances. So here are some quick notes/errata:

• In 4.4.0 print() and debug() are broken; I thought a commit that made them work had been part of the 4.4.0 tag. Apparently it wasn't. This commit is in the 4.4 branch, however, and so will be part of 4.4.1. Some distributions offer packages that use the 4.4 branch directly, and if you are using one of those distributions I recommend taking advantage of that. :)


• Assigning a pixmap to an IconWidget does not work. e.g. this fails (where icon.png is in contents/images/)
  

  var icon = new Iconwidget
var pixmap = new QPixmap("icon.png")
icon.icon = pixmap

  
  This is due to an unexpected (though understandable) limitation in QScript's magical abilities. It's usually so good on the "principle of least surprise" I was surprised to see that this didn't work. However, all is not lost as you can do this:
  

  var icon = new Iconwidget
icon.setIcon("icon.png")

  
  I've put a QIcon bridge on the 4.5 feature list, though, to make this Suck Less(tm)


• To get rid of a UI element permanently, you can call deleteLater() on it, e.g.:
  

  var icon = new IconWidget
icon.deleteLater()

  
  This was undocumented because I was really hoping to find a slightly less ugly way (e.g. "delete icon") but didn't manage to get to that for 4.4.
  

Documentation continues to be improved and updated, but there are such holes / annoyances. I'll be adding errata .. somewhere .. on Techbase. I'm also working out how best to show API added in later versions, e.g. just keep adding to the current Javascript API page or to start a new page with just additions so it's easy to see what each version adds. Input welcome. :)

On a side note, I've started using the rekonq web browser lately. I'm using it straight from the git repository and even that is nice and stable. The KDE WebKit integration from the KDE Dev Platform is really great (passwords and what not from Konqi appear in rekonq) and my bookmarks are all there. Most importantly, it's fast and in my week or so of usage rock solid stable. There are some rough edges (keep in mind I'm using the mainline devel version of it) and some features I'd like to see implemented (which I'm not going to grouse about unless I find some time to whip up a patch or two or unless a rekonq devel asks me about it :), but so far I'm very happy with it. Some of the features like the thumbnails that appear when a tab is hovered are very nice, however, even if some graphical loving could improve it even more (e.g. fading them in/out would make it feel a lot less jumpy). I think I'll be sticking with rekonq for the time being, which might mean I'll be compelled to start submitting patches to iron out some wrinkles. We'll see. :)

Read More

Javascript plasmoids training session #2 tomorrow!

Today's Javascript Plasmoid training session went quite well. Even I learned some things from it, including what I need to communicate a bit more clearly tomorrow (such as "do not ever call resize in your main.js" :). It even led to at least one bugfix in the Javascript Plasmoid code, related to serviceForSource; there is a simple workaround in 4.4.0 though which I will be sure to share with everyone tomorrow.

Tomorrow? Yes, tomorrow! (Well, it's still tomorrow to me here on the West coast of Canada. :)

At 16:00 UTC in #plasma-training on irc.freenode.net on Saturday February 13th I will be repeating today's session. I will also be uploading tomorrow's irc log to plasma.kde.org; I'll link to it from my blog and identi.ca account tomorrow as well. I have today's logs, but I'd prefer to use tomorrow's session instead as there will be a few improvements to the training session that should really be in there.

Today we had nearly 50 people attend, how many will join us tomorrow? :)

If there is demand, I can do more of these sessions on other days or even on different or more advanced topics. I'd like to focus on the Javascript API stuff for now though to help everyone get up to speed and running for the Javascript Jam Session, which is also featured now in a front page story on TheDot.

Read More

Plasma Javascript Jam Session

Tomorrow at 16:00 UTC we'll be hosting the first Javascript Plasmoid tutorial session in #plasma-training on irc.freenode.net. In case you need more motivation to attend than simply being able to create rocking Plasmoids, let me offer you this:

The Plasma Javascript Jam Session Contest!

Contestants submitting outstanding Plasmoids written in Javascript before March 31^st stand to win an N900, a trip to Akademy or Camp KDE, KDE swag and bragging rights! All you need is a text editor, some imagination and KDE SC 4.4 to test your creations out on. A story on TheDot with further details is forthcoming.

So come join us tomorrow (or Saturday at the same time and in the same irc channel) to get on the fast track to Javascript Plasmoid mastery!

Read More

Plasmate 0.1-alpha1

I'm pleased to announce the release of the first alpha of Plasmate, a Plasma add-on creation tool.

Plasmate uses a number of the great KDE components such as the Kate text editor and various Plasma goodies to present a lightweight "mini-IDE" specifically for creating Plasmoids, DataEngines, Runners and even assembling Plasma Desktop Themes. It includes built-in git support, which is why you won't find a "save project" button anywhere but instead a "New SavePoint" button and a timeline. A documentation browser is also included that pulls documentation from Techbase and api.kde.org.

The intended workflow is this: you open Plasmate, pick what kind of thing you want to create or pick something you had already started and you are brought to a project window with everything set up. So far you've clicked perhaps at most twice and entered a name for a new project. You add code and view it in the embedded previewer as you progress, reloading the preview whenever it's of interest to you and adjusting things like the form factor or screen location (handy for simulating use in a desktop panel, for instance). When you are happy with your progress you create save points (and roll back to old save points when you become unhappy with your progress ;) and at the end of it all click Publish to send your merry creation on its way.

The goal is not to replace KDevelop or QtCreator or to provide a general purpose development kit nor to help people writing things in C++. Plasmate is strictly about dynamic languages like Javascript, Ruby and Python and making add-ons for Plasma applications.

At this stage, we are still in early alpha stage development of the application. So while many of Plasmate's functions work, there are no guarantees it won't eat babies with one hand and lay siege to your castle with the other. (I don't know what that means either, so don't ask. ;) There are a number of unpolished, unfinished and even some unstarted features. Theme creation is basically a stub at this point, the Publish page is mostly functional but not polished, there aren't previewers for DataEngines or Runners, etc.

However, we're aiming for a 0.1 release that we can call stable by the summer and to help us achieve that we'll be doing regular releases of alphas, betas and eventually release candidates. At the start we'll be doing at least one release per month and slowly accelerating as we approach release. At the end of each development time period, we'll be tagging svn and rolling a tarball.

We invite the courages, curious and interested-in-getting-their-hands dirty to check it out and join us in the journey towards 0.1. Here's how:

• The 0.1-alpha1 tarball can be downloaded and used to build from source


• The 0.1-alpha1 tag can be fetch from svn with: svn co svn://anonsvn.kde.org/home/kde/tags/plasmate/0.1-alpha1


• The mainline development tree can be fetched with `svn co svn://anonsvn.kde.org/home/kde/trunk/playground/base/plasma/plasmate` and can be updated with a simple `svn up` whenever desired


• Bugs are filed at bugs.kde.org under the plasmate product


• The developers hang out when available on irc.freenode.net in #plasma


• Development discussion happens on plasma-devel@kde.org

We have a lot to do to reach our goals for 0.1, and even then there are a number of things we'll still want to accomplish (like Qt Designer and the new QML designer integration; a Javascript debugger perhaps; the ability to publish to gitorious from the publish page as well as browse other people's projects there and import them into your Plasmate to work on them there...) With your interest and the start of periodic releases as we go we hope to achieve them all. :)

I'd like to thank the following people who have written code that has ended up in this release:

• Shantanu Tushar Jha


• Diego Casella


• Yuen Hoe Lim


• Richard Moore


• Artur Duque de Souza


• Riccardo Iaconelli


• Frerich Raabe

Cheers! :)

Read More

go with the flow

A new feature release of the KDE Software Compilation has been made, bringing us to version 4.4.0. What a development cycle it has been! I won't bother recapping all the progress made, as you can read all about it in the above links.

With Tokamak 4 coming up in just ten days and the new KDE website up on its feet but still getting lots of love, attention and work done on it, it is certainly a busy time for us all.

Things are not going to slow down one bit, though. :)

There are the predictable events, such as "we will be working on the first 4.4 patch level release as well as features and improvements for 4.5 which will appear this summer". There are also the to-be-expected happenings, such as the odd kerfuffle about this or that (today's one was about KAuth and what it means for Linux distributions such as Slackware). There's more afoot this week than just the usual suspects, though ..

For instance, today I'm working on tagging a first alpha release of Plasmate, the Plasma add-on creation tool, as part of an effort to move Plasmate to a regular release cycle with the ultimate aim of it being in fighting form for 4.5.

I'm also hearing rumblings of at least one very cool KDE event coming up in April that I'll be keeping my eyes on. It's exciting to see the number of quality KDE events growing around the world!

The most exciting thing for me today, however, is an announcement I'm working on that will be going out at the end of this week on February 12th. What is it about? We'll have to wait for Friday to find out for sure, but I do have something related to that announcement that I'd like to share with you right now:

KDE SC 4.4 comes with vastly improved and expanded Javascript Plasmoid support, and I'd like to personally introduce them to you. I will therefore be hosting open training sessions on both Friday and Saturday at 18:00 UTC on irc.freenode.net in #plasma-training. I will demonstrate, step-by-step and with examples how to write Javascript Plasmoids from the very basics on up. All you need to do is bring your enthusiasm, a text editor, a web browser, an irc client and hopefully a KDE 4.4 install to test your creations out with. Each session will last 2 hours, including an open Q&A at the end and you will walk away having written your first Javascript Plasmoids and I will be repeating the material on each day to give you the greatest number of opportunities to catch it. I hope to see you all there!

Read More

krunner responsiveness

The RunnerManager interface in libplasma which powers KRunner (among other interfaces) was designed to allow plugins a-plenty so that one search term could be matched in "real time" by several different components, each one looking for answers in different ways or places. This isn't a particularly unique design by any means, and the concept can be seen in many search interfaces out there.

A "run command" app faces a challenge with this sort of design: in usage, one expects the interface to appear "instantly" when called up and remain responsive during use. This isn't the web where pages can take significant fractions of a second without anyone caring or where we can stack dozens/hundreds/thousands of servers behind your queries to offer mindcrushing amounts of compute power to chew through whatever gets thrown at it. No, we have to be fast with limited resources while looking in all kinds of places. Basically, KRunner has to be as responsive as the KDE 3 minicli while doing orders of magnitude more processing. Interesting problem.

To address the problem we made the query plugins, or "runners", multi-threaded even when we only had 2 of them. This ended up involving lots of queue management, but Threadweaver made that as easy as possible. We got rid of many locks as development went on, improving interactivity, and eventually ended up introducing the concept of a query "session". In KRunner, a session starts when the user interface is shown and ends when it is hidden. Runners are given the opportunity to set what they need during searching up at that point. Later, when the session is over, they can tear down all of that allowing us to conserve resources and not wake up KRunner every time a window twitches. This also helped speed up querying in some cases as it meant moving initialization routines that were being run in some cases on every keystroke to once-per-session.

The prep and teardown for sessions is not multithreaded, however. Or rather, the signals that a session is about to begin and end are not. This gives runners some comforting guarantees as to their ability to manipulate pixmaps or x.org information (things that can not be safely done from outside the main application thread) as well as to the order of events: prep, querying, teardown is a guaranteed order.

The new issue that query sessions brought was that some runners have grown time consuming code that is run during session preparation. There were a handful of runners that were taking 20-80 milliseconds each every time the user interface was to be shown. That may not seem like much, but it quickly added up to over 150ms on my dual core 2Ghz laptop which is very noticeable to the human eye. Since this code was running in the main application thread, popping up the KRunner window felt really slow. The question was: which runners were responsible for this and why? Some profiling was in order!

So I popped a small three-line patch into libplasma that measured how long each runner was taking during session preparation. The problem plugins were immediately highlighted. So I went through each of those and did some profiling to see where they were spending their time and pushed code around until the prep time was more reasonable. Most of the work was taking synchronous operations and making them asynchronous. At this point, none of the runners on my system take more than 1-2 milliseconds to prep, which means instead of waiting 0.15 seconds for something to happen after I press Alt+F2, it appears almost immediately. The difference is very noticeable and very pleasing.

What's interesting is that, with one exception, none of the runners are doing any less processing. In fact, in a couple cases they are doing a little more (though nothing to write home about), but the result is something that feels much smoother and more pleasant to use.

I backported the results after testing to the KDE SC 4.4 branch. I don't think the improvements will make it into 4.4.0 (it's already tagged and being packaged) but should be in the 4.4.1 release at the latest. So if you have been finding KRunner sluggish to appear and build from sources, try updating kdebase/workspace/plasma/generic/runners/ and kdeplasma-addons/runners/ and see if things improve after a restart of KRunner.

Read More

interesting bits in 4.4.0 for plasma-*

With KDE Software Compilation v4.4.0 tagged and going through final release engineering processes, early reviews and discussions about it are appearing around the Internet. It's great to see the interest bubbling around it all.

One interesting meme is that "not much has changed". That sentiment is a sign that things are settling down nicely in KDE 4: things aren't moving around as much and there's a sense of predictability again. This is an important milestone.

However, some people are under the impression that pretty much nothing has been done except "under the hood changes". I think this highlights a challenge for our communication around SC 4.4.0: just because KDE 4 has hit an externally visible stable trajectory and the SC 4.3 -> SC 4.4 jump is smooth, that doesn't mean that there aren't lots of new and exciting things in SC 4.4.0.

Let's take the Plasma Desktop, for example. As can be seen in the 4.4 changelog for libplasa, plasma-desktop, plasma-netbook and krunner, we've been busy doing as much new stuff as refining the existing.

We have added a number of "usual suspect" type things: drag-and-drop for wallpaper plugins, ten new Plasma widgets, one new DataEngine and five new Runner search plugins. Let's not forget, though, the plasma-destop Kiosk lock down features or the brand new Plasma Desktop Scripting tool for sys admins, power users and packagers. This feature is being used in several upcoming distribution releases already and offers something KDE has never provided before. (In fact, does anybody know of any other production system that provides such a system for the desktop shell layout?)

Then there is the first release of Plasma Netbook, which is a whole new shell consisting of a little over 6,700 lines of code that isn't shared with other Plasma apps.

There is also the new mouse actions plugins that let you associate any combination of mouse and meta-key (Control, Alt, etc) on activities with actions. In KDE SC 4.4.0 there are six such plugins included: activity switcher, window list, desktop switcher, default context menu (highly configurable, btw; you can turn on/off pretty much every individual entry via the config UI), paste (e.g. to attach to middle click :) and an app launcher. Sensible defaults are provided for these, and those defaults can be overridden by an libplasma application to suit its needs. Since they are plugins (and the API is part of libplasma, so guaranteed to remain BC from SC 4.4.0 on out), it's also possible for people write new plugins of their own. You aren't limited to menus, either!

We have Plasmoids in the system tray, improved and extended animations and many other improvements. Per-virtual-desktop-activities is very smooth in SC 4.4.0 as well, and there were multi-screen fixes even.

Then there are all the nice improvements in KSysGuard and more than you can shake a stick at in KWin, so if we want to cover the KDE Workspaces we'd have to go on for quite a bit longer than this one blog entry. Then we'd have to move on to all the applications that come with a KDE Software Compilation release, many of which have individually important improvements.

It is quite true, however, that much work did go into refinements, bug fixes and infrastructural improvements. For me, the KDE SC 4.4.0 release is a very well-rounded release in this respect. It is full of new features and capabilities (without becoming a Frankenstein of configuration overhead, either!), but it is also full of good maintenance work. This is why, combined with KDE SC 4.3 being a good predecessor, some aren't noticing the new things we're delivering in this release.

Hopefully we can communicate both the feature adds as well as the refinement work effectively, because that is indeed the whole story.

Read More

n900, thoughts

I received an N900 a couple days ago and was quite excited to unpack it. It came with the usual dizzying array of wires for power, audio, etc. The instruction manual was short but useful. The box was a nice charcoal gray. Yadda yadda yadda. Those were all but details, of course: I wanted to see the thing in action!

Now, I don't intend to keep the stock UI on there for very long. This device will be traveling with me to Tokamak IV to get a make over, but I wanted to have a good feel for what it was already capable of and how things worked. I've been working on bug fixes, mostly for Plasma Desktop and scripting, for the upcoming 4.4.0 (sometimes into the wee hours of the morning) so having something to play with in between debugging sessions has been nice. What follows below are my impressions of the device to date, all which is just my personal experience and personal opinions. Don't take them as gospel or even as a proper review.

Hardware

The thing is a bit of a brick, but that seems to be the Nokia aesthetic. It's small enough to fit in my pocket and while it weighs significantly more than my LG phone it's not off-puttingly heavy.

The heavy bevel of the N800 series is gone and the screen is much more attractive as a result. Playing movies on the device is actually very enjoyable: video playback is smooth (as is pausing, seeking and audio controls) and the picture is crisp and rich in color. The various graphical transitions between applications is very smooth for a phone. P. noted early on that it is a lot nicer than the iPhone his mom has due to these things.

The camera and speakers are similarly nice. They certainly aren't going to replace a proper camera, still or video, quite yet but they are better than the ones we have in our various phones around the house here.

I still have 26.5 GB of storage available on the device and once plugged into my laptop with the included USB capable, not only does it start charging but I can mount it and start chucking media and other files onto it painlessly.

The keyboard is well done and works nicely for thumb typing. The kick stand in the back is a little too small to keep it stable on a table top while pocking at images or web pages, though.

Software: The Good Bits

Being able to multitask is a god-send. Having a phone that you can easily add software to with a nice point and click interface is tremendous. (Hello, apt-get! :) The included media player looks good and works well, even if it isn't jumping up and spinning around the room with bells and whistles. Details like having media that is playing pause when you switch to a phone call or some other similar "I'm now busy, no audio please / I can't watch something right now" context, and then have it resume when the context is left, is great.

There really are a large number of details that it gets "right". Swiping to move between widget layouts on the desktop is smooth enough and works nicely. The application task management is rather nice, such as the transitions that happen when you close an app while others are running.

Nice prompts to import contacts, and that the contact book seems to be pervasively shared by apps on the phone show nice attention to software integration. The notification bar that pops down onto the screen is noticeable without being annoying, easy to read and easy to dismiss; bonus points to whoever got that oh-so-right.

These are all great things. Up to this point, I could really feel the potential of this phone platform. Excitement flowing through my veins and all that jazz.

Software: The Flip Side Of Good

Unfortunately, there are so many warts on this otherwise amazing bit of kit that I'm not sure I'd actually recommend it to others who "just wanted a good smart phone". Why? Most of the software, well .. sucks. I'm really hoping that the updates that will be arriving before the N900 is more widely available will plug most of the holes I stumbled across, but for now the N900 simply could not replace my current S60 phone. Let's look at some of the things I ran into.

I managed to lock up the device while setting the time in the setup app that is available when the device is first turned on. The only way to set the clock is to rotate the hands using touch. That's cool, but there's also a little label that shows the time right there and it's completely non-touchable. I could live with that ... if the analog clock wasn't prone to locking up the input on the device. :/ (Insult to injury for me: no Canadian cities, regions or timezones on the device.)

The email application looks reasonable, except I can't use it because it can't authenticate against my IMAP4 server which uses the "plain" login method over TLS.

The WiFi plays well with some AP's but not others. At the coffeeshop here I can download and browse like a mofo on the thing, but here at home it's so bad I can't download software or updates for it and the web browsing is a bit of a pain.

UPDATE!: Armijn told me that Sebas told him (small worlds!) that this is a known issue and can be dealt with by turning off power management when connected to troublesome APs. The way to do this is to go into the settings app, go to internet connections, press Connections, select the problem AP, click Edit then Next, Next, Next to the end where it offers an Advanced setting button, press that, click on the Other tab, select "Off" for "Power saving", dismiss the scary warning about it taking lots more power from your battery and voila ... intarwebs come a-streamin' down the tubes that were once cloggedy. ;) Thanks Sebas (who needs to go pick up stuff at Ade's place! ;)

The GPS doesn't seem to want to pick up satellites and the included mapping software doesn't let me bookmark locations (e.g. where my home is); or if it does, it's very cleverly hidden. The download-maps-over-whatever-connection-you-have-for-the-are-you-are-viewing is a nice step up from the N810, though.

The "app store" is anemic and too often I have to try to download an app more than once because it "can't connect to the server", even when I'm connected to a "good" AP for Internet.

The idea of tracing a spiral to zoom in/out of the web browser just doesn't do it for me, and web pages don't automatically scale to anything resembling a useful size in too many cases meaning that I'm starting to actually get good at that spiral motion. Stumbling upon a website with an unsigned SSL certificate sent me through the obnoxious Firefox "obstacle course of certificate exception approval"; worst of all it is exactly the same one as on the desktop. That means it doesn't fit on the screen and all the buttons are rendered using the default themed Gtk+ widgets. Compared to the rest of the slick chrome on the device, these web browser dialogs stand out like ugly ducklings with no hope of ever becoming swans. The thumbnails for browser history navigation is really neat, though.

Then there are the Mystery Zones on the screen: when a prompt with information and confirmation buttons (essentially the Maemo version of an informational or yes/no dialog) appears there is no immediately obvious way to dismiss it. You just have to press somewhere outside of the area to cancel the action or dismiss the information. That means there is a button saying "Yes, do this!" right there, but the "Get me out of here!" isn't obvious at all. When you are in the application launcher (a grid of icons, essentially) if you press just outside one of the icons (and with a finger that's really easy to do) it also triggers this "cancel the operation" Mystery Zone and the application launcher goes away. To get to the "desktop menu" stuff (for things like internet connections or setting your theme and background) you have to know where to touch (the top of the screen) and when (when the "desktop" is visible).

Which brings us to the desktop. It's separate from the application launcher and so I'm constantly feeling like I'm dealing with two paradigms that don't like each other much. One is the desktop with widgets, the other is a smart phone interface with icon grid launchers and app stores. As P. said, "This is really complicated." Yes, son, it is. Really annoying is that while you can set the background or theme from the "desktop menu", you can't launch the device's settings app. No, that's buried two different clicks away (three if an application is running). Networking, time, bluetooth and USB connectivity, audio volume and profile setting is in yet a different hidden menu on the destop (in the status area). At least this, however, shares the look of the "desktop menu", unlike the settings application.

I could go on as well about things like how the kinetic user interface elements like the flickable list boxes really don't work overly well, or how the 'rounded corner' widgets have bits of black squares in the corners (composition failure, no doubt) but .. well .. I think I've already said enough to give you an idea of the impression I've received.

Not Just Light, But Rainbows, At The End of the Tunnel

If this was a normal device, I'd be left with mixed feelings. I'd be really enthused about some things about the N900 but totally discourage about others. I'd probably discount it as a contender for now and wait to see how the software updates go over the next few months, fingers crossed.

Thankfully, this isn't a "normal" device, relative to other devices out there on the market. The N900 is an open software platform. I can work on it and replace the bits I don't like. I can fix things and improve things to my heart's content (and time budget).

This is why I see not just some light but full-on rainbows-in-technicolor-glory at the end of the tunnel. When Qt hits this device in all its glory, there will be a very powerful stack of software that works very well on these kinds of devices that we are very familiar with and already have a ton of software built on top of. At Tokamak 4 we will have a few N900s, all of which will be sporting Plasma interfaces before we leave I'm sure, along with 4 smartphone-ish devices from Intel to give similarly loving to.

Right now, as I type these words, I am imagining this device with a beautiful Plasma powered interface. Qt applications galore, a sensible melding between apps and widgets and a more unified UI experience that not only blends with but works seamlessly with my laptop and netbook with all of that wonderful, wonderful hardware pulsing and beating beneath it, driven by what looks like a rather nice kernel and userland.

The N900 (and other such devices) are ours to make in our own image. They can be, and as a result will indeed become, more than they have been originally designed to be. This is what happens when a shared commons is allowed to blossom with Free innovation and Free market concepts.

Others will have different ideas for it, I'm sure, and it will be very exciting to see what others imagine into life on these kinds of devices. Ultimately, none of us are locked in on these devices. We don't need to be happy to plod away on individual applications that play in someone else's jailhouse lock-in system, like some slave who's "allowed" to go into town on their own on Sundays. We aren't relegated to only creating Free software that rocks on our desktops (even if that is all I've been personally doing these last couple of weeks :), we can make stuff that rocks quite freely on almost any kind of device form factor we wish.

I remember dreaming about this part of the future as a young person. It's odd, in the most wonderful way, to be smack-dab in the middle of it playing out in reality.

A Word on Closed Device Platforms

I remember when BeOS R3 was released for the Intel platform and talking to some of my friends who were great fans of it . "Linux will never gain traction next to other niche operating systems that are so much more slick than it is," one of them said, hailing BeOS as a nail in the coffin of Linux outside the server room. "No chance," I said. "Yes, BeOS is far better than the Free systems. But it is a guaranteed dead end because it is closed. That can never compete with an open ecosystem. That only works for entrenched players and monopolies." (Irony in the story: BeOS lives on today, more or less, as a Free operating system called Haiku, to which the KDE Free software stack was recently ported to.)

I've seen this played out many times while I've knocked around the industry. To maintain a closed ecosystem in the face of an open one, you have to be insanely better (mostly at lock in techniques) or have a monopoly position. Open ecosystems far too easily generate a network effect that can quickly trump funding, partnership politics and even quality.

There is no successful, closed ecosystem monopoly in the devices world yet. There is Apple (who is growing, almost entirely due to there being a vacuum to fill), there is Android (which isn't open enough to avoid the pitfalls and pratfalls of competing against truly open ecosystems), there is Windows Mobile (but that's all a lark these days) .. but nobody has claimed title of Insurmountable King of the Hill (IKotH). Any of these players can tumble down, and likely will if they stick to their closed ways. This isn't to say they can't carve out a respectable and even sustainable niche, they just won't define the market long term unless the open up.

Open stacks based on Linux, Qt and similar tools are in a much better position simply because more people and companies can participate and therefore create a larger pool of shared resources that is hard to impossible for a closed platform to match without joining in. (Let's not forget that S60 is opening up, either, and bringing Qt along with it too.) I don't know what the ultimate role Maemo itself will play in all of this, but in an open ecosystem it doesn't need to be IKotH to be successful either, anymore than any of the Linux distributions need to be IKotH in the server space for server side Linux to flourish.

The only thing that could fail us now is for too many of us to consider open device platforms to be uninteresting and "somebody else's problem". This is one big reason why I've spent a good porition of the last few years of my life working on a software stack that I feel can be transported between the various kinds of devices I'd like to use. I want to be one small part of the huge success that can be, nay, will be the open mobile space.

Over the next few hours, though, I'll be working on a folderview bug that exhibits on multi-screen desktops. :)

Read More