kpresenter templates, foss/lc and other things

I was chatting a few days ago with Thorsten from the KOffice and KPresenter team about the KPresenter template contest. We've received a couple of entries, but we'd really like to see a lot more of them. I know there are a lot of brilliant artists out there in F/OSS-land, and this is an opportunity to get involved, get a bit of recognition and help out those who aren't as artistically gifted as you are to make stunning presentations with KOffice. The contest closes on the 15th of next month, so get your art engines revved up! :)

Speaking of revving, I'm working on what will hopefully be final drafts of my two presentations for FOSS LC's Summer Camp. One is about managing open source software projects, using the KDE meta-project as the poster child. I'll be covering things such as governance, leadership and infrastructure. I only have half an hour to do it in, so I'm sticking to the most important issues.

I'll also be giving an hour long presentation on where KDE and the Free Software desktop are going. It's one of the main presentations at the end of the day so the audience should be healthy. Always easier to draw a larger crowd when there are no other presentations to compete with? ;) I'll be covering what we're doing internally with The Pillars, what we're doing in the Workspaces (desktop, netbook, tablet, mobile, ..) and what the broader community is up to with an attempt to cover as accurately as possible the worlds of Amarok, Marble, KOffice, KDE Edu, KDE Games (will there even be a mention of Gluon? Hmm...), KDevelop, Digikam, etc. The current plan is to start out with what our over-arching goals are (a rocking community of creative people making Free Software for people everywhere on all kinds of devices with an increasing emphasis on elegance augmenting our traditional strengths such as power and integration), move to quickly cover what our foundations are built on (at a high level view), then talk about the workspaces for a while, then take people on a whirl wind tour of KDE applications. I'll be sure to emphasize the Platform / Workspaces / Apps differentiation as well the new worlds of mobile and non-laptop/desktop devices. It's always tricky to fit something like this in an hour (well, technically I have 75 minutes, but Q/A needs to be allowed for) while keeping a consistent and compelling theme while avoiding oversaturating the audience. I'm slowly getting better at it after all these years. :)

See you in Ottawa, and see your templates in the competition!

Read More

making writing documentation ... enjoyable?

Among other things, I'm a software developer. From what I understand that is supposed to make me genetically incapable of writing usage documentation without experiencing great pains in my head and various extremities .. or something along those lines. I wouldn't know, really, because I've generally run screaming from the task. I've just taken the word of my peers as to the horrors that would, in theory, await. Until this past week ...

I've been poking my head into Userbase and picking at the Plasma documentation there along with a handful of other people who have been writing content there. The revelation for me is how enjoyable it is to do this on a wiki. I spent some time thinking about why it's enjoyable, while I find the old "write it in a local file" method less so. Here are my thoughts thus far:

The wiki gives me instant feedback: I can write something and then preview it in its final form instantly. That's nice, but not as nice as seeing other people's content appear as well. Maybe I'm more teamwork driven than others (which is perhaps ironic, given how anti-team work as a student ;) but that really makes a psychological difference for me.

The discussion pages are great as they let us coordinate. Pages can be written before being linked to, allowing a nice editorial process. New pages that don't exist can be linked to from existing pages as well, giving a nice way to find something that needs doing.

The writing style is also less "describe the details of the interface" and more like a how-to book. Individual pages are topical and bite-sized. Pages can be tagged with categories like "widgets" so we can see all the (thus far) documented Plasmoids by going to the relevant category page. Tagging things with "needs improvement" or "under construction" gives us nice summary pages that work nicely as TODO lists.

I can spend five minutes making improvements or half an hour writing new content, and both are valuable additions. This is letting me "size" my contribution to my time availability. Even just re-arranging existing content into better flows is useful and, with the wiki, easy.

If you can't tell already, I'm completely sold now on the idea of using Userbase to do our user documentation, especially that now we can create offline versions of those documents. I'm looking forward to participating in and watching the continual increase in Plasma documentation and meeting new people in the process. I also understand that Anne is going to be hosting some Userbase days on IRC for people to come together and work on content together in the near-ish future, which should be a lot of fun.

Though .. yes .. I'm still a little conflicted: should I really be enjoying writing documentation? Hmm... ;)

Read More

Javascript DataEngines Get Services

DataEngines written in JavaScript can now offer Services. Sounds life changing, right? Ok, maybe not, but really, I swear it is! ;)

