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

    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!


    17 Responses to “Tokamak 3 wrap up.”

    1. kinto Says:

      This is SO AWESOME!
      Thank you for making this reality.
      Can’t wait to try it!

    2. nuni Says:

      can i publish a video widet , and play it over the network ?

    3. rscheepmaker Says:

      @nuni: not right now. As opposed to say nowplaying controls, the actual video isn’t provided by a dataengine, and so does not get the remote functionality for free. With a couple of changes I do think we should be able to come op with a solution that allows this to work, though.

    4. illissius Says:

      Building qca and especially qca-ossl from kdesupport was a huge pain in the butt the last time I had to do it — has anyone fixed things up since then, or was I just being a klutz?

    5. Burke Says:

      Just to get this right. What excatly is possible now? I can publish the data used by my nowplaying applet and acces the nowplaying applet on another computer?

      And how do I access those applets? Will there be a window with currently broadcasted applets? Or the possibility to set “use network applet” on? Or will it be more the apple way, e.g. Controlling iTunes from an iPhone?


    6. redm Says:

      Uhm… for the ignorant of us, besides technical wickedness, what are the use cases of this? And shouldn’t there be some kind of access control? Or maybe I just missed that part…? I certainly wouldn’t like everyone in the local net control my music player 😉

    7. rscheepmaker Says:

      @illussius: hmm, I’ve never encountered problems compiling qca. But you can always drop by in #kde-devel, and probably someone can help you out if you encounter problems.

      @Burke: what happens when you access an applet that is published remotely are basically 2 things:
      * The widget get’s sent over in case of a packaged (scripted) plasmoid. For binary widgets, just the plugin name is being sent, and you still need to have the plugin installed on the other machine. This is unavoidable, and one of the many reasons scripted plasmoids rock.
      * All calls to dataengines and services, so basically the data that has to be visualized by the widget, are routed to the machine where the widget was published. So the widget runs locally on the machine from which you access the remote widget, but the data that is viewed/acted on by the widget is on the other machine. And this is all completely transparent to the widget itself… it doesn’t know, nor needs to know, that it’s not acting on local data.

      The way you access those applets would be through the widget explorer (yet to be implemented). But other methods are also possible, as described in this blog, like clicking ‘add to current activity’ in the notification that will pop up whenever a new widget is published on the local network. From that point on they just run as part of your plasma desktop, just like any other widget, only acting on remote stuff.

      @redm: Oh, yeah, I should probably blog about the security part as well soon. There is access control of course. That was actually quite a big part of the project: to make things secure. Just stay tuned for the next blog where I will explain the possible methods of access control that will be supported.
      Use cases? Well, of course remote controlling your media center would be one (sitting on a couch with you netbook device or phone, remote controlling some media center pc that’s connected to your tv), Collaboration stuff like sharing the same blackboard widget where people can draw and write stuff together for example. Monitoring another computer’s jobs, or system load information. Synchronizing presentations…. quick and easy sharing of certain files… be creative, a lot is possible. 🙂

    8. James Smith Says:

      GetNewStuff KIO?

      How hard is it to implement a KIO modeled on widget explorer after the idea has already been drank over? Or one that allows an actual perusal of getnewstuff and a drag and drop or double click to install version packages. GetNewStuff frankly sucks in it’s current form; version difficulties and version-relation bugs between desktop releases come to immediate mind.

      I have some other ideas regarding an output through nepomuk and akonadi for push-package updates without inopportunely-timed pop ups, but still in writing. Tags and keywords bayesian-type filtering and bookmarking help with package updates; listing on opendesktop via social-semantic login might prove interesting from a trending and marketing (Nielson) perspective.

    9. slashdevdsp Says:

      I am not sure about the approach for the addition of network option:

      should the network config be added for the specified widget config dialog?
      should the network config be added like the old way of adding plasmoids to the dekstop/panel – meaning a window showing the list of currently added plasmoids and another window showing plasmoids with remote network and the ability to drag the plasmoids into a group (network enabled/non network enabled)
      so it will be easy to enable and disable remote-network plasmoids with single click ‘disable remote plasmoids’ ‘ enable remote plasmoids’ for the currently running plasmoids. not sure if i made my self clear?

    10. rscheepmaker Says:

      @James: While I don’t really get the link with an GHNS KIO slave, I’m looking forward to your proposals when you’ve written them down.

      @slashdevsdp: As you can see in the dot article linked in this post, the new widget explorer allows you to publish widgets directly by just checking publish. Remote plasmoids will be accessable from a seperate category. The publish option in the config dialog is another way of publishing that may be convenient at times, and where we can easily put more options, like the “allow everybody free access” option shown in that screenshot that essentially turns of access control for that widget, but it’s not the only way to publish your stuff. Or am I misunderstanding what you mean here?

    11. Aurélien Gâteau Says:

      Wow! This looks awesome… I was playing with a DLNA tv yesterday evening, I wish it would have been able to export widgets to my laptop 🙂

    12. Sławek Says:

      I will use this to control what my entertainments doing. 😉

      Only putting task list and now playing control on locked plasma activity, share every plasmids on this activity and disallow to unlock plasmoid(is there any way to do this?).

    13. illissius Says:

      rscheepmaker: Nah I already have it compiled, I was just worrying about all the other poor souls who might have to do it :-). But if it worked for you without a hitch then probably someone’s gone in and done some maintenance (thanks, whoever it was, if that’s the case). When I did it building with cmake didn’t work, building with ./configure didn’t really work either iirc, there were all kinds of problems with it looking for its own headers in the install prefix when they were not yet installed (it wasn’t yet built!), which I managed to solve somehow, and manual copying of files had to be done, and things like that.

    14. ano Says:

      I see a lot of useful things that could be done with this technology.

      But what about sharing plasmoids cross platform? I mean, if there is a plasmoid to share files, that’s all fine and dandy, but a lot of people are still users of Windows/MacOSX/Gnome and so on. Are there any ideas/plans to make this stuff cross desktop/cross platform compatible? (maybe a new freedesktop standard?)

    15. slashdevdsp Says:

      I think thats what i meant, but I think what I was suggesting was like a category “Plasmoids with remote access – Enable/Disable” so there is one place you can see and manage all the remote access for all the running plasmoids

      eg: so there is 1 place to see all plasmoids, currently running plasmoids and if remote plasmoid is enabled
      list Plasmoids | Running plasmoids | Remote plasmoid Enable |
      a a Yes
      b b No
      c c Yes

      something along those lines, because I feel if there is 1-frontend to add plasmoid and remote access

    16. jospoortvliet Says:

      @ano: this IS crossplatform. You can run plasma on Windows, mac and on mobile phones, and everything works just the same. Of course binaries always have to be available locally, nothing can be done about that. But scripted plasmoids work anywhere.

    17. ano Says:

      So, can I install plasma on Windows XP right now? I use VirtualBox on Linux, with Windows XP as guest OS. It would be pretty cool if I could control the host OS through the guest OS and vice versa using plasmoids!

      Did anyone try something like that?

    Leave a Reply

    Fill in your details below or click an icon to log in: Logo

    You are commenting using your account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s

    %d bloggers like this: