hanging out

Yesterday I mused on Google+:

I used to do a "seigo on kde" live video cast back in the day ("straight from his bedroom, heeeeeeere's aaron!" ;) with viewer interaction, and they were a lot of fun and pretty well attended.

Years have passed, and I'm considering starting up again using Google+ Hangout, though with a slightly broader scope to encompass the bigger world of things that make up the Free software user experience landscape. It'll retain a KDE perspective, but not be limited exclusively to "things KDE makes".

The response was quite good .. and so I've decided to go ahead with it. I'll be hosting the first Hangout tonight (!) at 18:00 UTC. Why the short notice? This will be something of a dry run to get the feel for "on air" Hangouts, both in terms of the production bits and the audience management. If all goes well tonight with the technical details, I"ll make this a weekly thing with a regular schedule posted and a proper announcement a day in advance to remind all you wonderful peoples.

Tonight's agenda will look like this:

• Introduction: why the hell am I doing this?
• Four dot Ten: A preview of why the upcoming 4.10 releases of KDE's Platform, Workspaces and Applications are interesting and exciting
• Onwards to Five: Reflections of the plans for Frameworks 5 and Plasma Workspaces 2 as revealed in the last week across various people's blogs
• Open source groupware: More public tenders for open source groupware are appearing, but are they "for real" .. and Kolab 3.
• The Meditation Chamber: this is where the audience will be invited to join in the conversation with (topical) topics of interest and questions to share. We'll ruminate on it together while avoiding it becoming a vapid chamber of echoes. Or so I hope :) So if you are able to show up, come with ideas for us to discuss! Compelling topics that deserve a more complete examination may even become the topic of future shows ...

The intro will be 2-3 minutes, the next 3 sections will each be under 5 minutes and the Meditation Chamber will be open ended. That's the plan, we'll see how reality pans out.

The resulting video will be posted online (one of the spiffy features of Google Hangouts) immediately after completion, and if all goes well I'll set up a permanent schedule and we'll see how far this takes us.

p.s. This is distinct from KDE Teatime in that it won't be a bunch of nice KDE people talking to each other about $STUFF but a quick set of informative (or so I hope ;) bits of news and reflections followed by viewer interaction. I enjoy watching KDE Teatime, and hope it continues entertaining me and its other viewers. :)

Read More

the real wikipedia of maps

In the wake of Google's CEO Schmidt going to North Korea on an official visit, American media has been abuzz with stories. Yesterday, CNN carried a story about how Google Maps is expanding in North Korea thanks to "a community of citizen cartographers" (that is Google's claim) allowing it work "in a similar way to Wikipedia, allowing users to add, edit and review information" (that is CNN's take on it).

Curious, I went to look at Pyongyang on Google Maps. Here is what I saw:

That's not bad. Perhaps there is indeed a community of citizen cartographers at work there, as Google claims. This got me to thinking about the crowd-sourced, Wikipedia-like map project, openstreetmap.org (or: OSM). So I decided to see what Pyongyang looked like there:

The level of detail is extremely impressive, and it only gets better as one zooms in further. You can see this for yourself at BBBike.org's Map Compare tool.

Yes, OSM does not have streetview, but using OSM via KDE's Marble mapping software I get great 2D maps complete with routing and other bells and whistles. Best of all, OSM never tells me I can't download a certain map for offline usage as Google Maps often does.

After viewing Pyongyang according to OSM, I couldn't help but feel that CNN had missed the real story here, had mistaken a corporate effort for a community one and missed out on telling the world about the real Wikipedia for maps.

Media coverage is one thing, but what would be truly news worthy, and good for humanity (which is a step up from simply doing no evil), is Google adopting OSM for its data sets. Yes, it would probably keep its advertising APIs and streetview and what-not to itself, but at least the world would be one step closer to having a shared and collaboratively maintained canonical source for maps. 

If nothing else, Google would get a much better map of Pyongyang.

Read More

Plasma.next()?

Sebastian wrote a pair of blog entries in the last week about where we are heading with Plasma in the near future. The first was an overview of the pathway to Frameworks 5 and what we're provisionally referring to as Plasma Workspaces 2. The second entry covered his work on making it possible to write widget layouts (aka Containments) in QML.

For me, the key sentence in that entry was this:

The work that is upcoming in Plasma Desktop is further bridging the gap between Plasma’s interfaces for different devices and formfactors.

 I'd like to share a little bit more about what this means long-term, and share a few more nuggets of where we are headed with the various Plasma workspaces in the process.

One Shell To Bind Them

In the early days of Plasma, the idea was to write one binary per form factor and share components between them. This would allow us to sculpt the overall interaction pattern of the shell while sharing the bulk of actual code, particularly the code that took the most effort such as network management. The shells take care of creating and managing the windows that make up the shell: panels, desktop layers, configuration dialogs and controls.

The desktop shell has around 9,300 lines of code, the netbook shell has under 3,000 and plasma-device (used in Plasma Active) has a little under 4000. Given that the rest of the Plasma code base ends up closer to a quarter million lines, this has been a pretty effective strategy.

There a couple limitations here, however. First, you need to write a shell if you want to approach a completely different type of device or interactive pattern. Experience shows that it's only 3-10 thousand lines to do so, but it would be nicer if that number was closer to zero.

Secondly, we've offered the ability for some time to switch at runtime between the Netbook and Desktop form factors. This is a little messy in that we have to stop one process and start the other. Not particularly pretty. With Plasma Active, we also started really fleshing out how much could be done if we also tweaked the settings of the window manager as well as various applications. What we'd far prefer is to be able to change the workspace layout entirely, including the bits that the shells have been doing up until now, without restarting processes and also alter other runtime settings such as changing the window decorations (or even removing them entirely in the case of Plasma Active).

We also learned in Plasma Active that we could write a rather generic shell and populate it entirely with QML. Sebastian's efforts bring those lessons deep into the core of Plasma. So in Plasma Workspaces 2, we want to provide a single shell binary with desktop, netbook, tablet and other form factors all being serviced by it. This will also give us the infrastructure to easily and elegantly switch between interaction concepts, e.g. between a mouse+keyboard-centric Desktop to a touch driven tablet experience. These transitions could be triggered by hardware events (docking, screen connected via HDMI, etc) or user configuration.

The result is that we'll share even more code between the different workspaces, be able to target new form factors even faster and produce a more consistent experience with cutting edge features.

One use case I'm personally looking forward to is plugging my laptop into the T.V. and having Plasma Desktop be replaced with Plasma Mediacenter automatically.

Plasma Framework

In coordination with the efforts to turn KDE's libraries into the highly componentized KDE Frameworks, Plasma's libraries and runtime parts are going to go into their own self-contained repository as well that follows the Frameworks policies. This means that all the components that are currently in kde-runtime will be moving into the same repository as libplasma or into kde-workspace, depending on where they best belong.

This isn't just an exercise in practicing how to use the "mv" command, however. The biggest shift here is that all the user interface bits are going QML. In libplasma2 there is no more QGraphicsView support. While DataEngines, Services, Runners and other data-centric components will continue to be written in C++, Javascript, Ruby or Python, the UI will all be done in QML. This is why we've been porting components at such a pace to QML.

In KDE Workspaces 4.11 we'll have some of the remaining big pieces in place: the window list (tasks) widget, the containments, krunner, etc. So when we make the move to libplasma2 as part of Frameworks 5, we'll be ready for the move away from QGraphicsView and into QML scene graph without hiccups for the user or our development teams. Yes, this means that the next major version of Plasma is going to be somewhat unexciting. We can't promise the fireworks of the 4.0 release, and I'm sure you're all disappointed by that news. ;)

For those who have OpenGL capable hardware and reasonable drivers, this will give them a fully hardware accelerated desktop. In such environments, we'll also have the ability to use fancy things like OpenGL shaders to achieve visual effects and usability concepts we can't do right now.

Oh, and the library is now a fraction of its previous size. More with less.

Plasma Active 5

We're hoping to make Plasma Active 4 the last release based on KDE Platform 4. This is a very important release, if only because it's going to be the version that ships on the Vivaldi tablet. However, we're also looking forward here too.

There are still variables in the equation, but our current goal is to make Plasma Active 5 a slightly longer than usual (for Plasma Active) development cycle and re-base on KDE Frameworks 5. This means Qt 5 and QML Scene Graph. It also means the possibility of using Wayland on devices. The KWin hackers have been insanely busy working on the changes needed to make this possible, doubly so since Martin was recently sponsored to work on KWin full time.

If things go according to plan, we'll be able to use the improved QML shell with libplasma2 and provide a very modern experience in terms of performance and interaction. Things like per-window transformations (important for supporting device rotation, among other things) become within our reach.

We also want to move Plasma Active's code closer to the Plasma Workspaces repositories. In fact, we'd like to create one Workspaces area on projects.kde.org under which the code in kde-workspaces, kdeplasma-addons, the left-overs from kde-runtime/plasma, networkmanagement, bluedevil and new repositories such as kscreen can all come together .. without coming together in one git repository. This will make building everything easier (if you use kdesrc-build, at least) while making it easier for us to manage the various assets.

Of course, it isn't all under the hood work.

Expanding on the Active experience

Something we've striven to do with Plasma Active is create an environment that is productive. Right out of the box you have eBook readers (and books!), office document viewers, a file manager (and even a terminal ;), data sync and much more. Combined with Activities, Plasma Active is really about getting useful things done (where you define what "useful" means) with your device.

We've been working lately on extending that from consumption to production. If you noticed, most of the items in the last paragraph were about using data: viewing, sharing, organizing. What about manipulating and creating? We really would like to make it dead simple to do things like take a photo, touch it up a bit and share it without requiring an Instagram in the way. We'd like to make it as easy to open a spreadsheet and view it as it is to create a new one.

However, in Plasma Active we've made two purposeful decisions: do not expose the hierarchical file system (unless the use case dictates that as a requirement) and do not expose details that are not relevant to the usage of the device (e.g. I care that I can open that spreadsheet, it's less important at that moment that the application is Calligra Sheets). Thus to open a spreadsheet one opens the file manager and goes to Documents, or simply searches for the document from the Launch area directly. No file system, no application launchers.

