Feed aggregator

Aaron, Sandro, moofang, Shantanu and Diego have been hacking up a Plasma storm lately on the Javascript bindings for Plasma and the Plasmate builder tool. Since good code is running code, and running code is a lot easier when somebody else builds it and packages it, I've updated the Plasmate packages in KDE:KDE4:Playground to 0.1alpha2 and have updated the javascript bindings in our KDE SC 4.4.1 packages to include Aaron's latest errata - no need to update yourselves.

So it's even easier to take part in the Plasma Javascript Jam Session competition now.

And while you're at it, how about completing the loop by using our kde-obs-generator to package your plasmoids and make them available on kde-look.org, so others can start to download and improve them directly in Plasmate? Free Software virtuous circle FTW!

Today on the even later gamaral show: Me and Gabriel Saldana from KDE Mexico kick butt and take names. (all in under 15 21 minutes)

Please send in your comments and ideas to: g@maral.me.

Animus Me – 2010-03-10 (MP3)
Animus Me – 2010-03-10 (OGG)

Subscribe! (MP3)
Subscribe! (OGG)

Just a touch of compliance today. If I wanted to do real compliance engineering, I would turn to gpl-violations.org (in Europe, and please note they are still looking for a new webmaster) or to Brad Kuhn/SFLC (in North America) to do the actual engineering and checking of product. But here’s a mostly happy story.

I spotted the LG NAS N2R1 at a local webshop. Two drives, DVD burner, UPnP, bla bla. Not something I need, but it struck me that that’s exactly the kind of device that does poorly in compliance — ships with Linux and busybox, no sources. So with my usual assumption of malice in place, I went looking. While the firmware downloads for the device (say from LG’s Dutch site) do not mention corresponding source code, the file is clearly and unashamedly a Linux image: a .zip containing a .bin which is actually a .tar containing a .tgz which is the result of tar czf - / on a Debian installation. Somehow I expected a firmware update to be a little more sophisticated than that, you know?

No README or other indications of the licenses in the firmware, but when I downloaded the users manual for the device, imagine my surprise to find pages 159-164 filled with license information: which parts of the firmware are covered by GPLv2, GPLv3, LGPL, other liceses, and a compilation of copyright notices and BSD variants. There’s a written offer for a CD with sources in the users manual. Pretty good, all in all — although of course one might consider checking that the sources are the complete corresponding sources for each firmware version.

But this brings me to a mystery point in the GPLv2. You may distribute versions of the Program in object code (section 3) under the terms of section 1 and 2 provided you offer the source code in some way. So — since this firmware is clearly distribution in object form — we need to check if the conditions are satisfied. The source code offer is ok. But what does “under the terms of Sections 1 and 2 above” mean? Section 1 is about verbatim copies of source code; section 2 is about modified versions (which might be understood to include object form). I guess the question comes down to this: does the condition in section 1, “give any other recipients of the Program a copy of this License along with the Program” apply to distribution in object form, or not?

I just tagged and uploaded a tarball for Plasmate 0.1-alpha2. Plasmate is our Plasma add-on creation tool and we're aiming for a summer release. Improvements since the alpha 1 release last month include not only a large number of bug fixes (thanks to everyone who tried it out and reported issues they came across!) but also some great new features, of which probably the most cool one is the online integration which allows you to grab a Plasmoid via GetHotNewStuff and instantly start working on it as well as upload your own creations using your opendestop.org account.

Download it and give it a whirl!

We are no just two weeks away from when submissions to the Javascript Jam Session can start to be made via email to javascriptjam at kde dot org. Exciting times! I've already seen some of the early entries and I think it's going to shape up really nicely.

To mark the "two weeks and counting" point, I've uploaded yet another Plasma Javascript ScriptEngine errata tarball. It should be usable with KDE 4.3 and 4.4. Enjoy!

Work continues to go into improving the Javascript Plasmoid API, with more and more of that work set to appear in KDE SC 4.5 as v2 of the API.

Today I committed a change provides the ability to connect a DataEngine to any Javascript function:

unction myUpdateFunction(source, data) { print("in myUpdate") }

function myClass()
{
this.count = 1·
}

myClass.prototype.dataUpdated = function(source, data)
{
print(this.count++)
}

var myObj = new myClass
myObj.oddUpdate = function(source, data)
{
print("huzzah! no access to the 'this' object, though.")
}

