Hello people,

yes, you can shiver at the title: we have (are still, actually) done a new package management frontend. Why? Because KDE missed a great one. Maybe some of you using Arch Linux will recognize the name Shaman: it is the default package manager frontend in Chakra, and my very first project with Qt. As such, it has grown quite old, and it’s showing the limits of my early programming skills, which made it almost unmaintainable by now. So me and Lukas (boom1992) decided to take it on a whirl and rewriting it from the ground up, with a more ambitious goal. We had some clear goals in mind:

• It should have been extensible to any package management system and integrated with it
• It should remain simple, and be extendable to the sky throughout plugins
• It should be completely asynchronous to bring the user the best possible experience
• It should be scriptable, to lower the barrier of the contributors and open up more possibilities to backends not in the C realm

There is one platform which actually makes this all possible, and it’s KDE So we created Shaman 2. What is it?

Chapter 1: Shaman for Developers

Before being a package manager, it is a library. Think about it as the Solid or the Phonon of package management. This library provides an easy to use interface to implement frontends, and an abstraction layer for building plugins and backends. A backend is an interface to a package management system, such as apt, yum, packagekit, alpm, whatever. It is implemented as a static plugin that will be chosen upon build. People who need to implement a backend have to reimplement Shaman::BackendInterface and Shaman::Package, and make it work. It’s really easy to do: the current packagekit backend weights ~900 lines of code (and a lot of them are made of strings) and it’s almost feature complete.

Also, in the spirit of giving the backend developers the maximum flexibility, not forcing them into workarounds and getting the best possible performance/user experience ratio, you can implement delayed loading, custom caching of the information, custom progress reporting (soon), custom searching implementations and more. Shaman comes already preloaded with “Insane rockstar settings” (cit.), a backend for PackageKit and one for Aqpm (pacman), but we are looking forward to people who would like to port Shaman 100% natively on platforms not fully supported by PackageKit. For example, Shaman will support soon streaming transaction questions with custom widgets and creating scripted backends. Did you see any references to apt and/or debconf here? I did not.

At the moment all the code in Shaman runs unprivileged: in the near future, though, it will be given the possibility to create a backend with root privileges just by giving a switch to Shaman at compile time. Thanks to some PolicyKit+DBus magic, the backend (and only the backend) will be run privileged and will require authorization to perform any actions. You still have the option of running Shaman as root, but these days it’s really nonsense. You can also simply bypass such a possiblity and implement this straight into the backend (as Aqpm and PackageKit do), but this boils down to be your choice.

What is extremely cool about Shaman, though, is its plugin system. Almost any functionality can be implemented through plugin, from the GUI or the core side. In fact, the 2 main widgets of the Shaman interface are plugins as well. Plugins have a very important role in Shaman, and can also play an active part in transactions. Every plugin, in fact, can register some “Hook”, that can be run after and/or before a transaction. Pre transaction hooks have also the power of reporting fatal errors and aborting the upcoming transaction before it even starts. As you can imagine, there’s a lot of room for making Shaman fully integrated with the underlying distribution and perform some annoying tasks not belonging to the package management system. For example, what about a plugin that after a transaction checks if the kernel was upgraded, and in case rebuilds the VirtualBox kernel module?

Scripting support, as I told you, is a priority. Even if it’s not working right now due to constant changes in the API, it will be made ready as soon as we reach a semi-stable API, and it will use Kross. The basics are already there and ready, so it’s just a matter of time. Help welcome on this side, especially from some Kross masters around

The API is still unstable but it’s stabilizing as I write this. You know where to reach me, if you’re interested, we can have a chat and you can bug me with some questions I look forward to plugin and backend developers

Chapter 2: Shaman for users

Anyway, what about the user interface? The user interface is meant to be non-modal when and where possible, simple & easy to use yet detailed, still remaining beautiful. How does it look like as of today? (Some screenshot here on Arch, some on Fedora, using Aqpm and PackageKit)

P.S.: The interface is changing by the minute and the default dialog sizes are much smaller than shown. Hey, this is a preview footage after all

You might or might not have noticed some small differences in the PackageKit and Aqpm UI. This is because Shaman adapts its UI depending on the capabilities of the backend. So you will never be shown something your backend does not know about. Well, unless the backend developer is cheating, of course

Shaman implements also some neat stuff: for example, your queue is retained on exit. This means that if you mark some packages to be processed, then your girlfriend calls you and you realize being already 30 minutes late for your date, just don’t worry: close Shaman and turn off your PC: the next time you will start Shaman, it will automagically restore the last queue, which will be ready to be processed. There is also a transaction logger ready for you, so that you won’t lose any bit of history.

There is also security: Shaman is meant to be run as a standard user, using technologies such as PolicyKit and KAuth for granting authorizations for privileged actions.

And it installs, removes and upgrades your packages too!

Near future development

Shaman as the frontend is only the first product in our quest to provide a fully integrated and KDE branded experience for package management. Those of you who used/tried Chakra might have run into, and hopefully loved, Chase, the automatic update system. Chase will be improved and ported over to libshaman (not a lot of work actually), to provide automatic updates in a fully integrated way. And there is also some stuff boiling in our minds to bring to Plasma some of the package management: we are planning on a Plasmoid which will serve as a global visualizator for transactions done through libshaman, and will also provide some very basic package management functions. All the three tools (Automatic updates, plasma widget/engine, Shaman) will be tightly integrated and cooperating, instead of conflicting (just as it happens with Shaman 1 and Chase in Chakra right now), to provide users an easy and integrated way of managing their software.

That’s all, folks

And I sincerely hope I raised some interest I am actually looking forward to distribution developers to get excited and use Shaman in their own distros. Up to now I have a VM for Fedora and Debian where Shaman runs great using the PackageKit backend.

The most important thing, is that Shaman is still not ready to be used. But for the brave souls and curious developers, playground/sysadmin/shaman is the place to be

Hello people, long time no blog.

I have a lot of interesting news for you, I will write a couple of posts in the next days about them. Today I just wanted to give out a small quick update on Power Management, following the drill of Sebastian

So, for the next 2 weeks (and given the freeze time) I happily try to declare and organize the Power Management bug weeks! 2 weeks in which I will dedicate to clear out the list of bugs in Powerdevil and Solid::PowerManagement. Of course I will need your help. It would be nice to have a “central” day, like a small powermanagement bug day in the middle of that. Since I never did such a thing, it would be nice to have some info/help from our bugsquad.

In the meanwhile, if you feel like closing some duplicates, reproducing and providing more information on existing bugs, it would be an extremely valuable help.

More news on completely different stuff coming up soon, stay tuned

Hello people,

Today I want to write a more extensive introduction and how-to, with the KAuth API being finalized, on writing a privileged KCModule. Please note that this information will be soon on Techbase as well.

So, before we start, why should you read this post?

• Because you’re a developer who needs to develop an application requiring high privileges
• Because you’re a developer who needs to develop an application requiring authorization
• Because you’re a curious developer
• Because you’re a curious user

So, defined the target audience, here we go

Back in the KDE3 days, we had an “Administration mode” button, that basically removed the kcm widget, XEmbedded another widget running as root into the kcmshell, and that’s it. Pretty ugly and unsecure, but still working. Most of all, the developer did not know what was happening under the hood, since what happened is in no way different than issuing right now “sudo kcmshell4 <module>”. In KDE4(.4), things are different.

We do not have an “Administrator mode” button, neither widgets being embedded. We do have small helper applications running in the background with high privileges, performing the requested action only if explicitely authorized by the underlying policy system. And we have an easy API, that extends throughout KDEUI and KCModule to make things transparent, customizable, yet extremely easy to the developer.

So let’s start. We are trying to create “fookcm”, a kcmodule for writing to /etc/foo the lines “foo”. So important. As you, experienced developer should know, the first lines will look like this:

K_PLUGIN_FACTORY(FooKCMFactory, registerPlugin<FooKCM>();) K_EXPORT_PLUGIN(FooKCMFactory("fookcm"))
FooKCM::FooKCM(QWidget *parent, const QVariantList &)
: KCModule(FooKCMFactory::componentData(), parent)
{
KAboutData *about =
new KAboutData(I18N_NOOP("fookcm"), 0, ki18n("Da foo KCM"),
0, KLocalizedString(), KAboutData::License_GPL, ki18n("(c) foo"));

Remember well the name we gave to the module (fookcm), we will need it later. So you wonder what we need to add to the constructor to make the magic happen. A single line:

setNeedsAuthorization(true);

What does that do? A variety of things:

• It maps the KCM to the action org.kde.kcontrol.<modulename>.save. So our save action is named org.kde.kcontrol.fookcm.save. Keep this in mind, we’ll need it later
• It turns kcmshell/and or systemsettings Ok and Apply buttons authAction property to the newly mapped action, so that buttons reflect the action state (eg: they are disabled, show a key instead of the icon, etc)
• It sets some additional visual feedback to the kcmodule.

After this line, your header (obviously after the action install phase, which I’ll show you later on) when you are required to authenticate will look something like this:

Neat, isn’t it? But to achieve this, a small thing needs to be done. We need to create an action file. So let’s just open your favorite editor on fookcm.actions (the “actions” extension is mandatory to let scripty translate your file successfully) and let’s write this down:

[Domain]
Name=Foo configuration
Icon=foo

[org.kde.kcontrol.fookcm.save]
Name=Save the foo
Description=Authentication is required for saving the foo
Policy=auth_admin

It is pretty straightforward, but let’s see this in detail. The structure is a standard ini file. You can define an unlimited number of actions in each actions file, provided they belong to the same domain (in this case org.kde.kcontrol.fookcm). The group name is the action name, Name is what will appear when you will browse the PolicyKit Authorization module, and Description is the message that will appear in the auth dialog. Policy is mandatory as well, and defines the default policy. It can be yes, no, auth_self or auth_admin. There is also an optional field, Persistence, that will define the default persistence of the authentication. There is also a special “Domain” group: this defines some additional settings that will affect all the actions under the domain you’re configuring. You can set the Name, that will appear as the folder name in the PolicyKit authorization module, and an icon that will be shown both in the authorization module and dialog. The whole Domain group is advised for better feedback, but not mandatory.

Done that, we need a small magic in our CMakeLists.txt. We need to register the actions like this:

kde4_install_auth_actions(org.kde.kcontrol.fookcm fookcm.actions)

Straightforward as well. Just define the helper ID (which basically is the action domain) and the action file. This will take care of generating and installing the actions for you.

So now we have our beautiful kcmodule with all bells and whistles and our save() function will be called just if the user is authorized to save the module. But we’re missing one step, huh? We actually want to save stuff in /etc, so we need high privileges. Then it’s time to create our helper.

Creating an helper is really easy with KAuth, since with the tools the library provides you, you won’t even know another application is running in the background. The helper has also remote debugging, so if you issue a qDebug() from the helper application, you will see the output in your main application. So you really don’t have to care about the fact it’s separate. But let’s get to the point.

Let’s create a new class for the helper, let’s name it FooHelper. The header file would look like this:

#include <kauth.h>

public slots:
ActionReply save(const QVariantMap &map);
};

There are some small but important details here. For every action our helper implements, we need to define a slot that has EXACTLY the same name as the action itself (so save), returns an ActionReply and accepts a QVariantMap. It’s EXTREMELY important that the return type is an ActionReply and not a KAuth::ActionReply, eg you have to use using namespace KAuth. Short explaination: otherwise things won’t work. Long explaination: we’re using QMetaObject::invokeMethod for calling the actions, and it is extremely picky about namespaces.

To understand better the arguments, let’s have a look at how to implement save() in our kcm

