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!

I’m sitting on my bed sipping one of the great beers I took home from bruxelles, eating some great Provolone (an Italian cheese) and salami, while I’m listening to Queen, Beatles and Rush, chatting with some friends and doing some code in the very spare moments.

Shit, this is happiness.

I feel so comfortably well that I really have to realize (once again) how small things change your life; how small things _are_ your life. There are a lot of small things, like this one, like seeing a smile, reading a pink post-it, play your music until your fingers and throat hurt, that make you feel happy, well, without knowing a reason. It’s like being in love. Most of the times it’s a person. Some times you’re simply in love with your life. And sometimes you happen to be in love with a person that made you love your life again.

This post is simple, small and short too, to keep things consistent (and hoping it will be beautiful as well to read)

Long time no see, again a post on PowerDevil.

PowerDevil has proven to be quite a solid software, and I’m both proud and happy about it: the 4.2->4.3 transition has happened almost with no maintainance (apart from a critical bugfix from Jacopo, thanks!). The proportion of bugs affecting it regard 20% up/downstream problems, 25% “please implement the feature x” and 15% “oh, the GUI sucks and looks confusing” (yeah, percentages are not accurate, I can tell)

The problem is that PowerDevil GUI does suck, big time, because it’s way too cluttered. However, I can’t add cool and nice features without cluttering it even more. Result, there has to be something wrong. The topic came back today by chance in a short conversation with Martin, and while I was eating, suddenly (and by chance, I was not even thinking about it) I got struck by an idea.

Let’s start knowing that Power Management is something that is very much linked to the hardware, and the average user should have a minor part in configuring/dealing with it.

Today, power management systems are based on profiles, more or less configurable. They offer the user access to a set of things to configure, and that’s it. There are some problems, though.

• The options are limited. Some features will still be missing
• The options can’t be expanded: code gets fat, GUI gets unusable
• Everyone loses on the long run: developers have a dirty code base, users have limited possibilities and/or an unusable GUI, distribution don’t have much flexibility in providing custom and effective settings, hardware vendors even less.

To me, this means one thing: the current profile concept fails. That’s why I thought about an alternative: putting an additional layer of abstraction: let’s call it “Actions”.

Actions are containers of, well, actions such as setting CPU scaling, brightness, and anything you can configure with PowerDevil right now. They come in form of plugins (KPlugin ftw!), so that you can create custom Actions (mind the capital letter) by defining your very own set of actions. But let’s make an example, to make things clearer.

You create a new Action, name it “Set Powersaving mode”. In it, you define (using the available plugins), that the scaling should be ondemand, the brightness 10%, the power scheme “powersaving”. That’s it. In the profile chooser, you now have a similar situation: a single page that has some per-event based fields: for example, “When PC is idle for more than 15 minutes, do”. Now what do you do? Just set an Action, in this case “Set Powersaving Mode”.

Everyone wins. Still can’t see why? I’ll tell you:

• Average users: they have to do almost no configuration, and they have it in a very readable form (as Actions can have human readable names, such as “Set Powersaving mode”), and with the best combination in the Actions, that were defined by KDE team, or by the Distro (better), or by the hardware manifacturer (even better)
• Power user: you finally can do the f**k you want with no limits, and I think that’s enough. And the GUI would be damn clean.
• Distributions: you have a way to define your very own actions based on your specific configuration, in a truly easy way, providing your users the best defaults possible
• Hardware vendors, and netbook vendors, I’m mainly looking at you: suppose your new motherboard has a “WOWSAVEALOTOFPOWER” feature, that can be used only on your motherboard by calling some weird functions. Pretty fine. Go ahead, and write 100 line of code to add a new plugin to PowerDevil’s Action system, to let Powerdevil handle it. Netbook vendors shipping KDE can also include it in their default Actions, to give their users the very best.

Looks cool? Obviously, we still miss one step, the configuration of events. I mean, leaving “When the pc is idle for … minutes” gets you limited and hardcoded. So simple, let’s apply the same concept to events too. A profile configuration GUI would look like this (squallid, more conceptual than anything else mockup):

That’s the concept. Slick, huh?

Well, even if it’s a fast and quick mockup, I think you will agree with me that it already looks much more polished than the current one And as you can see, adding a new event is very, very easy and human-readable. I also have a mockup for the Action editor:

Even more slick!

That’s it, the Events one would be analogue to the action one. As you can see, both GUIs need some love, but have a very simple and powerful concept behind. What’s more, is that this way we are getting even closer to Power Management integration in the system: all application would be able to define their own events/actions, allowing, for example, to stop your music when you enter deep powersaving mode, or anything you can think of.

Now, I’ve been eloquent enough, and now I would like to grab opinion and ideas. Do you like it? Would you like to see it in 4.4? Do you think it’s a major improvement and/or sucks? Let’s gather some ideas so that I know where to work on