be vewwwwy quiet .. i'm hunting pixmaps.

There's a great tool in KDE's svn called kdumppixmap. Once built, you run an app with `ktracepixmap ` and it says something like "Starting with pixmap tracing. Use kdumppixmap to save currently allocated pixmaps to disk". You wait until the application is in the state you want it to be in and then you run the kdumppixmap command it gave you. This creates a directory full of image files, one for each pixmap sitting on the X server. It was written by Maksim Orlovich, who borrowed some code from Geert Jansen's kstartperf and from kBacktrace.

I've spent time yesterday and today with plasmoidviewer and a tortuous little plasmoid I wrote in Javascript that has 150 buttons, 150 line edits and some other assorted jumble in a grid layout. The goal was to eliminate as many pixmaps as possible, and at 18:00 on day two, I'm quite nearly there. Here are the areas I traveled in my pixmap hunt and what I found while doing so; hopefully others will find it useful as well. :)

The FocusIndicator

The first stop was the FocusIndicator class which draws those pretty little halos around buttons and other things when you mouse over or give them keyboard focus. It had its own copy of the FrameSvg that creates those images from a raw SVG file, and it did a few unnecessary things at start up. After fixing that, there wasn't any reduction in pixmaps (sadly), but creating a button, line edit, combobox or slider got twice as fast. The remaining overhead is now in QGraphicsProxyWidget, of which there is probably desperately little we can do right now. (QtComponents is our likely savior in the mid-term; no short-term relief, however).

The PixmapTransition Animation

We do a lot of nice little animations in Plasma. You may not have noticed, but when you mouse over, press on, give focus to, etc. nearly any widget the visual states smoothly transition from one to the other visually. This is usually done using an animation called PixmapTransition, which does exactly what the name suggests.

One of the caveats of such a thing is that it needs to align the pixmaps first. No problem, just calculate some offsets, right? Well, it turns out it was doing that, but then creating new pixmaps with the original images repainted at those offsets in them. Which meant that every time it was used, there were usually two extra pixmaps kicking around needlessly. Now it just calculates the offsets and uses those in painting.

With those two gone, there was one left: the result. The way the animation works is that the animation timer ticks along from 0 to 100 over a given period of time (and a given curve). On each animation tick it would generate a new result pixmap and tell whatever it was animating (e.g. a push button) that it needed to repaint itself.

Thing is, most of the elements in Plasma are already buffered quite nicely and don't need this extra pixmap sitting around. So I made the caching optional and off by default. I also moved the creation of the pixmap into the method that the item being animated uses to get to it. This moves the creation of the pixmap out of the animation frame tick and places it at the moment the pixmap is actually used. This means that it now only creates frames in the animation that will actually get painted. Previously, if the animation loop is ticking along faster than the widget can repaint, then a bunch of painting operations that the user would never see on their screen would be generated. No more.

FrameSvg

So now we were down to just 1/3rd the number of the pixmaps being held on to, and a lot more efficient generation of the pixmaps we did use. But as kdumppixmap was showing me quite plainly, we still had one pixmap of the background for each button (or whatever) even if all the buttons were the same size and disposition. In other words, we had N pixel-identical pixmaps, where N is the number of identical items on screen. This just wouldn't do, and so I took a dive into the primary culprit here: FrameSvg.

This class creates nice four-sided frames to put around buttons, Plasmoids, tooltips and what not. It's used quite heavily in Plasma and to keep things speedy it has its own local cache on top of the on-disk cache in Plasma::Theme. This cache was per-FrameSvg object, however, and the source of all those pixel-identical pixmaps that were jeering at me from Gwenview. Damn you, pixmaps!

So I implemented a small reference counted caching system whereby identical frames are shared between FrameSvg objects. Finally, I had one pixmap for the buttons (well, four, due to different states of the buttons as I went around clicking on them) and a similar number for the lineedits. Instead of hundreds and hundreds of pixmaps, I now had a couple dozen for the entire plasmoidviewer session. The savings were well over 2 MB of pixmap data in the X server.