DataEngines publish data in a read-only pattern that allows the data to be accessed and shared by multiple consumers (or what we usually refer to as "visualizations"). The "read-only" part is a bit of an annoyance if the data being presented represents a live artifact. For instance, if a DataEngine was reporting on the network link, it might be nice to set the status of that network interface. Of if the DataEngine was publishing information about windows on screen, it might be nice to be able to say, "Hey, minimize that one." Or if the DataEngine shows information from an online service, it might be really useful to say, "By the way, here are my log in credentials for that service."

Plasma has the concept of a "Service", which does pretty much what it sounds like: it provides an interactive service that you can make calls to. What those calls do, exactly, is completely up to the Service. Service is designed around asynchronous jobs, but it can be used synchronously, something that is again up to the Service. Services, unlike DataEngines, are not shared but are used by the consumer that requests it. If 10 visualizations are using the same DataEngine, there is one copy of the data. If those 10 visualizations all request a specific Service, there are 10 services created, one for each. Such is the nature of asynchronous write operations, at least when you're trying to keep it easy to get right for people implementing the Services.

Services meet DataEngines in a really neat way: for any given source of data in a DataEngine (a network interface, a window or an online service provider, to use our earlier examples again) a visualization can request a service for that source. This done using the aptly named DataEngine::serviceForSource(const QString &source) method. (in C++ anyways; it looks very much the same in Javascript and other languages, though.)

So one can request the service for "that window" without knowing which service it is in particular. In return, you get an object complete with service description. Using that service description you can launch operations with parameters.

Obviously, it would be nice to do from a Javascript DataEngine as well. It is now possible in trunk, which will become part of KDE SC 4.6. Here's an abbreviated version of the full example (which is over twice as long as this due to explanatory comments and what not):

function startEcho()
{
    setData('echo', 'text', this.parameters['text'])
    this.result = true;
}

function setupJob(job)
{
    if (job.operationName == 'echoText') {
        job.start = startEcho
    }
}

engine.serviceForSource = function(source)
{
    if (source == 'echo') {
        var service = new Service('echo')
        service.setupJob = setupJob
        return service;
    }
}

setData('echo', 'text', 'test')

One of the really neat parts is the "new Service('echo')" bit. What does that refer to? Well, in the same package is a file under contents/services/ called 'echo.operations'. It looks like this:

<!DOCTYPE kcfg SYSTEM
    "http://www.kde.org/standards/kcfg/1.0/kcfg.xsd">
<kcfg>
  <group name="echoText">
    <entry name="text" type="string">
      <label>The text to echo.</label>
    </entry>
  </group>
</kcfg>

If you think that looks a lot like a KConfigXT file ... you'd be absolutely right. Each group in the file represents an operation, and the entries in each group the parameters for that operation. For each Service that the DataEngine wishes to offer, it includes a .operations file in contents/services. Whenever a Service is created, the name passed into the constructor (in the example above, that's 'echo') is used to identify which .operations file (e.g. 'echo.operations') to load.

