The project has been tracked on this page of hackweek’s wiki, this is a detailed report of what I achieved.

Installing docker on openSUSE 12.3

Docker has been packaged inside of this OBS project.

So installing it requires just two commands:

1
2

sudo zypper ar http://download.opensuse.org/repositories/home:/flavio_castelli:/docker/openSUSE_12.3 docker
sudo zypper in docker

There’s also a 1 Click Install for the lazy ones :)

Zypper will install docker and its dependencies which are:

• lxc: docker’s “magic” is built on top of LXC.
• bridge-utils: is used to setup the bridge interface used by docker’s containers.
• dnsmasq: is used to start the dhcp server used by the containers.
• iptables: is used to get containers’ networking work.
• bsdtar: is used by docker to compress/extract the containers.
• aufs3 kernel module: is used by docker to track the changes made to the containers.

The aufs3 kernel module is not part of the official kernel and is not available on the official repositories. Hence adding docker will trigger the installation of a new kernel package on your machine.

Both the kernel and the aufs3 packages are going to be installed from the home:flavio_castelli:docker repository but they are in fact links to the packages created by Michal Hrusecky inside of his aufs project on OBS.

Note well: docker works only on 64bit hosts. That’s why there are no 32bit packages.

Docker appliance

If you don’t want to install docker on your system or you are just curious and want to jump straight into action there’s a SUSE Studio appliance ready for you. You can find it here.

If you are not familiar with SUSE Gallery let me tell you two things about it:

• you can download the appliance on your computer and play with it or…
• you can clone the appliance on SUSE Studio and customize it even further or…
• you can test the appliance from your browser using SUSE Studio’s Testdrive feature (no SUSE Studio account required!).

The latter option is really cool, because it will allow you to play with docker immediately. There’s just one thing to keep in mind about Testdrive: outgoing connections are disabled, so you won’t be able to install new stuff (or download new docker images). Fortunately this appliance comes with the busybox container bundled, so you will be able to play a bit with docker.

Running docker

The docker daemon must be running in order to use your containers. The openSUSE package comes with a init script which can be used to manage it.

The script is /etc/init.d/docker, but there’s also the usual symbolic link called /usr/sbin/rcdocker.

To start the docker daemon just type:

1

sudo /usr/sbin/rcdocker start

This will trigger the following actions:

1. The docker0 bridge interface is created. This interface is bridged with eth0.
2. A dnsmasq instance listening on the docker0 interface is started.
3. IP forwarding and IP masquerading are enabled.
4. Docker daemon is started.

All the containers will get an IP on the 10.0.3.0/24 network.

Playing with docker

Now is time to play with docker.

First of all you need to download an image: docker pull base

This will fetch the official Ubuntu-based image created by the dotCloud guys.

You will be able to run the Ubuntu container on your openSUSE host without any problem, that’s LXC’s “magic” ;)

If you want to use only “green” products just pull the openSUSE 12.3 container I created for you:

1

docker pull flavio/openSUSE_12.3

Please experiment a lot with this image and give me your feedback. The dotCloud guys proposed me to promote it to top-level base image, but I want to be sure everything works fine before doing that.

Now you can go through the examples reported on the official docker’s documentation.

Create your own openSUSE images with SUSE Studio

I think it would be extremely cool to create docker’s images using SUSE Studio. As you might know I’m part of the SUSE Studio team, so I looked a bit into how to add support to this new format.

– personal opinion –

There are some technical challenges to solve, but I don’t think it would be hard to address them.

– personal opinion –

If you are interested in adding the docker format to SUSE Studio please create a new feature request on openFATE and vote it!

In the meantime there’s another way to create your custom docker images, just keep reading.

Create your own openSUSE images with KIWI

KIWI is the amazing tool at the heart of SUSE Studio and can be used to create LXC containers.

As said earlier docker runs LXC containers, so we are going to follow these instructions.

First of all install KIWI from the Virtualization:Appliances project on OBS:

1
2

sudo zypper ar virtualization:appliances http://download.opensuse.org/repositories/Virtualization:/Appliances/openSUSE_12.3
sudo zypper in kiwi kiwi-doc

