Foreword
This is the second in a series of five daily blog entries covering the various tracks in the Plasma Active initiative. This entry covers the Contour project, which you can read more about on Eva's blog as well as Marco's. I recommend reading those entries in addition to this one.
In The Beginning...
The Plasma team has been working on the idea of "activities", which allows you to topically group related widgets, windows, documents, etc. essentially since the initial Platform 4.0 release. It is a unique feature that no other production desktop offering provides and for people who use their laptop or desktop for more than one specific thing, they can be a very compelling feature.
Sebastian Kügler explained the idea of activities in detail to Eva Brucherseifer, who is the CEO of Basyskom. She also served as President of KDE e.V. for a number of years, so she is no stranger to KDE. Eva thought about it and began to realize the potential for this idea if applied to mobile devices. She envisioned an alternative to the application centric device paradigm: a context centric interface. Activities would be the doorway through which your mobile life would be presented, organized and interacted with. Thus was born Contour.
Here's a preview of the current status of the project (and note that these are not mockups, but functioning implementations):
Our First "Active App"
The decision was made to implement this activity-centric interface using Nepomuk for storage and retrieval of data and Plasma for interaction with the results. After some initial interface and technical design work, a basic implementation was crafted to see if the concepts that looked so tantalizing on paper would transition clearly to the small screen. Thankfully for all of us, they did.
It was only natural that when we got together to start the Plasma Active initiative, Contour would become the first of what we would come to refer to as "Active Apps". These are applications which fit the goals of Plasma Active developed by teams of like-minded individuals. I'll be talking more about Active Apps and what defines them tomorrow.
Contour's role in Plasma Active is simple: it provides a unique and innovative aspect to the user experience, and will be part of the default tablet reference system. For more detailed information on the "how"s and "why"s of the design, check out Eva's and Marco's blog entries linked to in the foreword as well as this wiki page outlining the Contour vision.
Developing Contour
One thing you may notice about the Contour track in the Plasma Active milestone map is that there are a lot of "stops" along the line. In fact, there is essentially one milestone scheduled for every two weeks. A scrum style development methodology is being applied to the development of Contour and a new (pre-)release will be offered at the end of each two week cycle.
The developers have mapped out their feature and stability goals for each of these cycles. This detailed road map will be published and managed in the open as a means to guide the project through a brisk six months of development.
This is exciting for a few reasons. Not many KDE projects use such a development methodology so it's an interesting experiment to see how it meshes with our culture. If it works, we may see it spread to other projects as well.
This approach will also offer users and potential Plasma Active developers the opportunity to try out a new revision of the software every two weeks. No longer will you have to choose between building it from sources yourself or waiting months between final releases. To find out how we'll be making this process as easy as can be for you, be sure to check in on Thursday's blog entry about the operating system track.
For those who just want to watch rather than try it out first hand, the development team will be posting a progress update blog entry with each cycle.
Getting Involved
If you think the idea of a fresh interface for touch based devices that takes full advantage of Nepomuk and Plasma is a great one and you'd like to track or contribute to the Contour project, here's what to do:
- Get a device that suits Contour (I'll be making some recommendations in Thursday's blog entry) and be sure to download the bi-weekly preview releases (a how-to will appear in Thursday's blog)
- Read the content on the wiki pages for Contour
- Subscribe to the Plasma Active mailing list
- Join us on irc in #active on irc.freenode.net
- Put your imagination goggles on and buckle up! It's going to be a wild ride..
Finally, a word of "Thanks!" to Eva for the insight, commitment and support; to Sebastian Trüg for the Nepomuk ninja flips, Marco for wielding Plasma like a magician and Fania for her design expertise. They are a great bunch to spend time with and such a breath of fresh, positive air when working alongside them on a project like Contour.
9 comments:
The only thing we are missing: this as a "KDE 5" (not a proper KDE 5 but you get me) shell.
Keep up the good work, and please, can you backport kdeplasma-addons to the stable branch (I've running kdeplasma-addons from git with SC 4.6 with no issues, apart from some plasmoids not compiling)
?
"can you backport kdeplasma-addons to the stable branch"
new features, string changes and larger changes that require additional testing can not be backported to the stable branch, unfortunately.
Is there any hope for running this stuff on android system (i.e. using an android kernel, bionic libc, & the android graphics stack) in the future? It seems to me that this kind of hardware is going to be flooding the marketplace in the coming year and being able to use this stuff instead of the traditional android ux would be a very desirable thing for a lot of people.
Along the lines of what Alejandro Nova said and given that recently two articles appeared on Planet KDE talking about a hypothetical KDE 5, would it be reasonable that Plasma Active could work as a test bed for the next iteration of the software compilation?
I know the status of the graphics stack in the desktop is the main impediment to generalized QML use but as in Gnome 3 compositing is mandatory, in an ideal world that could force an improvement of the current situation. If/when that occurs, do you think Plasma could use QML in all supported devices (including the desktop)? Would it make sense to port existing and new KDE applications to QML for its GUI?
I also hava another question. Would a QML Plasma shell work on a software Open GL implementation? Could that be used as a fallback on the desktop? Sorry if this is a bit off-topic.
Anyway, I'm really excited with this project not only for what it entails but also for it's great to see such a concerted effort going forward. I'm glad that KDE, as a community, can achieve that. Keep up the good work!
@yokem55: "Is there any hope for running this stuff on android system"
in theory, yes.
what is needed are people who wish to do the work of supporting the Android build. such an effort would become part of (and extend) the OS track (which i'll blog about on thursday).
anyone who wishes to get their hands dirty with this particular task: you know where to find us :)
@Naproxeno: "recently two articles appeared on Planet KDE talking about a hypothetical KDE 5, would it be reasonable that Plasma Active could work as a test bed for the next iteration of the software compilation"
i do think that Plasma Active can serve as a test bed for new approaches and perhaps even a role model for other KDE projects faced with similar needs and goals. we can do this within the framework of KDE4, however; there is no need (or desire) for a "KDE 5" at this point.
"I know the status of the graphics stack in the desktop is the main impediment to generalized QML use"
not really, no. you can use QML on QGraphicsView just fine. we already do that, in fact. in that case, it's rendered just as it always has been with no had dependency on OpenGL.
the two big things that prevents general QML use are available resources to do all the porting and rewriting of existing code and limitations in QML that don't make it applicable to every single use case (yet? :)
"but as in Gnome 3 compositing is mandatory, in an ideal world that could force an improvement of the current situation."
things have improved for many use cases in the last couple of years due to applications such as Plasma pushing the envelope. having GNOME join in here can only help. however, i'm not particularly holding my breath for it to happen in the short term :)
"If/when that occurs, do you think Plasma could use QML in all supported devices (including the desktop)?"
actually, we recommend using QML for all supported devices, including the desktop, when writing Plasmoids today.
we need more documentation on it, and that is coming. but there is no reason not to use QML for things in plasma-desktop. in fact, there are several reasons to do so, such as it being easier to achieve sophisticated visual results and being able to share the implementation on devices where QML will be a stronger requirement.
"Would a QML Plasma shell work on a software Open GL implementation?"
yes, but probably not very fast compared to a full OpenGL implementation. ;) this is similar to what we're doing now with the rendering being on the CPU.
"Anyway, I'm really excited with this project not only for what it entails but also for it's great to see such a concerted effort going forward."
we're excited too, and for the same reasons you noted :)
"I'm glad that KDE, as a community, can achieve that. Keep up the good work! "
thanks for the kind words, we'll continue to do our best.
Great stuff, this is looking really exciting! Congrats to Aaron and everyone else, I'll definitely be following keenly along.
Also love your way of presenting it bit by bit, its a great launch sequence and brilliant marketing. Keep it up and you'll definitely get a lot more exposure for the project, and KDE in general as results start becoming increasingly tangible to the end user =)
Just wanted to echo I love the idea of getting this going on Android, if installing the KDE tablet UI could become feasible on an Android tablet you guys could start providing a serious alternative to honeycomb and a great avenue for device makers to differentiate themselves. Exciting stuff ahead, keep it up!
For some reason this post got me thinking about version numbers. Using KDE 3 as an example, KDE 3.0 is the first release and KDE 3.x is the name of the series. I think KDE 3 should then be the last release (3.5), which is the "ideal form" of the 3.x series, or at least closest to being it. This way the integer values would refer to "finished products", while floating-point values would refer to stuff that's "in development". This wouldn't change anything except for the labeling of one release per series, and it would make sense to offer a direct upgrade from one integer release to the next.
Post a Comment