var label = new Label;

var svg = new Svg("tiger")
svg.dataUpdated = function(source, data)
{
// a cute made-up example
if (source = 'image') {
this.imagePath = data['path']
}
}

dataEngine("svgs").connectSource("image", svg)
dataEngine("time").connectSource("UTC", plasmoid)
dataEngine("time").connectSource("UTC", label)
dataEngine("time").connectSource("UTC", myUpdateFunction)
dataEngine("time").connectSource("UTC", myObj)
dataEngine("time").connectSource("UTC", myObj.oddUpdate)

.. and it all just works as expected. As someone who generally works with C++ this is all a bit magical. ;)

I've also added an interesting, at least to me, GSoC project idea to the KDE projects idea page: Javascript Test Suite. It's not particularly sexy, but it would be a great contribution to the future quality of something that is likely going to be increasingly important to us. I don't know if it would get a spot for sure if someone takes it on, but I'd root for it. :) There are some other interesting Plasma related ideas on that page, including a couple of cross-project ones, such as between Skrooge and Plasma.

KRunner needs a dictionary plugin. Work flow:

1. alt + f2
2. type “define “
3. ctrl + v
4. awe at simplicity

While we’re at it, a translation plugin would be nice too.

I will make the dictionary runner. Standby.

KDE will be moving to git, Qt has moved to git, recently also CMake moved to git.

So, it's time to start using git.

...until now it really looks so complicated, compared to cvs/svn.
In cvs/svn it was easy: local working copy, remote central repository, just one step away.
With git this is about three steps away: local working copy, stash, local repository, remote repository. You always have to be aware of where things are.

Ok, one has to get used to that "git add" is something different from "svn add", and "git commit" is different from "svn commit".
After a "git merge --rebase" (which seems to be the same as "svn up"), git told me that some files "need updates".
So I just tried "git update".
This would have been too easy:
git: 'update' is not a git command. See 'git --help'.

Did you mean this?
update-ref
$

Ah, right, I think "git checkout" is the same as "svn update".

At least "git diff" seemed to do the same as "svn diff" (or cvs diff).
Then I committed. To my local repository this means.
Now, I wanted to have a patch which I can send away.
So, with svn/cvs I did "svn diff", so I tried "git diff".
Nothing.
Of course, because there is no difference anymore between my working copy and my local repository.
But how do I get the difference between my local repository and the repository from which I cloned ?

I mean, I'd like to know that before I push.

So, some browsing and googling follows:
http://marklodato.github.com/visual-git-guide/
http://www.kernel.org/pub/software/scm/git/docs/everyday.html
http://book.git-scm.com/3_comparing_commits_-_git_diff.html

I read things like "committing with a detached HEAD" or "Create a local reference to the remote repository as" and other things which sound quite complicated.
I try "git log '^origin/master' master" and then "git format-patch --stdout 62b095d". This looks quite good, but is only one commit, not two. So I try "git format-patch --stdout 62b095d 57c5d370". This gives me plenty weird stuff. Next try.

And finally I find a web page which seems to contain what I'm looking for, how do I compare my stuff to the central repository:
http://pjps.tumblr.com/post/96756489/git-diff-with-a-remote-repository

Phhh, is it really that complicated, doing like one of the most basic things ?

So, how do I do this ?

Alex

The Register is reporting that some company in Mountain View includes cycling directions in some areas of the world. Old hat, I’d say, as the Dutch national cyclists union has had a really good bike trip mapper for quite some time already which makes use of the cycling infrastructure we have here. Too bad the editor to add data to the system seems to be a Flash app.

Speaking of apps, there’s an app for cycle route planning, which prompted the MOMC to say “I want an iPhone!”. To which my knee-jerk Free Software response was “No, you don’t. Really, you don’t.” But how do I make it a little less knee-jerk and a little more reasoned? Or how do we get pseudo-community organizations like the cyclists union to produce apps in a more open fashion so that they’re easier to port to all the platforms we use? I’d like that cycle mapping app on my n810, for instance.

Kind of strange, I’ve picked up two Russian-language comments that do not immediately seem to be spam on my previous post. I find my Russian reading skill hasn’t deteriorated completely, but I’m left wondering what разместить means. Which reminds me of the advances made in machine translation, so of course I can look it up. At the current state of technology, wouldn’t “multi-lingual chat” be a viable service? Set up an IRC server and run everything through a translate API so that each person connected reads and writes in their own tongue.