We are going to use the configuration files of a simple LXC container shipped the kiwi-doc package:

1

cp /usr/share/doc/packages/kiwi/examples/suse-12.3/suse-lxc-guest ~/openSUSE_12_3_docker

The openSUSE_12_3_docker directory contains two configuration files used by KIWI (config.sh and config.xml) plus the root directory.

The contents of this directory are going to be added to the resulting container. It’s really important to create the /etc/resolv.conf file inside of the final image since docker is going to mount the resol.conf file of the host system inside of the running guest. If the file is not found docker won’t be able to start our container.

An empty file is enough:

1

touch ~/openSUSE_12_3_docker/root/etc/resolv.conf

Now we can create the rootfs of the container using KIWI:

1

sudo kiwi --prepare ~/openSUSE_12_3_docker --root /tmp/openSUSE_12_3_docker_rootfs

We can skip the next step reported on KIWI’s documentation, that’s not needed with docker because it will produce an invalid container. Just execute the following command:

1

sudo tar cvjpf openSUSE_12_3_docker.tar.bz2 -C /tmp/openSUSE_12_3_docker_rootfs/ .

This will produce a tarball containing the rootfs of your container.

Now you can import it inside of docker, there are two ways to achieve that:

• from a web server.
• from a local file.

Importing the image from a web server is really convenient if you ran KIWI on a different machine.

Just move the tarball to a directory which is exposed by the web server. If you don’t have one installed just move to the directory containing the tarball and type the following command:

1

python -m SimpleHTTPServer 8080

This will start a simple http server listening on port 8080 of your machine.

On the machine running docker just type:

1

docker import http://mywebserver/openSUSE_12_3_docker.tar.bz2 my_openSUSE_image latest

If the tarball is already on the machine running docker you just need to type:

1

cat ~/openSUSE_12_3_docker.tar.bz2 | docker import - my_openSUSE_image latest

Docker will download (just in the 1st case) and import the tarball. The resulting image will be named ‘my_openSUSE_image’ and it will have a tag named ‘latest’.

The name of the tag is really important since docker tries to run the image with the ‘latest’ tag unless you explicitly specify a different value.

Conclusion

Hackweek #9 has been both productive and fun for me. I hope you will have fun too using docker on openSUSE.

As usual, feedback is welcome.

The previous 0.8.0 release broke ABI compatibility without changing the SOVERSION.

Toward QJson 1.0.0

I’m not entirely happy with some parts of QJson’s API. I addressed these issues inside of the 1_0_0 branch.

I would appreciate to hear your opinion before merging this branch into master and releasing QJson 1.0.0.

So here we go, QJson 0.8.0 is out!

What changed

A lot of bugs has been smashed during this time, this new release will fix issues like this one and this in a nicer way.

QJson’s API is still backward compatible, while the ABI changed.

Symbian support

Some work has also been done to get QJson work on the Symbian platform. The development happened a long time before Symbian was declared dead.

Currently I do not offer any kind of support for the Symbian platform because IMHO Symbian development is a mess and given the current situation in the mobile world I don’t see any point in investing more efforts on that.

Obviously Symbian patches and documentation are still accepted, as long as they don’t cause issues to the other target platforms.

QMake support

QJson always used cmake as build system but since some Windows developers had problems with it I decided to add some .pro files. That proved to be a bad choice for me since I had to support two build systems. I prefer to invest my time fixing bugs in the code and adding interesting features rather then triaging qmake issues on Windows. Hence I decided to remove them from git.

If you are a nostalgic you can still grab these files from git. They have been removed with commit 66d10c44dd3b21.

Relocating to Github

I decided to move QJson’s code from Gitorious to Github. Github’s issue sysyem is going to replace Sourceforge’s bug tracking system.

I currently use Github a lot, both for personal projects and for work, and I simply love it. I think it offers the best tools in the market and that’s really important to me.

QJson’s website and mailing lists are still going to be hosted on Sourceforge.

I think that’s all from now. If you want more details about the changes introduced take a look at the changelog or checkout QJson’s website.

Suppose you want to create a tailored SUSE Studio appliance to run a Ruby on Rails app, this is a list of things you have to take care of:

