Just a quick note: I have just moved QJson source code to this git repository hosted by gitorious.

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

Mystic Mine ist ein lustiges Independent-Spiel das man ähnlich wie Frozen Bubble mal schnell zwischendurch spielen kann. Und das beste daran, es gibt eine native Linuxversion.

Leider scheiterte mein Versuch diese Linuxversion zu nutzen mit folgender Meldung:

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/cx_Freeze/initscripts/Console.py", line 29, in 
  File "monorail.py", line 34, in 
  File "koon/app.py", line 10, in 
  File "koon/snd.py", line 4, in 
  File "ExtensionLoader_pygame_mixer.py", line 12, in 
ImportError: libSDL_mixer-1.2.so.0: cannot open shared object file: No such file or directory

Das ist mal ein schönes Beispiel für eine zielführende Fehlermeldung. SDL_mixer ist nicht installiert, die Installation der passenden Bibliothek hilft. sudo zypper in SDL_mixer

Some days ago I introduced the possibility to serialize a QObject instance to JSON. Today I’m going to show you the opposite operation: initializing a QObject using a JSON object.

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:

{% codeblock [class definition] [lang:cpp ] %} 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; }; {% endcodeblock %}

From QObject to JSON

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

{% codeblock [From QObject to JSON] [lang:cpp ] %} 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); {% endcodeblock %}

The generated output will be:

{% codeblock [JSON data] [lang:json ] %} { “dob” : “1982-07-12”, “gender” : 0, “name” : “Flavio”, “phoneNumber” : 123456 } {% endcodeblock %}

From JSON to QObject

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

{% codeblock [JSON data] [lang:json ] %} { “dob” : “1982-07-12”, “gender” : 0, “name” : “Flavio”, “phoneNumber” : 123456 } {% endcodeblock %}

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

{% codeblock [From JSON to QObject] [lang:cpp ] %} Parser parser; QVariant variant = parser.parse(json);
Person person; QObjectHelper::qvariant2qobject(variant.toMap(), &person;); {% endcodeblock %}

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 week kolab became one small step closer to realize feature request 307846: include Kolab in openSUSE. Although it will take lots and lots of more work to achieve this goal at all. The one step closer was realized in cooperation with the openSUSE cyrus-imapd maintainer R. The openSUSE cyrus-imapd spec file in the repository server:mail spec file has been extended with information about kolab, but the actual execution of the information has been switched off. With the Build Service link functionality the package server:mail/cyrus-imapd has been linked to the package server:kolab:UNSTABLE/cyrus-imapd-kolab, where the kolab functionality gets built. This is achieved by activating the variable with_kolab in the project related configuration file:
# osc meta prjconf server:Kolab:UNSTABLE
%define with_kolab 1
Macros:
%with_kolab 1

See the Build_Service prjconf page in the openSUSE wiki for more information about this awesome functionality. This way the cyrus-imapd-kolab package inherits everything from the openSUSE base cyrus-imapd package.

One drawback for kolab administrators, you have to manually correct the currently installed kolab packages. Start with downgrading cyrus-imapd-kolab (it only downgrades the Build service version and not cyrus-imapd itself):
# zyp in cyrus-imapd-kolab
This will install the dependent package perl-Cyrus-IMAP-kolab instead of perl-Cyrus-IMAP and perl-Cyrus-SIEVE-managesieve-kolab instead of perl-Cyrus-SIEVE-managesieve and it might remove kolab and perl-kolab.

Now reinstall kolab with:
# zyp in kolab
that should be sufficient to be in sync with the repository again. Don’t forget to restart the services, with:
# rckolab restart

This week also showed the power of the build service, as I could install kolab within only some minutes after installing openSUSE-11.2 in Virtualbox, while I never installed openSUSE-11.2 before.

The kolab installation in openSUS-11.2 made some problems visible in kolabconf -n. The latter has been fixed, it was a general problem in kolabconf and did not have anything to do with openSUSE-11.2.

The kolabconf problem however required some debugging, with a resulted spin off that the spamassassin daemon spamd is no longer activated via the startup scripts, but as a library of amavisd instead. That is the way amavisd and spamd have been configured in kolab, but what was not honored in the kolab setup on openSUSE.

Due to the change in the amavisd and spamd deamons, the script kolabsrv has been extended, and can now show a list with services required by kolab and what their current status is (see screenshot):