Creation should be just as straight forward. So we will be providing an interface that focuses on creating new things, just as the Files app focuses on managing existing things. In this model, you will simply tell the device that you'd like to start making a spreadsheet. Oh, and that you'd like to email it to your colleagues when your done.

Combined with an expanded Share Like Connect system and data sync services, publish and subscribe for activities and various other tweaks we have in the pipeline, 2013 will be a really great time for Plasma Active.

The Desktop too!

This will also be a time of significant upgrades to the desktop as well. The QML work is one major thing, but  Share Like Connect will also be featured in the desktop along with improved activity management and widget (Plasmoid) handling.

We have a steady stream of improvements coming starting with 4.10's QML containment support, continuing on to things like kscreen so we have a first-rate hotplug-driven and low-to-no-configuration screen management system (hopefully included with 4.11; many of us are already using it now!) and the bigger UI work that will come with the move to libplasma2 and Frameworks 5.

The desktop changes will not be very radical, but then our focus is to improve performance and expose features like Activities more effectively while also tieing into the multi-form-factor-but-one-shell idea.

Ok, we get it: you're doing lots of stuff.

I could continue to write about what we're up to right now and what that leads to next .. but I fear this is already long enough. I hope, along with Sebastian's and Marco's posts, it gives everyone a slightly clearer idea of where we're heading. We have a lot of work to do to get where we want to go, but we've already accomplished so much in the last few years that we know it is not only possible, but that we have the people who can make it happen.

Of course, one of those people could also be you. :)

Read More

Plasma Active 4