The Impact on Plasma Desktop

A Plasmoid with 200+ individual components in it which are all the same size in a nice little grid doesn't sound particularly "real world" does it? I also tested with a default plasma-desktop session and it turns out that, indeed, the savings are not quite as dramatic .. but they are significant.

On starting up a default plasma-desktop layout, there's ~1/3rd fewer pixmaps due to the FrameSvg caching, and several dozen fewer on top of that due the rest of the work on things like PixmapTransition. Each pixmap avoided is less X traffic, less video memory and a generally smoother experience.

During usage, a lot of transient pixmap creation is avoided as well. For instance, the tasks widget uses Plasma::PaintUtils::transition to fade the tasks buttons in pretty much the same way the PixmapTransition animation does (in fact, it seems the only reason it isn't using PixmapTransition is that the tasks widget predates PixmapTransition). As such, it gains the same benefits that PixmapTransition has, namely two fewer pixmaps per animation step.

The more Plasmoids you use, the more you gain, of course. Things like the panel controller and other such window dressings also benefit.

The Impact on Plasma Mobile

The impact on Plasma mobile should be even larger, as "bunches of things of the same size" is a very common occurrence (e.g.a phone dialer, a grid of app icons, ..) and graphics performance is a rare commodity. Keeping the animations tamed through fewer generated pixmaps, only generating pixmaps actually pushed to screen, etc. helps out as well. I don't yet have numbers of the impact on the N900, but it can only be good news there if it's noticeable on a desktop system.

So, a reasonably good investment of effort. All of this should end up in the 4.6 release coming in January. If you'd like to enjoy the benefits of these improvements now, we'd enjoy you helping us test things prior to the release. :) I know Suse provides some great packaging options for up-to-the-day builds and there's always the "build it from sources" option (kdesrc-build really helps making that easy to achieve).

Read More

a pursuit of joy

I have a knack for tending towards seriousness. This is sometimes balanced out by my penchant for the absurd and light hearted. Sometimes. Too often, however, I drown myself in thought and effort and veer towards over-focusing on certain things while paying too little attention to others. Eventually my motivation suffers because the joy in doing things starts to leave me. Finding the joy in things is more than just a nice idea, it's a survival skill.

The last couple of years have been necessarily serious in nature for me, both in personal and professional matters. There are many reasons for this, and I won't bore you all to tears with them. I am happy with many of the results of those efforts, though less than happy with others. Hopefully I've learned a thing or two from the latter. In any case, things have been arcing in a wide sweeping movement towards subtly new directions for me this year.

It has become time to re-find my joy in the various things that I cherish, but in which I have perhaps allowed too much seriousness to creep into, even if required by time and circumstance. It has been a prickly feeling under my skin for the last couple of months, a cocoon I find myself slowly emerging from with new skin to live in.

(Which is odd: we are beginning the march towards Winter, and I am experiencing Spring. I am usually more in step with the seasons than this.)

This has come in the form of simple things: I have finally searched out and found my favorite shampoo again, which happens to be a tea-tree infused magical concoction without any dies or colors or environmental nasties that opens my eyes jubilantly wide with each shower.

It has also come in the form of far less trivial things: I am moving, for the second time in two years, no less. I hate moving as a general rule, but this one has a great motivation: to share life with a special someone for hopefully a long, long time to come. So it is that I will be leaving North America altogether at the end of this Winter to makie a new home in Switzerland.

In between the trivial and the profound, another place I'm aiming to find joy again is here in my blog. It's been somewhat stunted, minus a few bright moments here and there, of late. It got more serious and less personal and more .. well .. less joyful. :) I'd like to shift that, to indulge in my joy in writing here again.

To kick this all off, I thought I'd share a little story from my childhood that came back to me in the shower this morning as the shampoo was doing its magic on my mind. It's the first clear memory I have of experiencing that "a-ha!" moment, something that I have since pursued through attempts to identify, analyze, solve and create. It involved airplanes and playing outdoors and wooden sticks and numbers. So many of the good things of childhood, really. ;)