• install all the gems required by the app (this can be a long list).
• install and configure the database used by the app.
• install and configure a webserver.
• ensure all the required services are started at boot time. You can save some time by cloning this appliance shared on SUSE Gallery, but this is still going to be boring.

Dister to the rescue!

Dister is a command line tool similar to the one used by Heroku (one of the coolest ways to run your Rails app into the cloud). Within a few steps you will be able to create a SUSE Studio appliance running your rails application, download it and deploy wherever you want.

Dister is named after SUSE Studio robot. It has been created by  Dominik Mayer and me during the latest hackweek.

How it works

We are going to create a SUSE Studio appliance running a rails application called “SUSE history”. The app uses bundler to handle its dependencies. This is its Gemfile file:

source 'http://rubygems.org'
gem 'rails', '3.0.5'
gem 'pg'
gem "flutie", "~> 1.1"

As you can see the app uses rails3, the flutie gem and PostgreSQL as database.

Appliance creation

Move into the suse_history directory and execute the following command:

dister create suse_history

As you can see dister has already done a couple of things for you:

• created an appliance using latest version of openSUSE supported by SUSE Studio (you can use a different base system of course)
• added the devel:language:ruby:extensions repository to the appliance: this repo contains tons of ruby packages (like mod_passenger)
• installed a couple of things:
  • devel_C_C++ pattern: this will allow you to build native gems.
  • devel_ruby pattern: provides ruby, rubygems and a couple of development packages needed to build native gems.
  • rubygem-bundler: bundler is required by dister in order to handle the dependencies of your rails application.
  • rubygem-passenger-apache2: dister uses passenger and apache2 to deploy your rails application.
  • postgresql-server: dister noticed suse_history uses PostgreSQL as database, hence it automatically installs it.
  • rubygem-pg: dister noticed suse_history uses PostgreSQL as database, hence it automatically installs the ruby’s library forPostgreSQL.
• uploaded a custom build script which ensures:
  • mod_passenger module is loaded by Apache
  • both Apache and PostgreSQL are always started at boot time.
  • all dependencies are installed: this is done only during the first boot using bundler.
  • the database user required by your rails app is created. This is done only during the first boot using some SQL code.
  • the database used by the appliance is properly initialized (aka rails db:create db:migrate). This is done only during the first boot.

Upload your code

It’s time to upload suse_history code. This is done using the following command:

dister push

As you can see dister packaged the application source code and all its dependencies into a single archive. Then uploaded the archive to SUSE Studio as an overlay file. Dister uploaded also the configuration files required by Apache and by PostgreSQL setup.

Build your appliance

It’s build time!

dister build

The appliance has automatically being built using the raw disk. You can use different formats of course.

Testdrive

Testdrive is one of the coolest features of SUSE Studio. Unfortunately dister doesn’t support it yet. Just visit your appliance page and start testdrive from your browser. Just enable testdrive networking and connect to your appliance:

Download

Your appliance is working flawlessly. Download it and deploy it wherever you want.

dister download

Current status

As you can see dister handles pretty fine a simple Rails application, but there’s still room for improvements.

Here’s a small list of the things on my TODO list:

• The dependency management should install gems using rpm packages. This would make the installation of native gems easier, right now the user has to manually add all the development libraries required by the gem. Moreover it would reduce the size of the overlay files uploaded to SUSE Studio.
• SUSE Studio Testdrive should be supported.
• It should be possible to deploy the SUSE Studio directly to EC2.
• Fix bugs!

Bugs and enhancements are going to be tracked here.

Contribute

Dister code can be found here on github, fork it and start contributing.

If you are a student you can work on dister during the next Google Summer of code, apply now!

Thanks to Jump, you won’t have to type those long paths anymore.

You can find jump’s source code, detailed documentation and installation instructions here.

SUSE packages can be found here.

Code can be downloaded from here. openSUSE packages are already available on the build service.

These are some screenshots illustrating fastuserswitch’s new features.

Let me introduce my first plasmoid: the fast user switch plasmoid. It’s a simple icon in the panel that allows users to swich to another open session or to open a new login page. Here you can see the mandatory screenshots.

