Archive for the ‘GSoC: network transparency’ Category

Tokamak 3 wrap up.

September 8, 2009

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).

    Publish a plasma widget on the network.

    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!

    Advertisements

    Little remote widget magic screencast.

    July 20, 2009

    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.

    July 1, 2009

    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:

    Remote dataengine in action.

    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 2009: network transparency in Plasma

    April 21, 2009

    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.