I was 8 or 9 years old at the time and was playing alone outside on a beautiful sunny day. I saw one of the float planes that take off and land in the waters around the town of Sechelt several times a day pass overhead. As it made it's noisy way above me, I began to wonder just how high up it was. I became entirely lost in the thought of figuring out the answer. Figuring that I couldn't actually get the answer in practice, I set about thinking how I could in theory.

So I imagined myself in a simpler, more perfect scenario to bring the problem within my grasp. In this imaginary place I was standing in a flat, wide grassy field with the airplane in the sky high above and at some distance away. The sun was directly above the airplane, and as such it was casting a shadow that landed directly below the airplane. I figured that I should be able to see this shadow, and if I could somehow measure the distance from me to the shadow on the ground, then measure the angle with which my head was tilted to look at the airplane ... perhaps I'd have enough information to figure out how high the airplane actually was. I ran back to my bedroom and got out some straight wooden sticks from one of my toys and started playing with them on my bed: indeed, if I knew where the shadow was and the angle of my head and that the airplane was directly above the shadow (giving a perfect right angle), there could only be one solution for how high up the airplane could be! What a wonderful idea! I lit up inside with the fireworks of discovery. Just imagine, I thought, at all the things one could accomplish with this idea of solving triangles.

I ran to share my "discovery" with my mother, who calmly informed me that it was called trigonometry and had been discovered ages ago. She was doing the dishes at the time, and from what I recall continued to do so without stopping during our exchange. It was a little disheartening, to be honest, that she didn't share my enthusiasm and that my little idea had already been found and was common knowledge. Rather humbling, in fact. I never did forget the rush of discovery, though. Or the realization of how hard it was to think of something someone else hadn't already thought of.

I've been in pursuit of that feeling ever since, with occasional success, returning to that wonderful warm surge again. Sometimes it's a trivial thing, like writing a poem that manages to strike just the right nerve in me. Sometimes it's witnessing the creation of something new and unexpected and better unfold before me. (Which is why I far prefer live music to studio recorded music, and one reason I find such joy in writing software.) Sometimes it comes from managing to find a new way to perceive the world around me in a way that sheds a different light on what I had once thought mundane or intractable. This is, at its most basic level, a pursuit of joy.

I have not done quite enough of that recently for my own liking, though, and this is a personal reminder to myself to fix that. Perhaps I'm now one blog entry closer. :)

Read More

copyright assignments gone wild, or why i can not join Canonical's contributor agreement program

When it comes to organizations involved in tending to Free software projects, I personally take a view that is probably deeply colored by my previous life experiences in business. Which is to say, it's probably a bit boring, conservative and balances out my raging enthusiasm for community.

In my opinion, there is a responsibility for such organizations to identify, define and manage risks related to the responsibility of oversight of what is a very valuable item: the intellectual and creative work embodied in the software products. This is ignored only at great risk to the software, its users and those responsible for the continued development of the software. As a whole, the Free software ecosystem fails more than it succeeds in this, though it is getting better every year.

As a result, I see on a disturbingly regular basis non-profit foundations causing problems for the projects they were formed to support because such oversight was not well defined or managed. (Personally, I feel that a professionally managed service to create and build in the right oversight tools would be invaluable to the Free software community; too many hackers screw this up badly with significant consequences, which is understandable in the sense that they are hackers not lawyers or business people. Linux Foundation, FSFE: are you listening? :)

I also see copyright violations by third parties being brought into the light regularly and distributed copyright often getting in the way. One way to mitigate that is copyright management agreements, such as the FSFE's or KDE e.V.'s Fiduciary License Agreements (FLA), which empowers a trusted third party to act on contributors' behalves without removing any of their original rights while simultaneously setting out firm boundaries on what those third parties are allowed to do. (Such as: "they can't change the license to a non-Free one.")