At the end of March, we will be releasing Plasma Active 4. Since Plasma Active 3, We've made improvements to the Files, eBook reader (Okular), Settings and Alarms applications along with a large number of bug fixes and performance improvements. We're also in the middle of moving to the KDE Platform 4.10 release as well as getting closer in line with other Mer based efforts, such as sharing the description files with Nemo that are used when building images for different device targets and adapting to a systemd driven user session. These two changes introduced a relatively large number of regressions that are being ironed out. In fact, we paused on the feature development and turned focus to fit and finish work before continuing on.

Marco posted a really nice blog entry on how you can help Plasma Active 4 shine. There are many small and large things yet to do, so there are tasks that should fit just about everyone. The easiest way to find these tasks is to start using Plasma Active and find what you feel is missing. One developer did exactly that, appearing on the mailing list with a KSnapshot interface written in QML. We're around most of the time online helping others find their feet and start working on the code, so don't hesitate to visit us and ask questions or share ideas. You can find us on irc.freenode.net in #active and #plasma, the active at kde.org and plasma-devel mailing lists and even in the new Google+ Plasma Active community.

Which brings me to a very nice anecdote: A couple of people have been working on bringing Plasma Active to the Nexus 7 device. I noted this on the Google+ community page and a person responded saying that if there was documentation on how to have both Android and Plasma Active on the device that would make it a lot more attractive to them. Alan Pope from Canonical showed up and shared a link to a page in the Ubuntu wiki showing how this can be done. I shared that on irc with Ruediger Gad, who jumped on Google+ to respond directly saying that they will add this to the documentation when he has a chance. At which point Bill Newton popped up saying he has dual-booting working and by that evening he had updated the wiki showing how to accomplish this. I love that kind of dynamic in the Free software world: from problem to solution in a span of a day with the help of multiple hands.

Read More

QML component API's to come together?

Just another day at the office...

The #active channel on irc.freenode.net is a place where people from a wide variety of projects that use various common bits of technology hang out. In Plasma Active we do a lot of work with Qt, QML and Mer, for instance; so we have people there from the Mer project as well as various QML focused projects.


Yesterday was therefore "just another day at the office" for us as a conversation between a Jolla (Sailfish) developer and a Canonical (Ubuntu Phone) developer about QML component API started up in the Plasma Active irc channel. Not only was everyone "Ok" with this, but consensus was that it was pretty awesome that we have a space for people to come together like this. People even said that to each other rather than let it remain silently unsaid. Contrast that with the attitude we sometimes see in development communities that discourage such "off-topic" communication between "competitors".




Well, one thing led to another and Zoltán posted an email to the Qt Components mailing list summing up the conversation and proposing we bring our APIs into better alignment. We hope to address issues of API drift between the various component sets out there. This is a pain point others have identified, such as in this recent blog post by Johan Thelin. There is much work to be done before we can even think of calling this a success, but it's the right sort of start.

And not the only fish frying...

There are also discussions underway regarding other aspects of the bigger puzzle such as common package formats and delivery strategies. We are poised, should we keep our heads straight and our feet moving, to evolve that holiest of grails in the mobile space: an open and vendor neutral application development strategy built around the commonality of QtQuick and Linux. This is our Rome, which will not be built in a day, but which can become something significant in the world if we keep our heads and follow through.

Waxing even more philosophical

I like to think that this is one result of Plasma team being focused on pragmatic goals rather than bordering-on-the-religious turf protectionism. We want to Get Stuff Done(tm), are often looking at problems in advance of others (our use of QML being a prime example) and are very interested in looking at solutions others have come up with before us (e.g. our adoption of the Maliit input system was made possible due to this).

We take the broad viewpoint that we have open technology in common with others, and the way to make the most of each of our investments is to collaborate and coordinate. This helps favor more congenial competition as we identify and expand our commonalities. It should also, in the case of QML component APIs, make a far more friendly and interesting story for developers: how much more exciting will it be to write an application that you know will work on Plasma Active, Sailfish, Ubuntu Phone ... because the components, while perhaps implemented differently behind the scenes on each platform, share some level of API consistency.

