Tokamak 3 wrap up.

Ok, so I’m back from Tokamak III (well, since friday evening actually), but didn’t find the time to blog about it yet until now, so here it is.

Tokamak was amazing… There was a great vibe, the surroundings were absolutely gorgious (you could have spotted some pictures on other people’s blogs so I won’t bother providing my own), and a whole lot of work got done. For a nice overview of all the accomplishments, take a look at the excellent dot article about Tokamak 3.. I again would like to thank Mario Fux for organizing this great event.

In this blogpost I want to cover my own work, the remote widgets GSoC project in some more detail. It’s shaping up quite nicely, and is merged into trunk so anybody can easily test it (well, anybody who builds KDE from trunk that is, but it’s still easier then building the various git branches of different parts of the project, so…) I’m about to commit some changes that allow libplasma to be compiled without support for remote widgets in case of a missing QCA2 library, (which means QCA can remain an optional dependency for kdelibs) but even with that change there are some possible pitfalls when wanting to get remote widgets to work:

You need the QCA2 from kdesupport, not a released version. The one in kdesupport contains a bugfix, and without is, there’s a good chance, you either won’t be able to publish remote widgets at all, or they work very unreliably.

You need the qca ossl plugins. Actually, not having these plugins in working order currently causes a crash, which I should probably fix soon. Some warning and not crashing would be better, altough less spectacular.

For the zeroconf stuff to work, make sure you’re running your avahi-daemon and you have kdelibs compiled with DNSSD support.

When publishing a nowplaying widget, please note that there was a silly bug in the nowplaying applet, that causes a crash in the case of a remotely accessed dataengines, since the sources don’t exist right away in that case. Make sure you also got an up to date kdeplasma-addons.

When you’ve got this, and a recent trunk checkout, built and running you can start publishing widgets! Just open the configuration dialog of any widget, got to the Publish page, and check the checkbox (and optionally the one to allow everybody free access).

The widget will now be published and announced over zeroconf. Accessing can either be done by clicking the ‘add to current activity’, or by using plasmoidviewer and passing an url to the widget, which can be seen scrolling by in the debug output. Integration in the new widget explorer will follow, so will the ability to just drag and drop from the network:/ kio slave, which, thanks to the work of Friedrich Kossebau, already lists remote widgets on the local network.

Soon there will probably be some little demonstration video (like a screencast… but then better 🙂 ). And I will probably also tell something about my future plans concerning remote widgets. Stay tuned!

Remote Widgets have landed!

Just a quick message to tell that I’ve just merged my remote widgets branch for GSoC into trunk. There are still rough edges…. actually, quite a lot of them, considering it just went through a massive refactoring as a result of the API we held here at tokamak, but it builds, and basically works with plasmoidviewer. Dario Freddi really was of great help getting the refactoring done and getting things merged, and tomorrow we’ll be working on integrating his work on KAuth to make rules stored securely. Then I will hopefully also be able to squash some bugs, and port plasma-desktop to the new API as well.
I will blog more about it later, including some instructions on how to actually use this stuff, because the GUI in that department is somewhat lacking (say: mostly nonexistent at the moment), but, YEAH! it works.
So far this is an insanely productive Tokamak, in an incredibly beautifull surrounding (the mountains are amazing). Mario Fux has done an incredible job so far on hosting this event. Thanks for that.

Well, now I’m going to sleep, its almost 5:00 in the morning already, and I’ve been hacking on remote widgets for most of the time since this morning so… I’m kind of tired. Stay tuned….

Little remote widget magic screencast.

Since the last time I blogged about my GSoC project, now not only Plasma::Service and Plasma::DataEngine can work remotely, but I’ve implemented a service that allows a remote machine to obtain a plasmoid. I also implemented support for blue tooth like pin pairing authorization as a quick way to connect two machines. As cherry on top, some massive refactoring work made both code and API a lot nicer. The refactoring made me discover a bug in QCA (a lovely Qt like framework for crypto stuff), and it took me a day or two to realize that the problem had to be in QCA and not in my own code, but QCA’s maintainer Justin Karneges was very responsive and within a couple of hours after my first email he had identified and fixed the bug in QCA: great work! 🙂

At http://blip.tv/file/2380126 you can see this process. (note that blip.tv allows you to download the original Ogg/Theora file for people like me who don’t like flash)