Do you know this one?

Phoronix tested md5sums of ISO images of distributions. The winner was openSUSE, scoring e29311f6f1bf1af907f9ef9f44b8328b, which gave it a noticeable lead before second Slackware (b026324c6904b2a9cb4b88d6d61c81d1), which is quite closely followed by Fedora (9ffbf43126e33be52cd2bf7e01d627f9) and Debian (9ae0ea9e3c9c6e1b9b6252c8395efdc1). The difference between these two distributions, as you can see, is only very small. Ubuntu completely flopped in this test, achieving only 1dcca23355272056f04fe8bf20edfce0, which is surprising, especially considering that its previous release scored a very nice c30f7472766d25af1dc80b3ffc9a58c7. (source).

Ok, that's just a joke, but the sad part is, as somebody pointed out, that it wouldn't be really that surprising if Phoronix actually did something like that. And, probably even more sad, there would be people who'd really take it as if it meant something and started adding comments about how last openSUSE is pretty good, last Ubuntu is so disappointing, and Fedora and Debian are not really that different.

So take this from somebody who has already done a lot of performance work: Benchmarks, on their own, mean almost nothing if you don't understand them. Especially if they are seriously flawed (I mean, testing filesystem performance by doing CPU-intensive tasks? Hallo? Probably even FAT16 could provide the same results in those tests on an SSD.), but even if the results are useful numbers, it is still necessary to understand what the numbers actually say. I think I wouldn't even have a big problem forging a "benchmark" where KDE would get better (and correct) numbers than LXDE by finding a scenario that'd be twisted enough.

And even then, it is still necessary to keep in mind what is compared. Comparing the default setup of Fedora and openSUSE means also comparing GNOME and KDE, which you may or may not want, but if you compare the distributions this way, it is affected by differences between the desktops, and if you compare the desktops, it is affected by the differences between the distributions. And in either case, it may or may not apply to another distribution or another desktop.

Yet one more thing to understand is what is measured and how it affects performance as a whole. Ages ago there was a Dot article that also mentioned performance improvements to be brought by Qt4 in some specific areas, yet even now there are numbers of people seriously disappointed by KDE4's performance only because they thought that since Qt4 improves in some areas, KDE4 will get exactly the same improvement, regardless of how much these improvements matter for the whole of KDE4 or how much of KDE4 was rewritten when porting from KDE3. When I fixed Exmap to work again and did a little benchmark as a part of it, there wasn't really much more to it than to show that Exmap works again and that it is very easy to lose a lot of advantage by a simple mistake, yet people had no problems drawing all kinds of strange conclusions from that. Since making right conclusions is unexpectedly difficult for most people when it gets to benchmarks, I really need to remember not to just post numbers again without also saying what it means.

And, finally, there is still the question of other costs and whether it is worth it. Various KDE components often have resource demands, but then they are also often worth it. I mean, we all could still use TWM, or, heck, Windows 95, but seriously, how many of us really would? This, ultimately, is always about what works the best for you.

Have you ever faced the need to rename a file and do a search and replace to adjust all places where it is referenced? For example if you are a C++ developer you may want to rename foo.h and foo.cpp to bar.h and bar.cpp, but you must also replace all lines which says #include "foo.h" with #include "bar.h" in other source files… and don’t forget updating the build system files as well!

This is not really difficult, but it’s tedious and error-prone.

Enter msrp, Meta Search and Replace Program, a handy command-line utility designed to do search and replaces in both file contents and file names. In my example, renaming foo.h and foo.cpp to bar.h and bar.cpp can be done with this single command:

msrp foo\. bar. src/dir/

Note that I escaped the ‘.’ in “foo.”, because msrp supports Perl 5 regular expressions.

What makes msrp even more useful is that it is VCS aware: If I replace the previous command with:

msrp --svn foo\. bar. src/dir/

Then msrp will rename my files using “svn move” instead of doing a plain rename!

Unfortunately, it is unmaintained right now: his developer does not have time anymore to work on it. You can however install it via apt-get on Debian and Ubuntu, or download the source tarball on the page of the Debian package (the developer was also a Debian packager (Hint: if you are a Debian packager, there is an orphaned package waiting for you!))