You can find the source code here. Binary packages for openSUSE are already available on the build service.

One last thought about KDM

I think that KDM should allow to switch back to an already open session in a more transparent way. Right now if an user has already one session open, he goes back to the login screen and enters his credentials a new session is started. I think that most users would expect to be switched back to their already running session. Starting a new session is just confusing for them.

In order to run the unit tests of your rails application, basically you have these official possibilities:

• rake test: runs all unit, functional and integration tests.
• rake test:units: runs all the unit tests.
• rake test:functionals: runs all the functional tests.
• rake test:integration: runs all the integration tests. Each one of these commands requires some time and they are not the best solution while developing a new feature or fixing a bug. In this circumstance we just want to have a quick feedback from the unit test of the code we are editing.

Waiting for all the unit/functional tests to complete decreases our productivity, what we need is to execute just a single unit test. Fortunately there are different solutions for this problem, let’s go through them.

The easy approach: use your favorite IDE

Most of the IDE supporting ruby allow you to run a single unit test. If you are using Netbeans running a single unit test is really easy:

• make sure the editor if showing the file you want to test or the file containing its unit tests
• Hit Ctrl+Shift+F6 or click on the following menu entry: Debug->Debug Test File Two new windows will be opened: one will contain the output produced by your unit test, the other one will show the results of the unit test.

As you will notice the summary window contains also some useful information like the:

• hyper links to the exact location of the code that produced the error/failure.
• execution time required by each one of the test methods. As you will experience it will be like “compiling” your ruby code.

From the console

If you are not using Netbeans you can always rely on some command line tools.

No additional tools

These “tricks” don’t require additional gems, hence they will work out of the box.

The first solution is to call this rake task:

rake test TEST=path_to_test_file

So the final command should look like

rake test TEST=test/unit/invitation_test.rb

Unfortunately on my machine this command repeats the same test three times, I hope you won’t have the same weird behavior also on your systems…

Alternatively you can use the following command:

ruby -I"lib:test" path_to_test_file"

It’s even possible to call a specific test method of your testcase:

ruby -I"lib:test" path_to_test_file -n name_of_the_method"

So calling:

ruby -I"lib:test" test/unit/invitation_test.rb - test_should_create_invitation

will execute only InvitationTest::test_should_create_invitation.

It’s also possible to execute only the test methods matching a regular expression. Look at this example:

ruby -I"lib:test" test/unit/invitation_test.rb -n /.*between.*/

This command will execute only the test methods matching the /.between./ regexp.

Using the single_test gem

If you want to avoid the awful syntax showed in the previous paragraph there’s a gem that can help you, it’s called single_test.

The github page contains a nice documentation, but let’s go through the most common use cases.

You can install the gem as a rails plugin:

script/plugin install git://github.com/grosser/single_test.git

single_test will add new rake tasks to your rails project, but won’t override the original ones.

Suppose we want to execute the unit test of user.rb, just type the following command:

rake test:user

If you want to execute the functional test of User just call:

rake test:user_c

Appending ”c”_ to the class name will automatically execute its functional test (if it exists).

It’s still possible to execute a specif test method:

rake test:user_c:_test_name_

So calling:

rake test:user_c:test_update_user

Will execute the test_update_user method written inside of test/functional/user_controller_test.rb.

It’s still possible to use regexp:

rake test:invitation:.*between.*

This syntax is equivalent to ruby -I"lib:test" test/unit/invitation_test.rb -n /.*between.*/.

Possible issues

When a single unit test is run all the usual database initialization tasks are not performed. If your code is relying on newly created migrations you will surely have lots of errors. This is happening because the new migrations have not been applied to the test database.

In order to fix these errors just execute:

rake db:test:prepare

before running your unit test.

Since I’m not a Symbian developer it has been a little hard for me to achieve that. I would like to thank Antti Luoma for his help.

There are also good news for Windows developers: now building QJson under Windows is easier. Checkout the new installation instruction page.

I hope this will help all the Windows developers who want to use QJson.

I’ll keep the code on KDE’s svn synchronized with the git repository.

I refactored a bit my latest changes: I created a new class called QObjectHelper that provides the methods required to convert a QObject instance to a QVariantMap and vice-versa.

This class can be used in conjunction with the Serializer and Parser classes to serialize and deserialize QObject instances to and from JSON.

Let me show a quick example, suppose the declaration of Person class looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

class Person : public QObject
{
  Q_OBJECT
  Q_PROPERTY(QString name READ name WRITE setName)
  Q_PROPERTY(int phoneNumber READ phoneNumber WRITE setPhoneNumber)
  Q_PROPERTY(Gender gender READ gender WRITE setGender)
  Q_PROPERTY(QDate dob READ dob WRITE setDob)
  Q_ENUMS(Gender)

  public:
    Person(QObject* parent = 0);
    ~Person();
    QString name() const;
    void setName(const QString& name);
    int phoneNumber() const;
    void setPhoneNumber(const int  phoneNumber);
    enum Gender {Male, Female};
    void setGender(Gender gender);
    Gender gender() const;
    QDate dob() const;
    void setDob(const QDate& dob);
  private:
    QString m_name;
    int m_phoneNumber;
    Gender m_gender;
    QDate m_dob;
};

From QObject to JSON

The following code will serialize an instance of Person to JSON :

1
2
3
4
5
6
7
8

Person person;
person.setName("Flavio");
person.setPhoneNumber(123456);
person.setGender(Person::Male);
person.setDob(QDate(1982, 7, 12));
QVariantMap variant = QObjectHelper::qobject2qvariant(&person;);
Serializer serializer;
qDebug() << serializer.serialize( variant);

The generated output will be:

1

{ "dob" : "1982-07-12", "gender" : 0, "name" : "Flavio", "phoneNumber" : 123456 }

From JSON to QObject

Suppose you have the following JSON data stored into a QString:

1

{ "dob" : "1982-07-12", "gender" : 0, "name" : "Flavio", "phoneNumber" : 123456 }

The following code will initialize an already allocated instance of Person using the JSON values:

1
2
3
4

Parser parser;
QVariant variant = parser.parse(json);
Person person;
QObjectHelper::qvariant2qobject(variant.toMap(), &person;);

A new release

These changes have been included inside the new release of QJson: 0.7.0.

Packages for openSUSE are building right now.

This solution relies on the awesome Qt’s property system.

Suppose the declaration of Person class looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

class Person : public QObject
{
  Q_OBJECT
    Q_PROPERTY(QString name READ name WRITE setName)
    Q_PROPERTY(int phoneNumber READ phoneNumber WRITE setPhoneNumber)
    Q_PROPERTY(Gender gender READ gender WRITE setGender)
    Q_PROPERTY(QDate dob READ dob WRITE setDob)
    Q_ENUMS(Gender)
  public:
    Person(QObject* parent = 0);
    ~Person();
    QString name() const;
    void setName(const QString& name);
    int phoneNumber() const;
    void setPhoneNumber(const int  phoneNumber);
    enum Gender {Male, Female};
    void setGender(Gender gender);
    Gender gender() const;
    QDate dob() const;
    void setDob(const QDate& dob);
  private:
    QString m_name;
    int m_phoneNumber;
    Gender m_gender;
    QDate m_dob;
};

The following code will serialize an instance of Person to JSON:

1
2
3
4
5
6
7

    Person person;
    person.setName("Flavio");
    person.setPhoneNumber(123456);
    person.setGender(Person::Male);
    person.setDob(QDate(1982, 7, 12));
    Serializer serializer;
    qDebug() << serializer.serialize( &person;);

The generated output will be:

1

    { "dob" : "1982-07-12", "gender" : 0, "name" : "Flavio", "phoneNumber" : 123456 }

I hope you will find this new feature useful. I’m also considering to create a similar method inside the Parser class.

As usual suggestions are welcome.

In the meantime I kept working on kaveau, so let me show you what has changed:

• rdiff-backup has been replaced by rsync.
• the setup wizard has been improved according to the feedback messages I received.
• old backups are now automatically removed.
• the code has been refactored a lot.

The switch to rsync

