Plasma Active 3 Sprint Ongoing

These days, the Plasma Active team (and a few people new to it) is meeting in Darmstadt, kindly hosted by basysKom to work on Plasma Active. Our topics range from closer integration of social networks and instant messaging to more hardcore topics such as our developer story (Plasma SDK, OBS workflows) and getting to run the thing on more devices, especially working on the system integration for the Spark tablet, that will become available to users in May. The meeting room is still buzzing with people fixing bugs, sharing knowledge, packaging, testing and (in my case, writing a blog).

Two topics that have been pretty important have been integration of social networks into the Plasma Active user experience, our plan here is to use Akonadi for collecting and caching stream from various social network sources, for example Facebook, Twitter, Google+ and others, and using Nepomuk for connecting this data from different sources to people we know. The problem of “Metacontact” (people you actually know, interact with in contrast to addressbook entries / email or IM addresses) seems to be “mostly solved” and in the process of implementation on various sides — KDE PIM, Telepathy, so we can use that as departure point to create a more natural view on your social surroundings. Now, a cunning plan that is well aligned with other components such as PIM (via Kontact Touch) exists, and we can move to the fun part: implementing it. This part will be spearheaded by Martin Klapetek, who has spent a lot of thinking on this topic.

Another important topic is our “Developer Story”. We identified three levels of target “users” for this: App developers of “simple” apps (meaning apps that can be done in pure QML / Plasma Quick and which don’t need C++ parts (we’re extending the possibilities here all the time), more complex apps that use C++ (Kontact Touch, Calligra Active, but also other apps that are being ported to Active UI guidelines and being made touch-friendly). This group will be served by a well-defined process involving ready-made cross-compilation environments in the form of virtual machine images. A third group (and likely the smallest) is the group of system developers. This topic needs a bit of work still, so in the areas where the tools provided by the fantastic Mer project do not suffice, we rely on passing on our knowledge in the traditional way: i.e. catch us on the mailing list or IRC, and we’ll try to help.

A special guest who arrived today is Mer’s Martin Brook, who has been very active in the Active team in the past months already, and who brought Plasma Active to a whole array of devices. It’s wonderful to welcome new people to the community, and it really rocks to see how effortlessly people who never met each other in person, and who come from quite different angle sit down and do great things together.

11 thoughts on “Plasma Active 3 Sprint Ongoing

  1. It’s lovely see the Plasma Active bloom. If twitter streams etc are coming to Akonadi does it mean we will also have desktop GUI on top it? Like Choqok port to Akonadi or something.

    1. That’s entirely conceivable, though not immediately planned. Likely the first UI to become available for this is the microblogging Plasma widget (which can also be started as an app, using a different user interface, I’ve done quite some work on that in January, but it’s not finished yet).

      As to the plans of the Choqok team, I don’t know what their plans are here, but of course we’d welcome working together on that. Maybe we’ll need to have one thing working first, and then “port” existing applications.

  2. Hi Sebas,

    A very long time no see! All this work going on in KDE land is more exciting then ever, especially the QML’ification and Plasma Active developments! There are so many interesting area’s to help developing with that if I would have time that I won’t be able to choose! Anyway, keep up the brilliant work!

    PS. I’m a bit concerned on social media within KDE, I think there should be a very (indeed, Akonadi backed) plugin based framework that integrates everywhere. I suppose something like a KCM for “Social network accounts” next to the telepathy pane in system settings.

    Anyway, great stuff going on!!


    1. Thanks for the kind words :)

      I agree, it’s a very exciting thing to work on, we have tasks on a range of different skill levels, so wether you’re a seasoned Qt / QML hacker, or a rookie who wants to get involved, there’s exciting work for you (or anybody who wants to join in, really).

      As to the accounts, yes, a centralized service account framework is actually part of our plan. It’s likely that we’ll first see a QML version of it, but it won’t be hard wrapping them in a KCM. The QML components we use allow us to write just one UI, which then adapts itself to the device it’s running on, be it a touch device, or a mouse/keyboard driven one.

      1. Couldn’t the entire KCM system be ported to QML? …or would that make any sense considering the future of KDE configuration management.

        1. Yes, it could, but it would only provide limited value.

          KCModules are based on QWidget, so they only “kind-of work” on touch devices. Also, on touch devices we are dealing with different screen sizes (higher or lower resolution, often higher pixel density), different use-cases (settings that are there in “desktop” system settings might not make sense on Plasma Active).

          I’ve blogged about some aspects of this earlier, you can find that blog post here.

  3. OT (sry don’t know where I have to ask such things): Are you interested in spending some time to get lionmail ready for a stable release? I think there isn’t much happen in the last time. In my oppinion plasma active would also benefit from a stable lionmail (e.g. could be insert as a widget in a “news activity”)

    1. Yes, interested I am. Do I have the time to do it? Unfortunately not. :/

      The good news is though, that Kevin Krammer will hopefully mentor a GSoC project with the goal of implementing “LionMail2” as I’d call it — basically LionMail’s UI concepts, done in QML and using the proper Akonadi / PIM models.

      The first version of Lion Mail suffers from a few architectural problems, which make using it prohibitive in terms of memory consumptions in certain (relatively common) cases, that’s why it hasn’t seen a release yet. I’ve only got as far as writing some proof of concept code, but hopefully we’ll have it in capable hands soon so it will finally come into the hands of users.

      Of course it would benefit from more helping hands, if you’re interested in helping out with it, please feel most welcome, I can provide you some pointers how to get started.

      1. I can do tests and give bug reports but I have no skills in coding. I’m just a student in humanities and long year KDE user. Sry

  4. Is using scratchbox and having an Active SDK considered? based on Mer sb SDK?

    1. Yes, that’s exactly the plan — if you’re referring to Scratchbox2, not Scratchbox(1). The Plasma SDK will (for some cases) be based on the Mer SDK.

Comments are closed.