As you can see I start plasmoidviewer in a Virtual Machine pointing to the url under which the plasmoid is published. The plasmoidviewer I’m using there is slightly modified to allow connecting to remote plasmoid. The published plasmoid is a slightly modified version of “Now Playing Controls“. The only thing that I modified though was the addition of a label showing artist + title to show remote dataengines are working, you don’t need to change anything in a plasmoid to allow it being remoted. At the moment remote widgets only work with scripted plasmoids (and we definately need more of those… scripted plasmoids are awesome! :)), and I would have loved to show a really fancy plasmoid here, but I couldn’t get the python script engine built, so I couldn’t use for example the quite fancy now rocking plasmoid.
Anyway, what follows is that I need to enter the password to unlock my kwallet (that’s where the private key is stored that is used for signing messages so the receiving side can be sure of the other machine’s identity. anybody knows if there’s a way nowadays to have kdm unlock your wallet?). Then I enter the same password on both machines. It’s identity verified, the virtual machine then receives the plasmoid package. This package is automatically changed to indicate that dataengine should be obtained from a remote location as well, and the result is that the plasmoid in the virtual machine can be used to control amarok on my other machine. Nice right?
What will follow is the ability to also authorize remote machines that have some gpg key in a trusted key ring, the possibility to have this also work with c++ plasmoids (only if both machines have that plasmoid installed of course), some better error handling, and, of course, zeroconf support. Stay tuned!

Remote dataengines working.

My SoC project is now at the point where not only remote Plasma::Services are working, but remote dataengines too. Which means I’m now actually running a nowplaying applet in my virtual machine which shows what I play using Amarok on my other machine. This applet can also be used to control that remote amarok, just like it would when run locally. And all this didn’t require any change to the nowplaying applet or dataengine, only an entry in the nowplaying applet’s configuration instructing it where the nowplaying dataengine should point to. Pretty neat right? Here a screenshot, because people like pictures:

Next step is supporting blue tooth like passkey pairing: when an untrusted machine connects, both sides can input a password, and if both passwords match, access is granted. Stay tuned!

GSoC remote widgets: first milestone.

I finally reached a significant point in my GSoC project. Since yesterday I can actually control amarok through a published nowplaying Plasma::Service from another machine! Not only that, messages are digitally signed and verified so we can be sure who tries to connect to the service, and tested agains a set of rules that define which machines are allowed to access which services. With just a little bit of work I can even ask the user interactively “<….> tries to connect to the nowplaying service. [Always Allow <…>] [Allow] [Deny]”, just by implementing an AuthorizationInterface that fires up a notification. If you’re the type of guy that that is interested in fresh API and would like to make it perfect, please join the api review on the plasma mailing list 🙂

The next thing that I’ll need to do now (besides fixing a very annoying random crash) is building a dataengine service on top of this. This will just be a Plasma::Service implementation that allows access to dataengines. Then implement a dataengine that uses this to access remote dataengines. And extending Applet to have dataEngine return a remote dataengine pointed at the correct location if stated so in it’s configuration.

Still enough work to do, and nothing very spectacular to show but with all basics in place now and working, I’m making good progress. This is a really interesting project. I love working with new technologies (I’m now actually the first user of Kevin Ottens still WIP but already pretty sweet QtJolie library, and JOLIE itself is also pretty hot). And the security aspects are very interesting as well. I’ll try to blog more often now the basics are in place and the very visible part of development is really just beginning. Stay tuned…

Jobs and notifications in the plasma systray.

I’ve been doing some work since 4.2 to make sure jobs and notifications in the plasma systemtray have better usability then in it’s 4.2 incarnation. Being a new feature it unsurprisingly still had some rough edges. Thanks to a lot of feedback, and discussion on the issues, the current implementation solves a lot of annoyances. Here’s a probably quite complete overview of improvements:

• There are 2 kinds of people: those that like it that the popup with jobs and notifications automatically hide after a short while when it’s automatically shown, and those that don’t like this behavior. Apparently, most of the plasma developers are in the first group, but looking at some of the comments I got through bugreports, blogposts and what not, the second group also has quite some followers.
  Two problem with auto hiding are:
  a) people tended to get confused, thinking the job was finished when it autohides
  b) some people usually wait for a job to finish when they start one, or have enough screen real estate (multiple monitors) that the popup isn’t really in the way of anything anyway.
  Issue a) will be much improved now that we animate the icon in the systemtray that indicates there are jobs/notifications while jobs are actually running, and the fact that, at least for compositing users, the popup smoothly slides into the panel when it get’s hidden, giving a clear hint to whats going on. For issue b) however, we decided to add a config option to the systray config dialog so you can disable autohiding if you don’t like it. Autohiding has also been improved by making it more consistent: always autohide on new automatically added items, and not only on jobs.