Msrp comes with support for Mercurial and Subversion by default, but I wrote patches to add support for Git and Bazaar. Note that these patches are not in the 0.9.4 version which is shipped by Debian and Ubuntu.

Give it a try!

I've now added basic X11 memory information to System Activity's Detailed Memory Information. It's a bit crude at the moment and simply states the total pixmap memory usage.

As I've blogged about before, System Activity now has an option to show the detailed memory usage of a process. However the numbers shown there don't match up at all with the numbers shown in the process list. This can be very confusing.

The reason is because the process list shows an approximation, so tends to underestimate the Private memory usage, and overestimate the Shared memory usage. It also doesn't help that it had a different name in the tooltip (URSS etc).

So I've added WhatsThis and tooltips to everything to try to explain the situation, and tried to use consistent naming. Hopefully this help. I've also updated the userbase FAQ.

Please let me know if you have any questions that are not answered on this FAQ. Feel free to use the discussion page there.

I finally came to a design that I'm mostly happy with for how the scripting is done in System Activity. I ended up simplifying the design, removing the QUILoader and the QScriptEngine and just using the QWebView only for the scripting.

The scripting system now looks for an index.html, which would be an html file like:


<html>
<head>
<link href="style.css" rel="stylesheet" type="text/css">
<script language="javascript" src="main.js" language="javascript" type="text/javascript">
</head>
<body>
<div id="innertoc" class="innertoc"></div>
<h1 id="heading"></h1>
<h2 id="SummaryHeading"></h2>
<div id="processsummary">
<!-- The process X is using approximately Y amount of memory etc !-->
</div>

...

Then javascript inserts the html. This way we can translate the strings, and refresh the data without reloading the screen.

So we can now refresh the data continually. This works, but unfortunately it uses up a lot of CPU :-/ It's disabled for now, but I might add a button to refresh or something.

I've talked about features that made it into KDE SC 4.4, and completed features that are now in svn for KDE SC 4.5. So now here's a more long term feature that I've been working on.

Scripting support for System Activity. We can now write javascript script to fetch and display information about processes.

For example:





The idea is that memory usage is rarely understood. So I wanted a tool that would try to present the information as simply as possible. There's still a lot of work to do with this, and I still haven't sorted out how I want it to work fully. I was thinking of giving it tabs, with each tab presenting different information about the process. For example a tab with graphs of cpu/memory usage over time, and a tab showing the files that the process has open.


At the moment scripts are created by just creating a main.js file and that script outputs html. The trouble with this approach is that it's very difficult for translators to, well, translate the output. So instead I was thinking of doing it like ruby on rails etc, and having a .html file that would look like:

<h1>Process <%= process.pid %> - <%= process.name %></h1>

etc. Hopefully this would be fairly easy to implement, and translators would create a copy of the html file and adjust it how they want.
Does this approach sound like it might work?

So, it's been a pretty crappy year so far hardware wise. My Vaio's headphone jack and 'a' key are broken, so it's been in for repair (and Sony, you're taking an awfully long time to repair relatively minor damage. It's been in since the 22nd of Febuary now...), and as of this weekend we just had, one of the hard drives in my desktop RAID died. All this is kind of inconveniencing my development efforts, which is annoying, but I'll survive.

I'm going to be buying another two to replace both of them, of course, as I don't want to put all my trust in the remaining drive not falling over.

On the subject of hardware, anyone got any recommendations laptopwise? I'm probably going to be replacing this Vaio soon, as it's just over a year old now and keeping it much longer will lead to depreciation - not a good thing.

I'm after a fair bit of power, seeing as I like compiling things like Qt every once in a while (not to mention KDE), and I'm also a fan of reasonable graphics (NVidia please, I had ATI *hell* last weekend, but that's a whole other story) as I game once or twice a month.

1) Create a folder somewhere eg ~/Desktop/My Favourite Apps
2) Drag and drop the folder onto a panel
3) Choose "Folder View" from the popup that appears
4) Drag apps from the menu, documents from Dolphin and other stuff onto the new panel icon
5) Click it and enjoy your new menu!

Hi all!

Been a while since I blogged, and I'll continue on that topic in a few days. I promise.

Meanwhile I've got an excuse for being rather quiet. I've moved to Utrecht, where I now live with two long-time friends in a rather nice place. A big step forward in many ways, from the good company to the much more comfortable house.