I also see huge issues popping up around patents, with various remedies with varying levels of utility being put in place as stop-gaps while people work towards actually fixing the patent system (a lifetime's work, really). These include the Open Invention Network (OIN) and including patent clauses in copyright licenses.

Managing the risks around intellectual property law is critical to maintaining the reward of the wide open green pastures of Free software and open source development in a world of business, government and intellectual property law. I am quite firmly in favor of such risk management, to the point that I was one of the people who helped ensure KDE e.V.'s FLA came into existence and that KDE e.V. signed on with OIN.

Now, I'm not a lawyer, and as such I would never, ever give legal advice to others. I can only share my thoughts based on my experience and explain my own personal decisions so that others may, at their discretion and risk, factor them into their own thinking on the matter.

This is all a very long preamble to me making this statement:

It is my personal opinion that Canonical's Contributor Agreement program is, in its current form (as of Sept 2010), flawed such that I can not participate in it due to the risks it brings me and my Free software contributions.

I am making this statement because I was recently asked to sign Canonical's agreement, but I could not. I sent an email of declination today along with the following explanation for my decision:

Normally i would have no problem with doing this, except that the contributor agreement is flawed in a number of ways.

I'll ignore the dubious legality of "signing" the agreement by email, because that's really Canonical's risk, not mine.

However, while I can ignore that oddity, what i can't ignore are the following items in the document:

• Para 3 allows Canonical to adjust what is covered at their discretion with no boundaries. By adding an entry to http://
  canonical.com/contributors Canonical gains access to my copyrights in that project. There is no express boundary or definition to what Canonical can add to that list. As a result I can not guarantee that my contributions to any possible project listed there could be held under this contract. Therefore, I can not in good conscience sign the document.


• Para 4 does not provide sufficient definition of what "submited to Canonical by me" means. In this case, I committed code to a repository. How is that submitting it to Canonical? The problem here is that, due to it being so vague, that nearly anything I commit to a repo that Canonical claims maintainership of (regardless of where it is hosted, it's previous history, etc.) could fall under this wording.


• Para 6 says, "Canonical may also, in its discretion, make the Assigned Contributions available to the public under other license terms." This means that the "ordinarily" wording of the first sentence in the paragraph is a "gentleman's agreement" and not actually meaningful in the least. Canonical is fully within its rights to release such code under, for example, a proprietary license. It could hand those rights over to another party as well, given how this agreement is worded. That runs counter to the ethics I hold which have led me to dedicate my professional life to Free Software.


• Para 8 would put a legal requirement on me to notify Canonical if I even become _aware_ of any possible patent (or other IP) issues relating to my contributions. That is highly onerous, and I do not have the time or financial resources to be able to commit to such an absurd burden.


• There are no termination clauses, meaning that no matter how I feel about Canonical (or Canonical about me) or what actions Canonical (or I) perpetrate in the future, there is no clear provision for how to terminate the agreement cleanly.

Since the agreement does not allow for ammendment (see para 13), I regret that I can not enter into an agreement with Canonical based on this document. I am not opposed to such agreements in principle, as I have signed similar agreements with other parties. The material difference in those cases was that the terms were reasonable and well defined and were accompanied with clear guarantees as to how the rights I am signing over will be managed.

If Canonical can present me with a reasonable document (the FSFE and KDE e.V.'s assignment documents meet that requirement very nicely, as just two examples), then I'd be happy to sign.

I am sharing this with you, dear readers, because I am sure some of you have also been asked to sign on with Canonical's contributor agreement program and I am concerned that perhaps not all have considered the implications of the wording of their document.

The only thing worse than risk management is bungled risk management, as it creates new and unintended risk (which often means it's also undefined in scope!) for those you care most about. It's a great way of unintentionally damaging your allies and partners.

I hope Canonical produces a better document in the future, for the sake of all involved. It has the right intentions and even some aspects done "right" in my estimation (such as the license-back). As it stands now, though, it is my opinion that it is too broken to be safe for me as a Free software contributor to sign it. I do applaud their efforts to be responsible with the Free software they tend to (and wish more entities in our ecosystem would show a similar awareness of their responsibility), but another go at it with a more thorough and sound legal treatment is in order.

(This blog entry is not legal advice. :)

Read More

plasma documentation writing, friday and saturday

When we were kids we'd play this fun little game called "dog pile". The idea was simple: everyone jumped on top of one person creating a big pile of bodies. The idea was to avoid being the person at the bottom and/or from being suffocated if you were. Ah, such fond memories of struggling for breath beneath the crushing weight of a pile of fellow children.

This wonderful childhood game lives on in the phrase "to dog-pile on something", meaning that you pick a target and everyone leaps onto it. In the age of online social networking this has become a rather common way of doing things. (For better and for worse. :)

In Plasmaland, we often dog-pile on a specific problem with everyone leaping bodily onto the task until there is no more task to be had. Making all of our Plasmoids implement configChanged() was done this way, for instance, with great success. It's fast, efficient and injects some urgency and fun into the mix. Much nicer than working alone on implementing the same thing 50 times over. ;)

Dog-piling is not just for coding, though. We can also use it for documentation writing. So I'd like to invite you, dear read, to join us in a Documentation Dog Pile. The goal will be to document as many aspects of Plasma Desktop and the Plasmoids (which, incidentally, is going to be the name of my next 50's tribute rock band) as we can on Userbase. Just look at how awesome such documentation can look!

I will be hosting this dog-pile-on-the-docs Friday the 17th and Saturday the 18th starting at 15:00 UTC both days on irc.freenode.net in #kde-docs. Given that I'm in UTC-7, this means I'll be rising very bloody early, but I love you people who live in my perpetual future so much that that is what I'm going to do. We'll go until nobody is left. :)

How will it work? Each attendee can pick the Plasmoid or aspect of Plasma Desktop of their choice, announce their intentions in the irc channel and then start writing about it. You'll have the support of KDE people to answers technical questions, proof-read and help with wiki-fu as needed. Personally, I'll be working on documenting the new Activies features and user interface.

You don't need to be an excellent writer or a master of the written English word. You just need to have the desire to help out and be willing to write your best. We'll have our team of ravishing editors (you didn't know we had such a team, did you?) descend upon the efforts and fix up whatever needs to be fixed.

If you are more interested in writing in your native language, we also need all the existing documentation translated, and so you too can join us and do some writing.

When it's all over, I'll post the results here in my blog. Let's make those results fantastic! To sum up:

• What: Plasma documentation dog-pile!


• When: this Friday and Saturday


• Where: irc.freenode.net in #kde-docs


• What To Bring: Your installation of Plasma Desktop and/or Netbook, your enthusiasm, a keyboard, an irc client such as Konversation or Quassel and a web browser pointed at userbase


• The Goal: Terrific documentation for Plasma, and a lot of fun in the process!

See you there!

Read More

do plasma widgets dream of krita wallpapers?

It's really impressive how good Krita is getting these days. A look through the Krita showcase demonstrates quite admirably what someone can do with it. What strikes me most while looking through those images is how not all of them look like they were done with a computer, but could just as easily be scans of natural media artwork.

I have Plasma on the brain, however, so of course I immediately jumped into thinking about what this could mean from a Plasma perspective. Yes, I'm aware that any connection between a great natural media painting app and a component framework for building primary user interfaces is probably not immediately obvious. No, I wasn't thinking about how to use Plasmoids in Krita, either.

What did occur to me while I gazed at the Krita showcase was that 'organic / natural mechanics' has been a baseline principle in designing many aspects of Plasma, and here I was looking at very natural looking pieces of art. I started to drift a bit and wonder if Krita couldn't be used to create some very beautiful, very compelling wallpapers and / or start up screens for Plasma Desktop? This would help communicate visually the direction we're aiming towards in Plasma and might be something unique in terms of default presentation of a desktop.

Wallpapers are a pretty unique and oddly difficult component of the visual design, though, and I'm not really sure if an app, such as Krita, that is oriented towards creating fine art can be used to produce something that could be used as a default.

I am, however, not a serious visual artist and I'd love to see the genius of others and be surprised and inspired. So, at the recommendation of gstarwind on identi.ca, I took it to the Krita forums. You can see the thread here.

Let's see what happens.

p.s. I apologize to Phillip K. Dick for totally abusing his title by twisting it into the barely recognizable silliness that graces the headline of this blog entry.

p.p.s. For the record: I have never dreamed of sheep, electronic or otherwise.

p.p.p.s. some inspiration for the day; it makes for great background audio if you are one of those people who can work and listen at the same time. :)

Read More

15 minutes of fame screencast

I recorded a quick screencast today about some 4.6 (and one 4.5.2) things. It ended up being exactly 15:00 minutes long, though that was more accidental than intentional. It covers:

• Folder on-hover popup lives again!


• Plasma KPart, being used by Kontact, Skrooge and KDevelop


• Javascript Addons, aka "plugins written in Javascript for plugins written in Javascript"


• Using desktop scripting template packages as Javascript libraries

Direct link to video (in ogg format, of course :)

It's may not be the most sexy of stuff, but they are the kinds of things I get to work on. ;) Fortunately, I enjoy doing so.

We're still very early on in the 4.6 cycle and there are a lot of other things in the works which aren't screencastable currently, but as they mature I'm sure one of us Plasmaters will produce some more screen grabbing fun.

Read More

using configChanged() in your Plasma widgets

With the advent of Plasma shell scripting, a rather large implementation hole in our widgets started showing through: almost none of them were able to react to external configuration changes. That means that when altering a widget via a script, configuration changes simply wouldn't be picked up.

We scampered through the most fundamental ones for the 4.4 and 4.5 releases, but in 4.6 we have committed to all of the widgets we ship being re-configurable via scripting. We're actually almost done, thanks to efforts by people such as Ann-Marie (KDE Edut and Plasma Picture Frame fame) and Anthony Bryant (a relative new-comer to the Plasma scene). It's been a relatively easy grind, actually, perfect for even newer developers because all the widgets needed to do was implement the configChanged() slot.

The rule is simple: in configChanged() (a public virtual Q_SLOT), all config values should be read. The common practice is to therefore call configChangd() from the widget's init() method. When the configuration interface is shown, it is also automatically called. This happens after anything that is connected to the configuration dialog in the widget's createConfigurationInterface method, which means that the widgets now have one slot connected to the configuration dialog's applyClicked() and okClicked() signals that does all the configuration data writing (taking values from the config dialog), and configChanged() which is called automatically which reads these values back in and does any updates necessary to the widget in response.

The beautiful this about this approach is that if your configuration dialog works, then it is guaranteed that your widget will also work perfectly with scripting or any other behind-the-widget's-back configuration changes.

What about all those scripted Plasmoids out there? Well, it's the same idea, just a bit simpler. Most scripted Plasmoids get their config dialogs "for free" just by including the correct ConfigXML and QtDesigner files in the package. When the configuration changes (either due to the config dialog or scripting), then the configChanged method is called in the script. In the Javascript bindings this means doing something like: plasmoid.configChanged = function() { .. do stuff in reaction to changes .. }

Oh, and if you are looking for other similar easy-to-get-into tasks, we're once again keeping up a page of such tasks over on community.kde.org.

Read More

school starts

School here in B.C. started up again this week, and P. has headed into grade five. It's really hard for me to get my head around the idea that my son is already in grade five. Amazing how fast that all happens. Best part is that he's finally at a school that is within walking distance which means he is now able to get himself to and from school. This is not just a nice thing for my schedule (two years ago I spent 2+ hours a day in the car shuttling him between home and school; last year it was "just" 40 minutes), but an especially nice thing for his budding sense and practice of independence.

Meanwhile, I'm going through a number of life changes myself which has left me various amounts of organization work, paper work, legal details and what not to take care of. Things are busy, and I think both P. and I are learning lots in the process.

Read More