• When a job completes, it now becomes an entirely different widget, and the popup get’s automatically shown so you can see when a job finishes, and, if it’s a file transfer, even open the file or destination directory (in case of multiple files), directly from that message. Furthermore, these items are nicely grouped with all completed jobs. I’ve currently got a patch pending on reviewboard with which they get automatically destroyed after some time (currently 5 minutes, might still change) so they don’t get in your way, but don’t get destroyed when you’re not using your computer. So you can safely go away from your computer for a couple of hours, and when you come back, will still be able to see which jobs are finished in your absence.
• The job progress widgets have been improved: nicer layout, shows ETA, and can even show number of files/directories/bytes with a click on the ‘more’ link.
• The job progress widgets are grouped in one single progress bar that shows eta, and total progress of all running jobs on your system. By default this group is collapsed, but if you like all the details, you can expand it with a single mouse click (persistent between plasma restarts btw) and will see all individual jobs.
• The icon to show/hide the popup is now not only animated when jobs are running, it also shows how much items (jobs and notifications) are there, and how much of them have been completed if some are still running. It even has a tooltip… one glance and you instantly know how much jobs are still running, even if the popup is hidden.
• The plasma notifications also show custom images, like kopete’s contact images.
• Probably forgetting some stuff here, and some bugs got squashed.

Of course there are supposed to be pretty pictures with an blogpost like this, so here you go (don’t get worried by the not so readable white text in front of the spinner icon, small problem with the Air colorscheme that will get adressed):

Because the tray uses extendergroups now to group running and completed jobs you can now even do insane stuff, like detaching the in-progress-jobs group to your desktop, in which case every new job will appear there on your desktop, but completed jobs will still appear in to tray’s popup (which is actually quite a nice configuration, as I found out when I tested it).

But keep those suggestions coming (well, only if they are good suggestions of course ;)), so the 4.4 systray can be even better 🙂

GSoC 2009: network transparency in Plasma

As you’ll probably have noticed, the accepted proposals for the Google Summer of Code of 2009 have been announced. KDE has a nice selection of projects this summer, and I’m very happy my proposal is one of them.

So what does this ‘network transparency in plasma’ mean? Allow me to copy/paste some stuff from my proposal:

The goal of this project is to make some parts of plasma network transparent with as end goal the ability to:

• have applets be able to use services and data engines on remote computers
• move applets and activities over the network
• share applets and activities between multiple computers

This allows for some innovative new use cases in plasma:

Alice is a teacher on a school where they use computers as a learning aid. She has set up all computers in the classroom to display a single shared activity in plasma. Now Alice can modify this activity on her computer depending on what she teaches that day, and all the children immediately see changes she made on their desktop as well. Because this activity is shared, a lot of applets also sync smoothly: whenever she modifies the text in a certain note applet for example, all children will immediately see this change. Alice can use this mechanism to give children exercises through the blackboard applet, and she can monitor the children’s progress.

Bob’s desktop PC is connected to his stereo, and he often uses that PC to put on some music. He doesn’t want to have to walk to this PC whenever he wants to, for example, skip a song. He publishes the “now playing” applet that is already on the desktop of his main PC. He picks up his wifi enabled smart phone, and in the add widget dialog on his phone (which is of course running plasma) he selects this published applet from the list of  applets and containments that are published on the network. Now the exact same “now playing” applet appears on his phone. He can use this applet to skip songs on his main computer, or to see what song his main computer is playing.

Charlie just got a new notebook. He would like to have some of the same activities he has created on his other PC on his newly installed notebook. He publishes these activities to the network, and adds those activities on his notebook. Note the difference between this use case and the previous one in that in this use case, Charlie will want to use his the local data engines and services of his notebook, instead of being connected to the data engines/services from his main computer.

This will of course all be wrapped in awesome api, so the developer doesn’t need to care if a DataEngine or Service is local, or hosted on another computer.

I hope I made my project a bit more clear to those who were wondering what exactly ‘network transpancy in plasma’ means.

Chakra: my new distro of choice.

I’m the type of guy who goes distro-shopping every now and then, but usually ends up with the distro I came from. I’ve been using kubuntu since hoary (5.04) and have been quite pleased. However, last year with KDE 4, I’ve grown a bit frustrated with kubuntu. Packaging has certainly been improved over the course of last year, but still there are quite some little problems I encounter now and then and somehow it’s starting to feel more and more draining on my systems resources. Plus I’m starting to dislike the 6 month release cycle, and rather always stay up to date.
I’ve tried a number of different distros but I’ve never really encountered my ‘dream distro’. There were always some things I didn’t like: slow package manager, hard to use package manager, capable of breaking my system package manager, bloat, wrong choice of packages, broken multimedia stack, too different from debian without good documentation so I couldn’t get used to it… you get the idea…
And then, two days ago I suddenly came across Chakra. It’s basically Arch linux + kdemod, but then with a live cd and quick and easy installer. And it’s amazing. It absolutely FLIES. On avage it consumes about 150-250 MB less memory then my kubuntu installation (?!). Everything works very well out of the box. The kde packaging is very well done. The live cd environment is one of the most response i’ve ever encountered (and uses only 256 MB RAM). It has rolling releases, so it’s easy to always run the bleeding edge. And it’s package manager pacman is really fast and easy to use.
If you are still looking for that fast, robust and well packaged distro for KDE 4, I’d really advice you to give it a try. Even though it’s only alpha2 atm, it’s still the best KDE 4 distro I’ve encountered so far.