Once a service is made, Jobs can be launched by the consumer based on the available operations. There are even some fun things like widget association, which makes it easier to connect things like push buttons to operations. Whenever a Job is created, the DataEngine gets a change to set it up. It does this by assigning a function to the start property of the Job. The DataEngine may also choose to reject the job by not doing so; it can also set an error code and string on it for nicer feedback. When the job is started (remember, it's all asynchronous!) the start function is called with the "this" object being the Job in question, giving the function access to properties and parameters. When the Job is completed (as per the DataEngine) then the DataEngine sets a result value which tells the consumer that the job is done and, hopefully, the result of the job.

Together with Addons and Extensions, this makes JavaScript DataEngines fairly feature complete. We already have one in development as part of a Google Summer of Code project for Plasma Media Center, and I'm looking forward a bloom of them when this hits an eventual release. While they will never replace C++ DataEngines for things like system integration, they are a great solution for online service access or other basic duty.

I'm quite interested in API feedback from others who would like to use the API: we have between now and January to get the API "right". (For whatever that means. :) I'm also still looking for an API documentation person to work with.

Read More

quick wiki experiment update

This is a quick follow-up on my post from yesterday about adding content to Userbase and Techbase.

The good news is that two people (besides myself) have started adding content to the Plasma Panels page. There's a discussion thread with three people (including me) adding to it. This is great!

I added some links in the introduction section to text that refers to specific widgts, such as the system tray and tasks widget. If you're looking for something even more focused than "Panels in Plasma" to add to, log in to Userbase and click on one (or more :) of those links and start adding content.

I've also added the {{improve|reason why}} template from Techbase, and used it on the Panels page. This in turn gives us the auto-generated Needs Improvement page thanks to the use of categories. Looks like a nice start to getting lists together. I need to discuss with Anne about adding a Category to the {{under_construction}} template so we can start building lists of new pages that are needed as well.

The Techbase task is still open and untouched, but that's understandable as it is a bit more technical and complex so the possible authorship audience is likewise smaller.

Thanks to all who have pitched in so far, and I look forward to more joining in with us. It's going to really help us understand better how to make the Wikis sustainable in the long run.

Read More

copyright assignments of the third kind

Richard Hillesley wrote an articled title "Copyright assignment - Once bitten, twice shy" that was published today. When boiled down its essence, Richard said two things in the article:

1. Forced assignment of copyright raises the barrier to participation and therefore limits the amount of participation.


2. When someone else owns rights over your work, they can do nasty things to them.

Both of these statements are true. They are also not without provisos. Richard noted that the FSF provides a promise that it will never close the software up, for instance, which makes point two a matter of diligence: if you assign your copyright to someone without anything in return, such as a guarantee of how those rights will be managed (including termination of said rights should the other party break that guarantee), then you have just made a huge mistake.

It's not all roses for projects that avoid copyright assignment, though: Richard notes the four years that the Squeak community has spent trying to get a license change through. When it comes time to defend copyrights in the legal system, it's also far more expeditious to have one entity that can represent the lion's share of rights in a project that it is to have a large number of individual (and individually supported) parties.

Unfortunately for all of us involved with Free Software, copyrights assignment is often not handled very well. Too often either too much control is given to one entity (which Richard documented quite well in his article) or nobody pays much attention at all and the project is eventually left with a mess on its hands when it comes to license management and enforcement.

There are two things, in my experience, that lead to projects not having policies in place:

• Not realizing it matters; this often happens with small projects


• Thinking that copyright assignment can't be done well, and therefore shouldn't be done at all

So, are there ways to do copyright assignment well? Yes, there are. In fact, I think KDE handles this better than most. Here's our policy in a nutshell:

• If we rely on a specific technology as a core asset (think: Qt) and the rights are owned by just one entity (think: Trolltech in the past, or Nokia today) we need a legally enforceable guarantee that it will remain open. This is the role of the FreeQt foundation, for instance.


• As a contributor, you do not need to assign your copyrights to any steering body within KDE.


• If you agree to allow KDE e.V. oversight and management of your contributions, you may voluntarily enter into a Fiduciary Licensing Agreement (a legal instrument which we were gifted by the Free Software Foundation Europe) with KDE e.V.


• If you do sign an FLA, in that same document KDE e.V. immediately returns rights back to you, so you don't really lose anything in terms of your future choices.


• KDE e.V. has a clearly documented policy as to how it is allowed to use the rights given to it in those signed FLAs

With this policy, KDE is protected, contributors who want it are protected and KDE's source code is much more easily managed and defended from a legal perspective. Those who couldn't be bothered aren't bothered, and the FLA is never used as a barrier to entry. We also are as careful with the code we use from others, ensuring it's future openness.

Now, I'm not writing this as a means to blow our own horn. I'm writing this because I am very, very concerned that copyrights (and other forms of "intellectual property") are generally handled poorly in most F/OSS projects, even large and significant ones. While at conferences, I often ask people working on F/OSS projects about their safety when it comes to working with upstream dependencies which are owned by a single entity (the "FreeQt principle") or management of their own properties. The results are pretty shocking in that there is almost never a reasonable answer to be had. Most often it is "well, we don't really have anything in place", usually followed up by "I guess we haven't really thought about it.". The rest of the time the answer is usually an overly draconian "one company owns it, we don't have any guarantees on offer to the community".

This worries me, as it puts our ecosystem at legal risk. A similar story can be written about patents, as well, but that's a different topic for another time perhaps. The good news is that we do have some groups that are emerging with good policies that work, policies that I believe we should stand up and recognize as "Best Practices" and promote across F/OSS for others to emulate. KDE is one such group, with the FLA and FreeQt foundation. Qt itself, under Nokia, is another example from the perspective of the "single owner" scenario: they have the FreeQt foundation and open governance.

"Best practice" does not mean "can not be improved", of course, but they are pretty darn good, especially relative to the status quo. We're not on our own, either: in my experience, the Free Software Foundation Europe is an impeccable resource for projects looking to implement similar practices.

It isn't an either/or situation of "control" or "safety and responsibility". You can have both and they can support each other. It just needs to be done right, and we in F/OSS need to start demanding that it is.

I'll get off my soapbox now. :)

Read More

KDE wikis want you

There were quite a few good comments on my last blog entry on how to get more people wikiing for KDE. Thank-you to everyone spent time thinking about it and providing feedback.

What I personally got out of your comments is that we need to:

• make sure potential writers know about Userbase and Techbase and how important they are


• make it clear on Userbase and Techbase that they are open to contribution by all involved, not just "the blessed few" from some mythical core KDE writing community


• provide easy-to-find lists of pages that need writing, pages that need improving and editing


• provide reviewers / writing mentors, and to make those people visible to potential authors

Some expressed that they didn't know if the wikis were used that much. Techbase is the older of the two wikis and is approximately as old as KDE 4 is. If we look at it we may find some interesting numbers, such as that there over 4,000 registered users who have made nearly 53,000 edits to the nearly 19,000 pages. The Tutorials page has been viewed nearly a quarter of a million times, with more people being sent directly to tutorials through links on the web. Total number of views on Techbase? Getting close to 19 million. Sounds useful to me. Once Userbase gains traction and we get content on there, given our user-to-developer ratio, it should put Techbase's numbers to shame. :) We really need to do a better job of raising awareness of the existence of Techbase and the fairly new Userbase as well as how critical they are to our shared success.

As for "todo lists", it should be doable with a few well maintained "open tasks, available mentors" pages as well as liberal and consistent use of templates such as {{improve|reason}}.

First, though, I'd like to run a small experiment inspired by the last two points in the list: Pointers to two pages, one on Userbase and one on Techbase, that need content can be found below. The experiment is this: does it help people get started writing? How / why?

Here are the two pages:

1. Document how to use the panels in Plasma Desktop here.
   
   There is already a start on it, but it's fairly skeletal and doesn't cover things such as moving widgets in a panel or creating new panels. What it does cover, it does so without much detail, for instance "Add Widgets" is documented as "Allows widgets to be added to the panel." Your task is to take that content as a starting point and flesh it out with more content and structure on the the new Plasma Panels page.


2. Document the new Javascript Plasma DataEngine API here.
   
   Over the last few days I've been working on Javascript DataEngines and it is rapidly reaching feature parity with what is possible in C++. It needs, however, to be documented in much same way as the Plassoid Javascript API. Thankfully the DataEngine API is much, much smaller than the Plasmoid API, and some sections can even be copy and pasted directly over from the Plasmoid API page! To work on this, you will want to have the KDE Examples module which now has two Javascript DataEngine examples in it (svn co svn://anon@svn.kde.org/home/kde/trunk/KDE/kdeexamples) as well as kdebase/runtime/ checked out from svn trunk (svn co svn://anon@svn.kde.org/home/kde/trunk/KDE/kdebase/runtime) so you can look in the source code if needed (in plasma/scriptengines/javascript/dataengine/).

I'll be watching both pages, as well as their Discussion pages, so you can start editing right away if you'd like. You can also email me (aseigo at kde dot org) or find me in #plasma on irc.freenode.net to discuss content while or before you start writing. The wording doesn't have to be perfect and we proof readers will look over it when all is said and done, so don't worry about that.

By adding content for either of the two tasks above, you will be helping untold numbers of users and developers looking for answers. You will also be making a significant and valued contribution to KDE, joining our team of software developers, graphic artists, bug wranglers and translators in helping make Plasma rock!

Read More

more plasma javascript, plasma mobile

Marco's been doing some more amazing work on Plasma Mobile. Given that its running on a device with a 2+ year old Intel mobile CPU, this is pretty cool:



Marco and I have been making progress on the Plasma Shell Design document as well, on step at a time. A lot of the information that is there is being externalized from our minds for the first time ever, and it's really long overdue. Some illustrations of things like the usage of the different quadrants of the scene for different kinds of items would be nice, but are beyond my skill to make look nice and professional. Still, progress... :)

I also did a small proof of concept yesterday, when Aaron P. came up to visit from Washington so we could give him a jumpstart on KDE development, that answered the question: is the current Javascript-based Plasma Shell Scripting powerful enough to use to write a Javascript that could be fed back in through the Plasma Shell Scripting framework and recreate the layout? Here's the result. While not complete (or overly pretty) it shows that it's possible and could be an early step towards a very easy to implement "export these parts of my Plasma Desktop/Netbook" feature.

I also ended up committing some work that allows Javascript plugins (Plasmoids, DataEngines, Runners) to have their own Javascripted plugins. The API (which is not yet documented, but will be tomorrow!) is just two simple functions: listAddons and loadAddon. To be notified of an addon being loaded (and it's main object), you register an event listener in your Javascript to the addonLoaded event. Then people can craft Plasma Packages of Javascript addons to your Javascript Plasma plugin and they get handled automagically. GHNS support will be a natural feature add to make.

What's the use case? Well, say we have a DataEngine that wants to fetch photos online. (We do, actually. :) We'd like to allow it to have multiple backends, and we'd like those written in Javascript so they can be easily written, easily shared and easily updated in case the service changes. We can define a simple set of function calls for these addons to use and implement, but we need to deal with the Javascript bindings bits. If you wrote that DataEngine in Javascript, though, you'd get those bindings for free, and only need to add your own addon API on top (also in Javascript, of course :). Voila, fully portable addons with pluggable backends.

Oh, and the Plasma KPart now supports scripting, too, to make it dead easy for apps using the KPart to define what the layout should look like. Fun.

Read More

KDE release day for 4.5.0 delayed

Today an email from the release team was sent out notifying KDE developers and packagers that the release of the next KDE software compilation, containing versions 4.5.0 of the Dev Platform, Workspaces and application modules, will be delayed by a week. In the email, Sebastian Kügler wrote:

"After discussing the amount of changes that have gone into the 4.5 branch post-RC3, the release team has decided to wait another couple of days for things to settle down and to re-tag the 4.5.0 release from branch in a bit more than an hour, at 1600 UTC. We'll push the further schedule for the 4.5 series for 1 week as well. The current plan for 4.6.x is not affected.

There was a number of last-minute changes introduced we didn't feel completely comfortable shipping. Also, delaying the release a bit gives us the chance to have zero-day packages available for more OSen than we'd have with only about 24h head-time for packagers, and will likely lead to better and more complete material for the press to be available and seeded early."

So we're delayed by a week, but the result will be a better 4.5.0 release for everyone. This means that important fixes for issues with Dolphin, Nepomuk and Plasma Desktop that did not make the original deadline will now be a part of 4.5.0. Some of these fix crashes, such as a problem in Dolphin with showing metadata, and some are more technical packaging issues such as a library from kdebase/apps/ whose .so version wasn't bumped up even though it broke binary compatibility.

As noted in the email, the 4.6 release schedule is not affected by this as we already branched off for 4.6 development a few weeks ago and those efforts have already been moving forward at a good pace.

Kudos to those who worked on the last-minute fixes, as it shows commitment to quality, and to the release team for being able to make tough decisions in a responsible manner and communicate them clearly.

Here's looking to a great 4.5.0!

Read More

how to get more people wikiing?

Today's blog entry is a simple question:

What would motivate you to contribute to KDE wikis such as Techbase or Userbase?

Within the Plasma team, developers put a fair amount of time and effort into writing tutorials, with some more taking shape on our Community wiki pages. We're about to start on content on Userbase, starting with documenting how Actitivies work from a user's point of view in the 4.5 release. Other teams within KDE are doing similarly.

While this is creating a very nice set of resources, the cost of making them is fairly high as we trade development (read: software quality improvement, feature) time for documentation time because it's the same people doing both sets of tasks. We regularly encourage people outside our core development group to contribute to this growing body of documentation, and occasionally they do. Usually .. they don't. Now, I'm used to the usual "talk to 10 people and one will actually do something" we all know and love from sales so I don't expect a very high success rate, but the success rate for documentation seems even lower than that.

Even when we seed a document with the essential information, people hesitate to add to it. When a new bit of information is discovered by someone using those tutorials, I have to urge them to add their findings to the page, and even then they often don't. I know we "all dislike writing documentation" (well, that overstates it a bit :), but I get the feeling we're doing something wrong here.

I could make guesses such as, "It isn't obvious that the wiki is something even me, as a casual third party developer, is encouraged to improve." Even then I'm not sure what would help fix that? A big "contribute, contribute!" header / footer on each page? The main landing page(s)?

So I'm looking for your feedback as to what would turn you into a contributing author. I look forward to your comments below. :)

Read More

in case you missed it ...

... lots has been going on in the Plasma worlds, including:

• We managed to get number of critical and important fixes in after RC2 for the final release of 4.5.0. These fixes have come not just from the usual suspects such as Marco or myself, but also people such as Will Stephenson, Raphael Kubo da Costa, Alex Fiestas, Rafał Miłecki, Maciej Mrozowski, Jonathan Michael Thomas, Sebastian Kugler, Ryan Rix, Giulio Camuffo,
  Jacopo De Simoi .. I love you guys and your commitment! As do our users, even if they don't know it. ;)


• a cool new runner for Debianesque systems that helps you install software you want to run but which isn't yet installed: Command Missing Runner


• tons of work on Plasma Mobile, which can not only make phone calls now but which has an innovative and common sense approach to interacting with desktop widgets even on those tiny screens. Marco is doing some amazing work, including screencasts. It's Sunday today and guess what I see on the commit logs as they roll past my screen? Yep, Marco hacking on Plasma Mobile. Commitment, baby, commitment! :)


• We have a new addition to the Plasma Desktop Scripting: you can set the desktop theme now in response to a request from a packager with Unity Linux. As usual, it's also well documented


• Lion mail is alive and kicking!


• Ryan has started writing tutorials!


• We have a new class in libplasma called PluginLoader that centralizes access to Applet, Containment, Runner and Service plugins so that applications can even add their own internal objects (plugin or not) into the mix. This is driven by the needs of Skrooge, KDevelop and Kontact.


• The mobile system tray is taking shape


• Plasma's network manager Plasmoid is getting more mobile connection UI love


• Plasma Media Center is getting QML love for at least the welcome screen; I assume QML will spread further into PMC over time as well.


• The pastebin DataEngine has morphed into the Share DataEngine thanks to Artur and become a lot more generic and, most importantly imho, scriptable so it is easy to extend and update between releases.


• Giulo's Grouping Desktop is on its way into the KDE Plasma Add-Ons package for the 4.6 release day


• ... as is Jason's dictionary runner


• Activities efforts from the Plasma and the Nepomuk side are being merged, thanks to the leadership of Ivan and Trueg. It is going to freaking rock, capturing user events such as file interaction, window usage and Plasma layouts all in one tidy package for users to ride


• I've started a "Plasmoid of the Day" thing on my identi.ca profile and I update it nearly every day. :)

That's some of what has gone down in the last few weeks. Happy happy, joy joy!

Read More

writing a plasma shell

I'm a hobbyist writer of fiction and poetry, which is to say that I write for the purpose of enjoying the pleasure the activity itself brings and for little other purpose. Sometimes I'll go back and read something I wrote some time ago, perhaps years ago, maybe even a decade or more. Sometimes when doing so a fairly odd thing will happen: I'll suddenly realize something that I was trying to say, something which was quite plainly there in what I had written, but which I was blind to at the time of writing. I've heard similar experiences from other writers, and if you are a writer you may have experienced the same thing too.

I had a similar experience with Plasma the other day. We get asked from time to time "Why Plasma?" or "What is the purpose of libplasma, exactly?". Or we get compared to other projects out there, even though there are only passing similarities. (I have yet to find another single project that approaches this problem space in the same way Plasma does; either Plasma is fairly unique or I'm just not looking hard enough. :) I have my stock answer about a scalable, repurposable interface component system with a high degree of data/visualization separation that emphasizes scripting, etc.

It ends up being an accurate description, but it's never been one that really speaks loudly to what drove the writing of libplasma or the design of Plasma itself. It's all about attributes of the system, after all, not motivations.

So let me try that now. Some of what follows will be familiar to those who have followed by writing here and elsewhere over the years, but I don't think it's probably ever come together this succinctly.

I Want To Write Workspaces

What I want to do is to be able to create a user interface that is "applet" or "widget" centric. I want to be able to design how that is presented to the user, how it fits together, how the interaction works for a given audience or device.

What I don't want to do is write all the applets/widgets myself in the process of doing that. A battery is a battery, a window list is a window list, a CPU graph is a CPU graph, a tweet is a tweet, etc. That's a hell of a lot of work just to get a new primary user interface on a device. Too much, in fact.

Plasma allows us to write a desktop, a netbook, a tablet, a mobile, a media center, a screen saver, a log-in screen and an in-app dashboard interface that can all use the same component model. We just write the workspace for them and all the details, from theming to configuration management, are handled for us.

In KDE3, Kicker had applets. They were pretty cool, but they were tied to Kicker. So SuperKaramba came along to let us do something similar (better in some ways, worse in others) on the desktop layer. It also brought a new API and we had to write a whole new set of widgets. Not the best.

Every other widget API out there tends to come with no way to build a workspace around it. Either they are tied deeply into an existing workspace presentation, or are so loosely coupled to the idea that you have to do all the work around them yourself. Plasma is the happy medium: it gives all the tools to easily make a workspace and access to it's own API as well as any other you wish to add, just as we've already done with Google Gadgets and SuperKaramba.

I Want To Write Killer Widgets / Gadgets

What I want to be able to do is sit together with a designer and a developer and put together a really cool widget that does something. I want that widget to run on my phone and my tablet and my laptop. Or maybe just my laptop. Or maybe just my tablet.

I want to let the designer do as much of the UI as possible. I want the developer to deal with the data. It all has to scale across devices. I want to be able to choose whether I use C++ or Javascript or GoogleGadget's API or ... I want to choose!

I want fancy things like animations and SVGs. I want simple things packaging and configuration handled for me. I want it all to be platform independent.

Plasma lets me quickly write widgets with a clear design and data separation that any workspace can use on any hardware platform libplasma is available on. In fact, not only can other workspaces use what I've done, but other widgets can even use my data level work!

A Toolkit That Fits Those Needs

Qt is an awesome toolkit. It is, however a general purpose toolkit. Ditto for the other libraries in kdelibs. They all lack what is needed to meet the above motivations. Plasma fills those gaps and provides a great way to write widgets and workspaces for them.

It isn't something you'd write a traditional monolithic app with (e.g. Digikam, Krita, K3B, etc), though you might use Plasma inside your app for the parts that have the aforementioned needs. It isn't meant to support the monolithic app concept on top of it, it is meant to support the componentized "app made of apps" concept. Nothing more, nothing less.

If we look around at what others are doing, whether it is companies like Apple and Microsoft or projects like Moblin or GNOME, no one is approaching it this way. Everyone is still making separate silo APIs welded into purpose-specific workspaces. I don't believe that "write a new workspace from scratch for every device on top of the generic toolkit" is a viable strategy in the new era where the device spectrum reigns supreme. In fact, I think the web itself is going to find itself one-up'd by the device spectrum reality and will experience displacement in the coming years. And I certainly can't imagine GNOME Shell running on my phone, no matter how good it would be on the desktop.

So this, then, is what I was writing when I started on the first classes in Plasma. Looking back all that was there, but I couldn't enunciate it because it was a new set of thoughts and ideas rolling around just out of reach. It is also what I see in the work of the others who have joined in on Plasma and made it more than I ever could have on my own.

I'm really excited that we're seeing the first device making companies picking up our API and building workspaces around them. It brings tears to my eyes. :)

Do You Want To Do This Too?

Would you like to do this too? I know it isn't for everyone, it's just a certain brand of odd fellows who think this is great, interesting, cool stuff. If, however, you are one of those people, libplasma is there just waiting for you to explore.

We have several ongoing projects of our own to create workspaces, with new ones such as Plasma Classroom just starting (more on that in a blog entry later in the week). But don't let what we're doing limit what you would do. Maybe you want to do something completely different. Maybe even just for yourself or a certain group of friends.

If you want to work on widgets, we have a growing number of tutorials and examples, and would welcome more if you'd like to write some.

If you want to make a new workspace ... well ... we haven't really had anything good for you. You'd have to rummage about the libplasma API, maybe read how Plasma Desktop or Netbook is stitched together. But documentation? *chortle* Well, that just won't do. So we've started a page, for now on community.kde.org until it is ready for the tutorials section on Plasma Desktop, that will document everything that goes into making a workspace shell, the way I'd always wanted to ever since picking up maintainership of Kicker all those years ago.

Questions? You can find us on irc (#plasma in irc.freenode.net) and our mailing list.

Read More