I'll give you two pics of both ppl dumb enough to sign for living with me. Ask the bloody german how much fun that is - he experienced me for a full week at Camp KDE. Aaah well. Everyone's crazy, and it's more fun that way.



We discovered several interesting things about each other. For one, we cook differently. So I have an interesting culinary experience every day. And J has a tick which makes him clean up the living room. No problem, that's for sure. Doesn't extend to the other rooms, however, so we'll still have to come up with a deal about those.

Oh, and slightly higher on the weirdness scale: we differ in how we handle toilet paper. J wants it on the floor (but moves it around randomly), N on the cistern and I like it - well, where it belongs... J also has a tendency to get a new roll as soon as he's about 90% finished with the previous one. As I said, weird is fun.

Then there's beer. N likes Leffe but can't afford it. I like Jupiler and can pay for it. J insists on Euroshopper. The cheapest pilzner from the largest dutch supermarket chain. Weird is good, riiiight.

Anyways. Enough rambling. I'll treat you on a pic of myself and finish this.

Back in the days, we did not have capabilities to find and install debug packages with Dr. Konqi in KDE. But those times are over!

Debug packages are important, well, actually very important. When an application crashes it is in most cases possible to create a so called backtrace. A backtrace ideally provides the developer with the precise location in the source code where the crash happened. Fixing a crash without this kind of information is almost impossible, and the more information are available in the backtrace the better. Debug packages contribute to this in that their content are debug symbols, essentially those are the references that are used in the backtrace. Now, usually you do not need to have this information to use the software, which is the reason a lot of distributions strip the symbols into these seperated debug packages (one can save a big deal of disk space by removing them).

In case you did not yet hear of Dr. Konqi. It is a very useful tool that usually pops up when a KDE application crashes. It then tries to get all information necessary for you to create a perfectly useful bug report.

There is big of a problem, on the one hand you do not want to waste disk space and network traffic for these debug symbols, even though like 99% of the regular users will not need them, and on the other hand you have Dr. Konqi which is trying to obtain a high quality backtrace that enables developers to quickly process a bug report and fix a crash in their software.

Not KDE 4.4not GNOME 3.0 and not KDE SC 4.4but Dr. Konqi 2.1 comes to rescue and now allows distribution developers to create scripts that take care of the find an installing of debug packages, so that the debugging experience becomes a bit better. Well, obviously debugging is not much of a user experience eitherway but at least getting a backtrace is now more barable than it was before.

The system is quite simple. Dr. Konqi calls an executable, passing it all files for which no debug symbols were found for as arguments, then the executable tries to find and install the appropriate packages and returns back to Dr. Konqi. Straight forward really

Since I am, amongst other things, Kubuntu developer and since this blog post is tagged ‘kubuntu’ of course I am only blogging about this because Kubuntu today got support for this fancy new feature . Should you encounter a crash in upcoming Kubuntu 10.04 Dr. Konqi will not only tell you how good the quality of the automatic generated backtrace is, but also show a button with which you can install missing debug symbols.

Additionally I might mention that Kubuntu has a new mantra of using C++ whenever possible (in opposite to the former one, which was to use Python whenever possible), hence the application standing behind this new features is written in C++ and got the fancy name kubuntu-debug-installer.

In case you care, the code is available on launchpad, and fairly simple. It really just creates a thread and uses dpkg -S to find the appropriate packages. In later versions it will also be able to use other means of looking up debug packages and be able to add a super secret Kubuntu repository for debug packages automatically, if necessary.

What I would like to see for future KDE releases is the possibility to directly tie a plugin into Dr. Konqi instead of having to create an independet application. But for now we’ll try to get kubuntu-debug-installer the ability to use different algorithms for finding the appropriate debug packages (also using different tools, since for example apt-file performs better than dpkg-query, but requires an up-to-date cache etc.) and of course support of a special Kubuntu repository that contains debug packages for all and every official Kubuntu package.

March 31st brings us Free Software cyclists a dilemma: Document Freedom Day, supporting Open Standards in document storage (the Dutch organization will be in Baarn) or the nationwide record-breaking attempt for simultaneous cycling (in Dutch). Of course, I could ride my bicycle to DFD, that would do the trick (it’s about 70km from here). Dilemma, dilemma.