void FooKCM::save() {
KAuth::Action *action = authAction();
QVariantMap args;
args["path"] = "/etc/foo";
args["contents"] = "foooooo";
action->setArguments(args);
KAuth::ActionReply reply = action->execute();

I did not write the followup, where you actually check the result of the reply and act accordingly. So what we do here is grabbing the authAction of our KCModule, attaching some arguments, and executing it synchronously. I think you can now realize the reason for the arguments of the save function of the helper. ActionReply can also carry a QVariantMap, so you have a way of returning data back from the helper. In any case, returning ActionReply::SuccessReply will just tell the main application that everything went well.

Almost done (I’m just skipping the save implementation in the helper, as it is really stupid). We need two more small things, one in the helper implementation (our foohelper.cpp) and one of course in cmake. The first one is a macro, and it goes like this:

KDE4_AUTH_HELPER_MAIN(“org.kde.kcontrol.fookcm”, FooHelper)

What does it do? It accepts our helper ID (so the actions’ domain), and the class which represents the helper itself. Under the hood, it creates a main function for the helper instantiating and registering your class. CMake stuff is pretty straightforward as well:

kde4_add_executable(fookcmhelper foohelper.cpp)
target_link_libraries(fookcmhelper ${KDE4_KDECORE_LIBS})
install(TARGETS fookcmhelper DESTINATION ${LIBEXEC_INSTALL_DIR})
kde4_install_auth_helper_files(fookcmhelper org.kde.kcontrol.fookcm root)

It adds a new executable, that has to be installed (this is mandatory) in LIBEXEC_INSTALL_DIR. Installing it elsewhere will make things fail. The additional macro you surely spotted takes as arguments the target, the helper ID associated to it, and the user under which the helper will run on. Yes, you can also create helpers not running as root! This can be extremely useful to improve security in some cases. Under the hood, this macro generates and installs a lot of files. It creates a dbus policy for your helper, so that it will be able to be exposed on the system bus, and an activation file, to make it start up automatically. As you probably have realized by now, the helper ID is nothing else but the service name of the helper. But as you noticed, you (as a developer) do not even know that DBus is running under the hood, as you don’t see/have to write a single line of DBus related code.

That’s it. You now have a nicely integrated, rock-solid, clean and extremely secure KCModule that saves data with high privileges. I’m not covering why it is secure (you can read about Polkit and/or Authorization Services if you are interested) as this post is already long enough.

Also, what I’ve shown you is just a very basic usage of KAuth. You can, for example, execute actions asynchronously, and stream progress of an action, and even data from your helper. To learn more about KAuth, go now to the KDE API Documentation for a complete overview of KAuth and its capabilities, and be sure to have a look at the KAuth namespace documentation, which features a really extensive introduction/tutorial that will be reformatted as well to be included in Techbase.

Now, before you start yelling this is the best thing you’ve ever seen, there are also some caveats you might want to be aware of and, of course, avoid:

• If you are using a non-standard type in your QVariant, Q_DECLARE_METATYPE is not enough. Data is streamed through the bus in a binary datastream, so you have to implement custom operator<< and operator>> of QDataStream for your class. Please read QDataStream documentation for more details about this.
• KAuth needs to install some files in privileged and specific locations. In particular, if you are installing stuff in a different prefix than /usr, things will not work out of the box. You have to tweak DBus configuration and move PolicyKit files to /usr (even though the PolicyKit guys are fixing that) to make things work. But be careful in editing DBus configuration as you might end up screwing your system. More details on that will follow on the TechBase tutorial. If you are installing KDE from packages you can simply ignore this, or blame your packager.
• I noticed (at least here) that sometimes DBus does not recognize immediately new policies/autostart services. Before screaming about things not working, you might want to try restarting DBus first.

That’s all, folks. Hope you enjoyed this, please give me some feedback before I push a refined version of this tutorial on TechBase.

Just testing Bilbo Blogger.

Looks like it could actually rock.

So byebye wordpress web interface!

So, quite lately, but it’s my time as well to write a small wrapup on this wonderful Tokamak. Shame I had to leave earlier than all the other guys due to an exam, but I managed to have a great time anyway. I met a lot of people who I really wanted to get in touch with since a lot of time, and it was great sharing rooms and beds with a lot of people you work with all the year but you somehow manage to meet in person just in some special occasions just like this one

The location was lovely, the host even more, so Mario keep your mobile switched on as I could call you anytime to share a beer together in the beautiful randa again. And I also hope I won’t have to wait some more years to catch up again with all the great KDE people I met in Switzerland.

Of course, it was not just about socializing. We also pushed a lot of new stuff, which we will refine and get ready for 4.4. KAuth is almost stable BC/SC wise (will be soon on cmake side, since some macros are still being discussed by me and Alexander), and it took really some pain to push it in. Pushing a new framework that relies on generating some special files in kdecore can be difficult and you sometimes need to take the most difficult route to lead to innovation.

I had also a lot of valuable reviews after pushing stuff in trunk. I had seen this coming, and this is probably the most important reason why I pushed this framework that early in the development cycle. This way, I sure have to change some stuff around in kdelibs/kdebase, but I am also sure that when we have 4 months yet since 4.4 release, we have a 100% tested and reviewed framework ready. I realized during all my time in KDE that kdereview, for this kind of stuff, is really not enough; and I was proven right

What am I going to do in the next days: some tutorials for developers (still did not write anything due to the fact that we’re still stabilizing the API), some more talking with people interested to use KAuth for their stuff, and make a plan for trying to integrate KAuth into KIO::File. It’s a difficult task, but we have some great people ready to help (Davide, Nicola, Riccardo), and we really want to get this feature in, so we’ll try our best.

And some stuff for users (hoping that Sebastian will push the nice “commercial” videos we made ), such as screencasts, screenshots and whatever to let you know what this thing is bringing to your table.

All in all, we really managed to join productivity and fun in a way I did not think was possible, but this is what happens when you share some days with some of the best developers (and crazy people) out there. You guys rock, thank you for the great time I (and you hopefully) had, and I’m really looking forward to see you again!

Yes, KAuth is finally in KDELibs. Yes, systemsettings has integration. Yes, the first module (date/time) is already ported & ready. I know this was a long awaited feature by many of you, and now it’s in. But today, I want to show developers how to enjoy the new power of this framework.

First of all, what is it? It is the first known framework to check for authorizations by fine granting them and/or granting applications high privileges in a transparent, secure way completely integrated with the desktop and completely native and multiplatform. So you have quite some power in your hands. Why should you use it? Well, if you want to lock out users from certain features, for example, or to perform privileged actions. But let’s get into details.

KPushButton and KAction have 2 new methods, which are setAuthAction and authAction. Just set a KAuth::Action into one of them and you will have the following things for free: the authentication will be automatically triggered when the action/button has been triggered, you will get an authorized() signal when the user actually got the authorization, and the button/action change their availability and appearance according to the action status. Quite straightforward, huh?

KCModule has a new method as well. It’s (set)needsAuthorization(). Whenever you set this to true, an action for it will be created, named “org.kde.kcontrol..save”, where name is your KCM’s main as specified in the KAboutData. Just do this, and you get all the ui integration for free and save() will get called just when the user grants that authorization. Even simpler, isn’t it?

Want to have a look? A tutorial on Techbase is coming up, but for now, you can simply have a look at kdebase/workspace/kcontrol/datetime and kdelibs/kdecore/auth/example to have an idea. I’ll ping you back when the tutorial gets ready oh, and api.kde.org is your friend as well, Nicola made a great work in documenting all the library just for you guys to pick it up.

So put your thumbs up for a great GSoC project ended, and stay tuned, because this is just the beginning. The next keywords are now: KIO, GHNS, and KIOSK.

And put your hands up for the fun and the productivity we are having at Tokamak 3!!!

As you might have understood if you’re reading me, if you’re easily offendable on this matter, you’d better skip this post.

So, i figured out I should shout out something. Because I am always interested in hearing skilled, readable, balanced and well-made opinions from people such as Richard or Adrian, but I’m fucking tired of hearing random people screaming out why mono is cool or not. These kind of people don’t even know what coding is about, or they just learned Java or C# at university and they’re like “oh shit, I can code!!”. STOP THAT.

This is a technical, and ethical problem that regards DEVELOPERS. Users will end up having choice. All you pro/anti-mono fanboys, what is difficult in installing or removing mono, being it provided by default or not? No matter what your position is.

After this small rant, hoping to have made some things clearer, let’s move forward.

I’d like to skip the ethics/politics part for a variety of reasons. First of all, I’m all for things that work, if they’re free, much better. That’s why I’m using closed nVidia drivers, because they work better. Secondly, everyone has freedom of choice. And this also means freedom on choosing where to be free. And I hope some false freedom advocates will revise their concept of freedoms. One should be free of being not free as well. And more than that, this is not my field, so I’ll just leave the word to someone knowledgeable (following what I said before)

That said.

I am still asking myself why on earth people should need Mono, .NET, C# or similar stuff. I am starting to think that while more and more people are starting to code, the overall coding skills are getting lower and lower. Maybe it’s just me being too strict in using almost always C/C++, but I remain extremely confident in the fact that if you don’t know how/don’t want to manage memory, you should be doing something else. I’m not saying that using python, ruby or similar stuff is bad: I do it as well, and enjoy doing it. I think being capable of using JUST python, ruby or similar stuff is bad. Also for broadening your mind and knowledge. Just my opinion anyway.

Before you start yelling at me: yes I used C#, and some friends such as Java (similarity is almost ridicolous). I wrote about that as well. There were some things I liked, but a majority of things I disliked.

Now, comparing what Java/C# has to offer (just to demonstrate that I’m not blindly bashing C# only, that I also like better than Java) with Qt, there should be a single question.

Why on earth someone should choose C# over Qt/C++?

I don’t know, really. Maybe introspection, it’s much better. Maybe serialization, it really works out. Maybe something else. But when i talk about something that should be the backbone of your program, such as event loops, threading, events, and whatever, Qt/C++ puts C#+Forms/WPF/etc to shame. Please come up with some technical reasons why C# is better. And don’t start with compilation: I don’t think it’s so relevant for a deployment.

I don’t want to spend more time talking about this: you can verify what I’m telling you is true by looking at the percentage of KDE code written in languages different from C++. And we have some great bindings.

So, what’s the conclusion? Why people can still code fast, efficiently and easily with an “old” language like C++? Probably because the toolkit/framework integrates extremely well and extends the language to fit everyone’s need. That’s what Qt does.

So this is the point, on which you are free to flame me until death: the problem is GTK. Consider the amount of programs recently written in GTK. A huge percentage of them is in Python or Mono. Let’s be clear: I don’t have anything against bindings. But try stopping your flaming ego and follow me a bit more.

We have PyQt and Qyoto. Yet they are not so widespread and planetkde is filled with new C++/Qt apps. So where is the problem? Probably people are no longer comfortable in programming with GTK/C. I did it a while ago, and it was quite a pain to me actually, and it made me want to look into python, damn my laziness. I think that this is the kind of route a lot of people take nowadays.

Now you’re expecting a sort of GTK/GNOME flaming here, right? Well, bad for you. This was not meant to be a flame, just an introspection to understand the reason why mono existed (see the introduction). And my take is that mono is just a way to “modernize” something that is NOT obsolete (and I repeat: NOT obsolete), but simply no longer fitting the 2009 attitude of “oh shit I need to create a program in 3 lines of code!!!”. To demonstrate that I’m actually not attacking GNOME and/or GTK, I’ll give you Microsoft.

If you think about it, the iter that Microsoft followed for getting more developers is not that different from the one GTK took. So, what’s the conclusion?

Mono is not the panacea. Mono is a great way of developing easily, without spending that much time. But some skilled GNOME developers already showed the world (*cough*GNote*cough*) how Mono is NOT saving time to someone who is skilled and knows how to do things the right way. To me, GNote is not a symbol of freedom, but a symbol of the fact that people can still use GTK with success with C or C++ (and by this point I hope you realized that this is not a war against GTK, more some constructive criticysm).

So, Mono is nice to have, but not required to have, and not necessary to have. And I don’t see (today) a reason why a developer should choose C#/.NET/Mono over Qt or some other great frameworks out there. And I still think it is a nicer bridge FROM Linux TO Windows, and not the other way round. You should be blind if you can’t see it, or you’ve been simply hiding in your house without looking for a job those days. People need to make money, dude.

Last line, I bored you enough: my solution to the debate is not boycotting, insulting or anything: is having easier, crossplatform toolkits, and more skilled developers.

And now come on, the flaming box is just some pixels away from you!

Dear lazyweb,

As you know, it’s not in my style filling PlanetKDE with non-KDE related stuff, but this time I really need some help from the community, as I know that there are some good musicians around you.

I’m about to buy a synthesizer, since we’re adding some electronical influences in our band (we’re mostly playing rock music). So, here it comes. I need something on a decent budget, with good action on the keys (I’m quite choosey as a pianist), and decent piano, strings, and lead sounds (square and sawtooth are the sounds that intrigue me the most at the moment, but I’m opening to a new world in which I’m quite ignorant).

I would use it with piano sounds, and with synth sounds, mostly to harmonize guitar parts (such as solos). I would let you taste a sample of our latest work but it’s still in the studio. Anyway, this synth should be suitable especially for live performances and optionally for composing.

At the moment, my choice for budget and everything is the roland Juno-G. It fits my budget and it looks like it will fit my needs as well.

Here’s the question: any advice on this being a good/not bad/worst ever choice? Any other synths you would recommend me?

Well, it’s day 3, but yesterday I had no time to blog or whatever, so I’m just writing with a day of delay.

So yesterday I woke up at a decent time to check out from Anker and getting to Munch. After having left my luggage over there, waiting for Will to arrive, I took a tour of the Oslo fjord, which is really nice, especially the park around it. I had a nice and relaxing walk, and then I catched up with Will and headed up for Nokia offices.

Once there we met all Qt software guys, that were basically waiting for us after having read my previous blogpost. I suppose that is the web 2.0 deal everyone’s talking about. Anyway.

We had lunch with Knut, Thiago and Alexis and talked about some stuff, while waiting for Frederik and the students to catch up with us. We actually discussed some plans about the networkmanager applet and we now have a defined direction, that we will probably make real today. That was worth quite some hours of work, and we left the office around midnight to get some fun in the town.

So me, Frederik (who is basically sitting next to me writing probably the same stuff on his blog, and that feels kinda weird), Will and Olivier took the chance and went into the Garage having a beer. After Will left us, since he was really tired after his flight, the three of us went to Rock Inn to get another beer and some nice music.

Waking up today felt kinda hard, and me and Frederik are basically waiting for the other guys to arrive. Well, it’s always like people going to bed later are the ones waking up earlier. And hopefully, you should see some code today as well.

So I finally arrived in Oslo for the NM applet meeting. Today I’m alone, since the meeting starts tomorrow, but I came here one day before to cut the travel costs (yes, hard to believe, but it’s true) and I decided to write a small something everyday, since it’s a whole new experience for me.

I left from Bergamo at 10.45. 2 hours and a half later and 20°C less after, I finally arrived in Torp, greeted by the awesome view of the Danish and Norwegian coasts, one of the most amazing things I’ve ever seen. It still took an hour and a half to get to Oslo, and some more time to reach Anker, where I’m staying just for this night (I’ll join the rest of the KDE people in Munch tomorrow). The room is really nice, especially for the price paid.

Oslo is kinda expensive, but I fit myself finding some pizza slices at 20kr (2 for 30). Not the best deal ever, but quite cheap for the standards indeed, I hope tonight I’ll be eating somewhere decent.

The city is nice. Well, it rained almost all the time, but I took the time to walk on the Opera theatre, have a quick look at the fortress, and walk through the main streets of the city.

A fun fact is that I needed an adaptor for my PC. Without knowing which kind of ac plugs they had in Norway, I brought an english one from home, and came here to find out that they have german-like ones. So I went to a shop (on advice of the people at the hostel) to buy another adaptor, and they told me they the only ones they had were for english plugs. As you can imagine, my setup now consist of my laptop plugged into my adaptor, which is plugged into the adaptor I just bought. Lucky chance indeed.

Tonight I’ll look around for some pubs & clubs, hoping to have a great night in Oslo. And if you’re hanging around there, be sure to catch us in the next days to join the fun!