Extender grouping and notification images

Last week I’ve spent some time on adding grouping support to extenders, and laid the foundation for grouping jobs in the plasma systemtray.

The grouping support for extenders is accomplished through the new ExtenderGroup class. ExtenderGroup is a subclass of ExtenderItem that adds an expand/collapse button to show or hide all ExtenderItems that belong to this group. You can add ExtenderItems to a group by calling setGroup on the items.

The grouping support for jobs currently uses this feature to show the total progress of all jobs. By expanding the group you can view all individual jobs. See this screenshot to see what this currently looks like:

The green arrow (we’ll need a better icon for that) hides the 2 jobs, keeping only the “2 running jobs” part. The nice thing about this is that by default you’ll only see this total progress when copying stuff, which doesn’t take up as much space as the detailed individual jobs. You can also notice the just added support for showing custom images in plasma styled notifications, which is used here to show a contact image. The oldschool passive popup notifications supported this, but the plasma notifications didn’t until now.

The handling of jobs in the systemtray could still use some more work (the layout of the individual jobs could still use some improvement, and maybe the global job progress should show a little bit more information), but you can see the direction we’re taking here.

Also notice the plasma theme that’s used here: Air, which will be the default for 4.3. The progressbars need some work (yes, you can see how far the bar has progressed if you look very good, and no, this isn’t very clear atm to say the least), but then again it’s still a work in progress. It’s starting to look very slick though.

Tokamak II

If you’re reading this you’ve most likely already read about Tokamak on some other blog or this excellent article on the dot, but still I like to write something about this experience. It was the first time I went to a kde related meeting and I have to say: it’s great fun. It’s great to have finally met a lot of the plasma devs in person and be able to put a face to those nicknames on irc. I’m now able to confirm that plasma people are in fact nice people with good taste ;), and I felt right at home.

We also had a lot of interesting discussions, not only about important stuff like whether or not mozzarella should be called a cheese (if you’re talking to someone from Italy you really shouldn’t ;)), but also about stuff like improving the system tray, kinetic (new Qt animation framework) and what aspects of plasma are currently weak points.

For the systemtray, we’ve designed a new specification that will hopefully be used in 4.3 and would not only fix the problems with the old spec and it’s inherit inflexibility, it also makes amazing new stuff possible. For example, being able to decide exactly which icons are useful to be displayed at which time, by requiring applications to provide a category and status to the systemtray. We also discussed a better way to display jobs in the systemtray. I’ll be working on implementing grouping support for extenders, so that in the case of the systemtray, all currently running jobs will get summarized in a single progress widget which can be expanded at will to show the individual jobs. Meanwhile, the current icon that shows whether or not any jobs or notifications are displayed in the tray will be changed to actually show activity by being animated. The 4.3 systray will really, really rock.

Besides a lot of discussion, also a lot of code got written. It’s amazing how much more productive you can get when you can ask each other questions face to face as opposed through mail and IRC. I’ve spent quite some time refactoring the way drag&drop was handled with extenders. While the old way allowed for easy live updates of the widget you’re dragging, while you’re dragging it, the new way avoids a bug which is not easy to avoid otherwise, and the code is faster and cleaner. I’m pretty pleased with the result.

Some of the other developers worked on plasmate, a simple editor for creating scripted plasmoids. While a lot of the individual components work for the biggest part, everything still has to be tied together. It’s going to be a very nice way to quickly create your own plasmoid. It will include the kate editor part of course, combined with an embedded preview of the plasmoid you’re working on, an easy way to edit the plasmoid’s metadata, a way to explore and edit the package, browse the api documentation and a way to directly publish your work. All in one nice, minimalistic editor. I think once it’s in usable shape, it will really make it a lot easier for people to start developing plasmoids.

It was also great to see other people using the extender api I created for the summer of code last year. Davide worked on some additions to the calendar so you can show details of a certain date (atm only holidays, but akonadi integration will follow) in an extender, and sebas was using extender in lionmail, a new plasmoid he’s working on which shows your email using akonadi. It’s really nice to see your work being used by other developers. Especially since the more widgets use extenders, the more this feature will shine.

There’s just so much nice stuff in the pipeline for 4.3… I could go on for hours, but I won’t: there still have to be some surprises along the way. While 4.2 focused mainly on restoring functionality of 3.5, 4.3 will mostly see innovative new features, which will make plasma really shine. These are very exciting times.

All in all I really enjoyed Tokamak, and I’m looking forward to the next meeting. 🙂