The main task of kolabsrv is to convert the openpkg service names to the distribution dependent names.

The kolab project is heading towards a new release 2.2.3 with a planned release date in December 2009.

Sascha released a nice Brain Dump of the Week, giving a nice insight in the possible future of Kolab.

In one of the replies of Sasha’s brain dump, a references was made to project-builder, a project similar to the openSUSE build service. Although the OBS and project-builder may be similar, some people are wondering what the differences (1) and (2) are.

That’s quite a lot of information, but lots of things happened since my last blog entry about Kolab.

PS: many thanks that M. from Novell, who made my Lizards blog account working again. For the most part of this week, I’ve not been able to login to my blog account. After logging in with the correct credentials, I was referred back to the Lizards entry page. M. knows the details, so if this happens to you contact M. from Novell

Mono got a room at FOSDEM2010 in Brussels, so we won't have to do that in the hallway this year !

Want to speak about something fun you did with mono ? Propose a talk. Using mono on your servers saved your company from bankrupt in 200[89] ? Talk about it too. You are a passionate mono hacker and want to spread the word about what we'll got in the upcoming version ? You know the link.

And for everyone else, eager to learn about it, to discuss it, join on Sunday Feb 7. You're all welcome.

Note: be quick, the deadline for the cfp is around Dec 20.

I have notebook which contain private data and I don’t want anyone to read it even if my notebook will be stolen. Encrypted whole home partition is too much as my home directory contains also svn or git repositories which could anybody read. So I create encrypted directory in home directory which contain all private data and rest is normal accessible. So how to do it?
At first install user space crypted filesystem encfs. Then create two directories. First one for encrypted data and second one for accessible data. It is up to you how it is named e.g. encrypted and .encrypted or .Xcache and data (if your government feel that you must give him your data, so encrypted data is not so visible). Then create filesystem for it:

mkdir .encrypted encrypted
encfs /home/jreidinger/.encrypted /home/jreidinger/encrypted

Easy, not? Then encrypted directory contain your data. you can unmount it by fusermount -u encrypted.
After reboot you must attach it again. Maybe it is possible to do it easier, but I need that data only if I work from home, so I mount it manually. It is same as if you create encfs /home/jreidinger/.encrypted /home/jreidinger/encrypted

If you've been paying attention at the back there, you'll know that openSUSE started using a new community-driven online update administration process for 11.2. As well as Novell employees, community people are taking care of the workflow of examining and approving online updates to buggy packages. Now I have a favour to ask of you - the online updates that are ready to go out need testing to make sure they don't inflict gross mischief on users' systems.

KNetworkManager has an online update sitting in this queue awaiting testing. As anyone who has read http://bugzilla.novell.com/show_bug.cgi?id=553908 knows, I forgot to initialise 2 bools added to KNetworkManager just before 11.2 shipped, causing the settings that control whether DNS and routing settings from DHCP to be applied to be set randomly, so the update team wants someone more reliable's opinion on whether my fix for that is any good.

If you want to test it out and take part, add the 11.2 update test repo (or manually browse this URL and install all the NetworkManager-kde4 packages yourself) - http://download.opensuse.org/update/11.2-test . NB that due to a process bug the release number is the same so you will have to --force the install. If it works for you, please comment on bnc#553908 to that effect.

I have just committed into trunk a couple of changes that make easier to serialize a QObject instance to JSON.

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

Suppose the declaration of Person class looks like this:

{% codeblock [class definition] [lang:cpp ] %} 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; }; {% endcodeblock %}

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

{% codeblock [Serialize to JSON] [lang:cpp ] %} Person person; person.setName(“Flavio”); person.setPhoneNumber(123456); person.setGender(Person::Male); person.setDob(QDate(1982, 7, 12));
Serializer serializer; qDebug() << serializer.serialize( &person;); {% endcodeblock %}

The generated output will be: {% codeblock [JSON data] [lang:json ] %} { “dob” : “1982-07-12”, “gender” : 0, “name” : “Flavio”, “phoneNumber” : 123456 } {% endcodeblock %}

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.

Me mudo de blog a Masuto Studios. ¡Los espero allá!

Si quieres ser anónimo, tal vez quieras usar Tor. Ve la siguiente presentación:

Introducción a Tor

View more documents from Mauro Parra-Miranda.