This has two effects: the audience for developers is much bigger and instead of competing for developer attention between us relative small fry, we can compete for developer attention together. That means greater opportunities for participation which will translate into more tools and toys for us as users. By finding what is already best for us as platform developers, we will make something better for us as users. That's an "us" that includes you!

I am exceptionally happy to be a part of a project and a community that can see the forest for the trees here: the cooperation for the competition. This is one of the primary value points I see in KDE as a whole, and one reason I recommend supporting KDE to others: over the years, KDE has matured into a community focused more on creating value for the user rather than protecting largely imaginary borders or, worse, creating new ones.

In economic terms we have evolved into a community of free markets and open trade (with all the competition and cooperation opportunities that comes with that) in contrast to isolationist communities which exhibit protectionism, borderline xenophobia and the propensity to create new schisms rather than bridge old ones.

Recently David E. Narváez reminded us all that "at the end of the day the time we dedicate to [KDE] directly affects the life of many others", and I simply could not agree more.

And what of Vivaldi and Make Play Live?

Progress on the Vivaldi tablet hardware suffered a major setback in the middle last year, but we've manged to put it back on the rails. I'm very happy with the progress of things and we will be sharing with the world what we've come up with once we're finished crossing all the T's and dotting the I's. I have been devoting a large amount of my time and effort into making precisely that happen along with a number of others. We are not alone in making this come to fruition and I will be sure to give credit where due when we launch the new hardware. 

The end result will be significant, not only because of the final product itself, but because this effort is being undertaken in the spirit of leading cooperation among a pool of friendly competitors. We are focused on creating open, exciting and useful technology for the world, not just a business for ourselves. We believe that those who resonate with that viewpoint will support these efforts by adding their time, energy and finances to help it go further, faster. Some will do so because they need the results it brings (e.g. vertical integrators needing broad freedom to shape their own products), others simply because they think that this is what our world needs.

Regardless of motivation, it is significantly rewarding to be a part of something that brings people together so we can all go further. It is the sort of world I wish to find myself in, the sort of world that ought to be available to us all. :)

Read More

Plasma Active: stable, devel and bleeding edge

Every so many months we roll a new Plasma Active release. We've done three big releases so far and are working on a fourth for release in the early Spring. These releases are great for people using Plasma Active on a device or for device integrators looking to make a releasable product.

If you want to stay on the leading edge, however, you can follow the devel repositories from the Open Build Service. This is fun as you get to see our work in near real-time. At least when things build, and since we're talking about an entire operating system stack for these images that doesn't always hold. The devel repositories not only include our own work, but also new work done by the Mer community. Sometimes it can get a bit chaotic.

One of the things we wanted to change was the pain and difficulty of making production quality releases in the midst of the occasional chaos. One step towards doing this has been to adopt a new policy for the plasma-mobile repository: the master branch should always be stable. There should be no point in time when a feature freeze just to get things stable for a release is necessary. Development happens in branches, these branches are merged into an integration branch for testing and when proven then they are merged into master.

This will make it a lot easier for different groups putting out products on different schedules to be able to create their own release timetable: pick your dates and whenever you decide to branch from master it should be in a good state. There is no requirement in this scenario for everyone to follow the same release "cadence".

It also means that people who wish to follow development can do so in a rather less chaotic environment. They can follow the work in master and it should always be relatively unbroken. Releasable, even. Put another way, this shift in our development workflow allows us to treat plasma-mobile as a rolling release.

If it works for the plasma-mobile repository, I want to make the same shift in all the repositories (which we have control over anyways :) that go into making KDE's Plasma Workspaces.

Of course, how do we test that integration branch I mentioned earlier? On Plasma Active we now have a repository that draws from the integration branch. So those of us who want to follow development and can live with beta quality features and the occasional annoyance can track integration on our devices. This helps prove features before merge into master.

How hard is it to use to the integration branch? Right now you have to edit some text files in /etc to set up zypper to draw from the correct repos. This isn't much fun, though and so in Plasma Active 4 (or if you grab a devel build :) you can just visit the Development page in the Settings app:

Then on the next system update you'll get the integration branch versions of things. Easy peasy.

Read More