Previously kaveau used rdiff-backup as backup back-end. rdiff-backup is a great program but unfortunately it relies on the outdated librsync library. The latest release of librsync is dated 2004. It has a couple of serious bugs still open and, while rsync has reached version three, this library is still stuck at version one.

These are the reasons of the switch from rdiff-backup to rsync. This choice breaks the compatibility with the previous backups but it introduces a lot of advantages. One of the most important improvements brought by the adoption of rsync is an easier restore procedure: now all the backups can be accessed using a standard file manager, while previously rdiff-backup was needed to access the old backups.

Backup directory structure

On the backup device everything is saved under the kaveau/hostname/username path.

The directory will have a similar structure:

drwxr-xr-x 3 flavio users 4096 2009-09-12 18:50 2009-09-12T18:50:19
drwxr-xr-x 3 flavio users 4096 2009-09-14 23:07 2009-09-14T23:07:46
drwxr-xr-x 3 flavio users 4096 2009-09-14 23:30 2009-09-14T23:30:36
lrwxrwxrwx 1 flavio users   19 2009-09-14 23:30 current -> 2009-09-14T23:30:36

As you can see there’s one directory per backup, plus a symlink called current pointing to the latest backup.

Old backup deletion

Nowadays big external storage devices are pretty cheap, but it’s always good to save some disk space. Now kaveau keeps:

• hourly backups for the past 24 hours.
• daily backups for the past month.
• weekly backups until the external disk is full. Thanks to hard links’ magic, old backups can be deleted without causing damages to the other ones.

Plans for the future

Before starting to work on the restore user interface I will spend some time figuring out how to add support for network devices.

A lot of users requested this feature, hence I want to make them happy :) .

I’m planning to use avahi to discover network shares (nfs, samba) or network machines running ssh and use them as backup devices. Honestly, I want to achieve something similar to Apple’s time capsule.

As usual, feedback messages are really appreciated.

The good news is that QJson can be successfully built under Window, I can show you proof ;)

I have written the build instructions on QJson website: just take a look here.

One last note: if you have problems with QJson please subscribe to the developer mailing list and post a message.

I decided to dedicate myself to an idea that has been obsessing me since a long time. Last December my brand new hard disk suddenly died, making impossible to recover anything. Fortunately I had just synchronized the most important documents between my workstation and my laptop, so I didn’t lose anything important. This incident make me realize that I should perform backups regularly and I immediately started looking for a good solution.

Personally I think that doing backups is pretty boring so I wanted something damned easy to setup and use. Something that once configured runs in the background and does the dirty job without bothering you. Let’s face the truth: I wanted Apple’s Time Machine for KDE.

After some searches I realized that nothing was fitting my requirements and I decided to create something new: kaveau.

What is kaveau?

Kaveau is a backup program that makes backup easy for the average user.

As you will see while coding/planning kaveau I made some assumptions and so only few things are configurable. I really think that sometimes “less is more”.

What does kaveau?

Current features:

• it performs backups to an external storage device: I don’t think it will ever store backup data on a remote host. If you want to do that just use some good project like Backup pc.
• it backs up the complete home directory of the user: storage is cheap and average users (like me) keep everything inside their home directory ( but it’s possible to exclude some directories from the backup).
• it performs incremental backups.
• the backup data are neither compressed nor stored in fancy formats: in this way you can plug your external disk into another machine and access your data without additional work.
• backups are performed automatically every hour (of course only if your external disk is plugged).
• notification messages are shown if your backup is older that a week. More enhancements are coming…

What technologies does it use?

Backups are performed using rdiff-backup because it’s damned easy to use, well tested (it’s used also in production environments) and packaged by all distributions.

The awesome solid library is used for interacting with the external disks is super easy.

Status of kaveau

I have been working on kaveau just for five days, so there’s still a lot of work to do.

A screenshot tour will give you the right idea of its status.

First run - external storage device attached

Backup wizard - page 1

Backup wizard - page 2

Backup wizard - final page

Backup operation in progress

Backup completed

Right now the code is available on this git repository but I don’t recommend you to try it (unless you want to find and fix bugs ;) ).

I would really appreciate:

• feedback about the user interface (right now it looks too much like Time Machine).
• icons: it would be great to have a desktop icon and some system tray icons (contact me for more details).
• new code, bug fixes, code reviews, hints,…

In fact we hacked a lot, doing lots of changes to QJson:

• the API has been cleaned, now it can be considered stable
• unicode support has been completely rewritten
• it’s now possible to convert QVariant objects into JSON ones

So it’s with a great pleasure that I announce the release of QJson 0.6.0.

Beware, since the API has been changed your application will probably break. I’m really sorry about that, but I guarantee it won’t happen in the future (as I said both API and ABI interfaces can now be considered stable).

QJson web site has been updated, reflecting all the changes made to the library. openSUSE packages has been moved from my home repo to KDE:Qt one.

One last note, if you have problems with QJson please contact me using the qjson-devel mailing list. You can subscribe here.

On Thursday 9th July I’ll give a BoF about QJson.

During the talk I will show:

• the advantages brought by QJson.
• the usage of QJson.
• some real programs using QJson.

See you soon!

As usual data is provided by last.fm, which should return also the events “near” the specified city (don’t ask me to define a value for near :) ).

I have created new openSUSE packages, this time everything should work fine. Just make sure to remove all qjson packages before installing this release (in fact all the previous problems were due to packaging errors of qjson, now I have created new packages called libqjson0).

Packages are available for openSUSE 11.0, 11.1 and Factory (both for i586 and x86_64 architectures).

One last news: rockmarble has also a new site, something slightly better than github wiki ;)

After some hacking I created this small application: rockmarble…

If you have a last.fm account rockmarble will import your favourite artist list. Otherwise you can add one artists at a time.

The tour location will be displayed inside Marble, using openstreetmap.

Requirements

In order to build/run it you will need:

• Qt4
• marble
• QJson

Installation

You can grab the source code of rockmarble here.

If you are an openSUSE user you can use 1click install:

Issues

Geolocalization

The geolocalization data are given by last.fm, so if you discover that Metallica are going to give a concert in the middle of the Pacific Ocean please don’t bother me :)

Special names

It seems that QJson doesn’t handle properly special characters. Maybe you will some artist with a blank name. I’m going to fix this issue asap.

More details

Visit rockmarble website

Future

Who wants to integrate it into amarok’s context view? ;)

I came over a couple of solutions but none of them made me happy. So in the last weekend I wrote my own library : QJson The library is based on Qt toolkit and converts JSON data to QVariant instances. JSON arrays will be mapped to QVariantList instances, while JSON’s objects will be mapped to QVariantMap. The JSON parser is generated with Bison, while the scanner has been coded by me.

Usage

Converting JSON’s data to QVariant instance is really simple:

1
2
3
4
5

// create a JSonDriver instance
JSonDriver driver;
bool ok;
// json is a QString containing the data to convert
QVariant result = driver.parse (json, &ok);

Suppose you’re going to convert this JSON data:

1
2

{ "encoding" : "UTF-8", "plug-ins" : [ "python", "c++", "ruby" ],
  "indent" : { "length" : 3, "use_space" : true } }

The following code would convert the JSON data and parse it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

JSonDriver driver;
bool ok;
QVariantMap result = driver.parse (json, &ok).toMap();
if (!ok) {
  qFatal("An error occured during parsing");
  exit (1);
}
qDebug() << "encoding:" << result["encoding"].toString();
qDebug() << "plugins:";
foreach (QVariant plugin, result["plug-ins"].toList()) {
  qDebug() << "\t-" << plugin.toString();
}
QVariantMap nestedMap = result["indent"].toMap();
qDebug() << "length:" << nestedMap["length"].toInt();
qDebug() << "use_space:" << nestedMap["use_space"].toBool();

The output would be:

encoding: "UTF-8" plugins: - "python" - "c++" - "ruby" length: 3 use_space: true

Requirements

QJson requires:

• cmake
• Qt

Obtain the source

Actually QJson code is hosted on KDE subversion repository. You can download it using a svn client:

svn co svn://anonsvn.kde.org/home/kde/trunk/playground/libs/qjson

For more informations visit QJson site