the pulse

December is almost always a hard month for me. Besides the seasonal brinkmanship with depression that I struggle with as the days dwindle away (something I liked a bit better about living closer to the equator in the past was not having to deal with that) it often seems to come with its own stew of drama. Some years are decidedly harder than others, and thankfully this one is somewhere in the middle of the pack. I'm looking forward to spending the holidays at my sister's (for the first time ever we'll get to do the Christmas thing together!) and things are looking like they are all coming together .. but the spill and slop of December can be seen as my schedules get routinely disrupted (excuse the irony / puns ;) and I fail to do the usual like keeping up with my blog. Mea culpa.

Much has been afoot, however.

Netbook World Summit

This was a bit smaller than I'd expected, but it was very useful to be there along with Frank Karlitscheck (opendesktop.org, KDE e.V. board member). We were able to meet with some hardware manufacturer and OSVs as well as rub shoulders with the world of bloggers. Hopefully we'll be able to develop these relationships further over the coming months and years. It was a great opportunity to also reconnect with the people at Mandriva and deepen our relationship with them. Getting feedback from the trenches and offering some insights into where we're going is always helpful. We also got a Slashdot story about netbooks out of it. Combined with it being in Paris (a lovely city if you are in the right parts, and we were), I'm happy with how it turned out. Hopefully next year's version of this event will be larger and more diverse.

In the "downsides" category, it meant I had to cancel attending FUDCon in Toronto. There are some events I keep trying to get back to but my schedule has been a little insane over the last two years and with the growing number of quality regional events, it's getting harder and harder to get to enough of them. (I had to pull from SCALE 2010 because of a conflict as well. *sigh*) This is why KDE needs you: with more of us out there, we can cover more of these events and shine our blue light on the world around us a bit brighter.

Speaking of netbooks...

Some people have suggested that the rise of Plasma Netbook might mean we aren't paying much attention to Plasma Desktop now. That's a valid concern, so let's talk about it.

Plasma is designed to allow applications, particularly "primary user interface" apps (those things that you see when you turn on a machine before you start launching applications), that should share code to do just that. This means that Plasma Netbook and Plasma Desktop share a huge amount of code. In fact, Plasma Netbook wouldn't have been so achievable without this approach as we were able to take the efforts put into Plasma Desktop and use them in Plasma Netbook. We've only crafted the new parts we needed.

The reverse also works. When we've done something good in Plasma Netbook that isn't specific to netbooks, it shows up in Plasma Desktop. I expect this virtual cycle to repeat itself with Plasma Mobile, which has recently taken bud in playground.

Finally, while we have put a fair amount of effort into Plasma Netbook, we are still committed to the traditional desktop as well. It's a huge percentage of our real world use scenarios, and that isn't going to change anytime soon. We've tasked more effort than would likely be usual on Plasma Netbook this release cycle because it is new (and so needs that initial "get it up and going" effort) and we ought to have something that can track the success of netbooks in the market where they are represent 20-50% of the laptop market depending on the region in the world one looks at.

JavaScript Plasmoids

One of the other hot topics for the 4.4 release of the KDE Workspaces has been the use of JavaScript. With 4.4, you can define the defaults for a Plasma Desktop layout using JavaScript as well as change the layout of a Plasma Desktop session at runtime either interactively or via scripts that get run at startup. (There is documentation here, but we really should have an article based on that in the Techbase Sys Admin section; anyone up for writing that?)

We also have the JavaScript option for Plasmoids, with the API documentation getting rather extensive. There are a few things I'd like to add to the API for 4.5 (in particular: Extenders, improved configuration UI control and writing data to local files and the network) but for 4.4 we already have more than enough to make the API useful to write nice Plasmoids. That includes:

• Plasmafied User Interface Elements: BusyWidget, CheckBox, ComboBox, FlashingLabel, Frame, GroupBox IconWidget, ItemBackground, Label, LineEdit, Meter, PushButton, RadioButton, ScrollWidget, ScrollBar, Separator, SignalPlotter, Slider, SpinBox, SvgWidget, TabBar, TextEdit, ToolButton, TreeView, VideoWidget, WebView


• Layouts: Linear, grid and anchor layouts for UI elements


• Painting: drawing lines, boxes, text, etc. ala QPainter


• Packaged Files: easy access to packaged files, e.g. for images it's as simple as "new Svg('filename')" or "new Pixmap('filename.png')"


• Local file and network data access (security controlled)


• Configuration read/write


• Images: Pixmaps in memory or on disk (in the Plasmoid's package or part of a theme), PNG, JPEG and SVG


• DataEngines and Services: This provides access to a huge array of information and interaction with that information. Windowing, time, system information, weather, microblogging, dictionaries, networking, geolocation, files, email and contacts, power management, rss, remember the milk, places, hotplug, chemistry data ... the list is getting really long, which is great news for widget writers as it means access to all kinds of great stuff without anyone having to write more bindings!


• Plasma::[Popup]Applet: lots of great API is available directly in the "plasmoid" object, and in 4.4 it also supports PopupApplet too!


• Animations: a variety of stock animations to make things look great

This has all been made rather easy to achieve thanks to Qt and KDE's development platform. The whole set of bindings that makes the above possible is just a bit over 5,000 lines of code.

What we need now is people building kdelibs/plasma/ and kdebase/runtime/plasma/ from svn trunk and writing JavaScript plasmoids with them. Our own set of examples is slowly growing but to find all the annoyances and issues we need your help. The good news is that this kind of helping can be a lot of fun: it's ludicrously fast to write Plasmoids using JavaScript and the gratification is nearly instant: edit and run plasmoidviewer right from the same directory! (Or, for the even slightly more adventurous, use Plasmate for an all-in-one GUI experience.)

While development will contine, I don't think we'll be adding too much more to these particular bindings. They are meant to stay relatively simple (while featureful) and suitable for sandboxing. For a more "everything and the kitchen sink" approach, we'll be relying on the JSmoke bindings which bring all of Qt and KDE's libraries into QScript. The current JavaScript Plasmoids for 4.4 are already capable of sucking in these QScript extensions, in fact!

More Plasma

Plasma continues to blaze trails elsewhere as well. There are the stock animations that come with the Plasma library which allow us to bring even more tasteful and consistent effects to Plasma applications makes us one of the first adopters of Qt Kinetic. The animations included in the Plasma library, accessed via the Plasma::Animator::create factory, can be freely mixed with Qt Kinetic, of course, and the blog linked to above has a really nice video of them in action.

Our new DBus system tray protocol is being picked up by Canonical and implemented in GNOME 2 (don't know what will happen in GNOME 3 yet). Canonical will be contributing a menu serialization system to the spec that will allow us to scratch off our biggest "v2" TODOs for the spec: making the menu rendered client-side. This means that the menu will be in complete control of the visualization, allowing it to be put in submenus (think of the task bar integration possibilities!) as well as just plain themed properly. Canonical will be using it to create a slight different take on the system tray, one that is simpler and offers a single-menu-to-icon paradigm. The beauty is that this wasn't specifically what we had in mind when designing the spec, showing the power of "data divorced from visualization" type designs. The old XEmbed based system simply could never do this ... which is why we broke new ground in the first place. :) Once it is implemented in GNOME, we will be working on turning the freedesktop.org proposal into a freedesktop.org spec.

Branding

The KDE branding efforts are also going very well with people really understanding the ideas on a deep level. That's so great to see! By increasing the accuracy of the phrases and words we use, we are able to more accurately describe what we are doing: creating a development platform, a set of workspaces and a ton of amazing applications. These are parallel and complementary activities, but they aren't conjoined. Communicating that, something we utterly failed at in the past, is the entire point of this exercise.

For those who think the primary emphasis is in any way on the "KDE is us" thing are completely missing the point. It is great that we recognize the community and our part in making KDE. It is vital that we create a shared set of ideals and goals to work towards in our own and individual ways (so that we end up somewhere coherent despite those efforts being not mandated from the top-down). However, the original purpose behind the branding effort was to clarify the positioning of our products (as in "the things we produce", not in the corporate sense of the word) in relation to each other with the applications and development platform being separate yet peers with the desktop environment (which in turn is augmented by other workspaces, such as Plasma Netbook). The community building exercise is a great freebie, but nothing more.

Git

The movement towards getting KDE hosted on gitorious.org is also going ahead nicely on all fronts thanks to weekly meetings by those involved. It's not an easy process, and there are some moments of over eagerness to be seen from time time. In general it's going well, however. Logistic issues such as SLA agreements and technical issues such as pre/post commit hooks are being addressed in a thorough manner. The KDE and Git tutorials on Techbase need more love, though. Find chani on irc.freenode.net if you'd like to help out there.

Most important to me is that while we move towards git, we don't lose the best things about our workflow around svn while gaining the power and benefits git provides (such as sensible branch merging and offline usage). Those benefits would be centralized work and a low barrier to entry. We will still have one mainline that everyone in KDE can commit to and that all our downstream packagers can reference as "the KDE source code". We will keep the workflow simple and well documented, even if git would allow us to do crazy insane things that only vcs geniuses can follow, to keep that bar low. Where necessary, we will also make exceptions, such as keeping translations in svn until the translation community is ready to follow on their own timeline.

Overall?

KDE 4.4 betas are rolling now and overall I'm pretty juiced about how things are going in KDE land. Things are positive, we're hitting strength after strength and the KDE 4 series, from the development platform to the workspaces to the various apps, is increasingly making its mark as the set of desktop and mobile technologies to beat in terms of openness, features and pure rockitude. (Whatever rockitude is ... ;)

And overall I need to update my blog more often so I don't end up writing these massive pieces every week or two. *sigh*

Happy holidays everyone! :)

Read More

netbooking it

It's been another insane week of activity for me, but fortunately it's also meant having a lot to show for it. As one example, we put the Plasma animation hooks through one more API review and we're pretty happy with the shape of it now. I have some work to do in the JavaScript Plasmoid engine to reflect some of these changes, and that's a good example of how activity often causes even more work for us. ;)

Today, however, I'm in Paris attending the Netbook World Summit. I'll be taking part in a panel presentation this afternoon, but the most important thing for KDE here is the human networking opportunities. I've been joined by Frank Karlitschek to represent KDE here, and it's great to have an extra pair of hands, ears and eyes so we can get the most out of this event.

Frank and I also had a very good set of discussions yesterday over dinner and drinks about challenges and opportunities KDE and KDE e.V. are faced with, ranging from the git migration to distribution relationship issues.

This morning I was pleasantly surprised to see the KDE logo on the partner's banners here at the event and breakfast with the Mandriva people was very productive. I also met with some eBook people and talked about the current and future state of eBook readers, files and services and how we could take advantage of these things in KDE and in particular Okular. So we're off to a great start here already and I have great hope for what we can achieve before tomorrow when I turn around and go back home.

Read More

general audience vs advanced audience

Reading Cyrille's blog entry today about Krita and GIMP appropriateness (or rather, how they are not appropriate) for a default OS installation, it got me to thinking about a common pattern we see emerge in applications.

We often end up with general audience apps that represent a good entry level position. They aren't wimps, but they certainly remain lean and the UI stays focused on what they are doing in a way that's approprirate for a general audience. They may make most people happy, particularly because the interface is nice and clean while offering the "things I want most", but they usually leave a more demanding user wanting, particularly people who are professionals in the field in question.

The professionals and enthusiasts will be looking for richer tools that Do More(tm) and often support more sophisticated models. These tools could be viewed as "upgrades" from the general audience applications except that for many people in the general audience these pro tools are vast overkill and even off putting.

The pro tools can't really be streamlined beyond a certain point without losing their audience, and the general audience tools can't be beefed up constantly without leaving behind their audience. Perhaps there is even a symbiotic relationship at play here, at least within the KDE world: the pro tools push the envelope of what's possible in ways that the general audience tools can add selections of features that straddle the general/pro audience but which are complicated to do and so more likely to show up in a pro tool in the first place; the general audience tools take the pressure off the pro tools from having to cater to too broad an audience, and the pro tools take the pressure off the general audience tools from the demands of demanding users.

(As an aside, for all the claims that one can simply have a UI adapt to the user's level of capability has never really been shown to be a real solution. I've seen it fail before, and where it has succeeded it's been for apps that themselves straddle between "general" and "advanced" in audience. Usually it just leaves a mess, and even more usually the suggestion that this is the solution comes from people who have never tried it. Aaaaanyways ..... ;)

The example of Gwenview, Digikam and Krita is a great one, I think.

With Gwenview, you get basic photo downloading from cameras and image manipulation. These "high end" (for Gwenview) features mostly comes from work laid down by the people working on the higher end photo management tools like (though not exclusively) Digikam. Sometimes feature improvements flow from the general audience app into the advanced tool app as well, but in my experience such improvements tend to be of the general audience pleasing type (as one might expect).

Meanwhile, Digikam can concentrate on being a great power tool for photographers, amateur and professional alike and Krita can concentrate on being a great power tool for artists, amateur and professional alike.

The result is a great set of apps for different audiences which help each other improve as they individually advance to better serving their specific target audience. What duplication of effort does exist is offset ten-fold by the resulting benefits for the users of each app in having something targeted to their needs. In KDE, that duplication is often very minimal.

There are other examples of this in KDE as well and they often follow very similar patterns. We have JuK and Amarok; KWrite, Kate and KDevelop; Dolphin and Konqueror ... can you think of some more?

Also, is there a pattern here that we can use when presenting our application clusters to the public?

Read More

some krunner updates

KRunner continues to grow into a really great tool to quickly get things done using words. It was intended to be something more flexible than the Run Command dialog in KDE3 that also looked nicer. I think we've achieved both of those things, and KRunner blends sexily into the rest of the Plasma Desktop. It runs asf its own process to allow some separation between the desktop and panels and the command dialog, which is also a bit different from KDE3 where it was part of the desktop itself.

I wasn't looking to create a specific work flow, per se, other than "type something in, get some results, pick one". Other projects try and create a very specific work flow (quicksilver being the grand daddy of them all), I opted for the Google-ish "a search line with results". There are strengths and challenges to both approaches, but I like the choice made in KRunner for general consumption purposes. Once can switch to a more work-flow defining mode in the configuration, however, by selecting the "Task oriented" user interface.

Since it's debut in the KDE SC4.0, KRunner has gotten a lot prettier, a lot faster, a lot more featureful and a lot more stable. It's a fairly healthy project in that regard. It's a multithreaded app that favours responsiveness, best seen in the as-you-type results, over CPU cycles (so there can be plugins running old queries that are no longer useful; KRunner just moves on instead of waiting for the to finish). The result is still very usable on low powered machines.

In KDE SC 4.4, the Runners (as KRunner's plugins are known) also power Kickoff's search and Plasma Netbook's Search and Launch activity page. Other apps can just as easily use them by linking to libplasma and using Plasma::RunnerManager.

Also new in 4.4 are support for actions-on-results in the default interface (the task oriented interface already had support for them in 4.3). They appear as little buttons attached to the respective entry, just like the configure button does. This feature uses the base work done by Ryan with Jacopo doing the UI integration into the default interace.

Jocopo's done a lot of other nice work for the 4.4 release as well, including "single runner mode" which allows a Runner to advertise that it's useful "all on its own". When it does so, with X-Plasma-SingleRunnerQueryMode in the .desktop file, one can launch KRunner with just that one runner active and an empty query box becomes synonymous with the default syntax the runner registers. Queries then get passed to just that one Runner, it's icon and name is shown in the user inteface to make this clear, and you can even set a global keyboard shortcut to bring up KRunner with a specific Runner in single runner mode. This is a really nice usage of the RunnerSyntax feature introduced in 4.3 for online help; in the apidox it is noted that RunnerSyntax might be used in the future to enable features that require knowing what a Runner is capable of, and with 4.4 we have the first application of that. Very cool.

There's also the new visual positioning of the KRunner window. While you can configure it to go back to the traditional "window floating in the middle of the screen" it now appears "glued" to the top of the screen. It plays well with top edge panels as well as applications like Yakuake (there's one top edge panel issue I still need to address before 4.4.0 is released, but there are a few months left for that to happen :), and you can move it by clicking and dragging inside the window or resize by clicking and dragging on an edge. When it's pushed into a corner, it removes the appropriate border of the window so it looks nice in such cases. The size and position are also stored and retrieved between sessions, and if you want to get it back to the center after messing around with it there's a "snap zone" in the center.

I have to admit it took me a day or two to get used to it popping out of the top of my screen after years of Alt+F2 causing a dialog to show up in the middle of my screen. With the adjustment period over (and it was quicker than I thought it might be), it feels so much more natural and is much more convenient when using KRunner to do things like unit conversions when reading a document, for instance, as the KRunner window now is now out of the way of the window. Pressing Alt-F2 a second time makes the window disappear when it is edge mounted, as well, which supports this kind of quick "check something" workflow nicely.

What isn't there is the ability to drag it to screen edges other than the top; that's probably something for 4.5. In fact, I'd like to get rid of the configuration option altogether for 4.5 and make it so that if you click-and-drag to move it and go more than X pixels from the screen edge it just pops off, and if you push it back up against a screen edge it just pops onto it. I just didn't have time to do this for 4.4; I was more concerned about getting the edge docking working nicely first. Next we can get fancy. :)

Speaking of fancy, the configuration is now embedded into the KRunner window. Dialogs-on-dialogs just sucks from a visual design perspective. There's one visual annoyance there right now, however, which I will fix for 4.4.0: the KRunner window should grow when the configuration is shown to give more room for it. The default size needed by it and a reasonable size for results is rather different. Separate windows sizes for each already works, I just need to make it automatically do this.

Of course, all this is nice and all but the real usefulness comes from what the Runner plugins themselves can offer. In addition to the usual stability, performance and feature improvements in KRunner itself, we've added some new Runners and improved on some of the existing ones. In the KDE Software Compilation v4.4 we will be shipping the following plugins for KRunner:

• KDE Workspace
  
  
  
  • Bookmarks: supports both KDE's and Firefox's bookmarks in 4.4, depending on the default browser setting
  
  
  • Calculator: still not as strong as I'd like; there were efforts to make it use libqalculate optionally (falling back to QtScript as the evaluator as it currently does), but nobody was able to confirm the thread safety of libqalculate
  
  
  • Kill: kill -9 from KRunner! New in 4.4.
  
  
  • Locations: network addresses, with some nice frills like automatically adding ftp or http depending on the domain name if a protocol wasn't provided
  
  
  • Nepomuk Search: aka "Desktop Search" in the user interface, does what you'd expect
  
  
  • Places - the places model known from Dolphin, the file dialog and kickoff, among other places (excuse the pun)
  
  
  • Powerdevil: desktop style power management from a command line! :) This includes the ability to hibernate or sleep.
  
  
  • Recent Documents
  
  
  • Services: aka "Applications" in the user interface, it's what launches applications and plugins like control panels that are registered with the system using a .desktop file (same thing that populates the app launcher menus)
  
  
  • Sessions: start new sessions, switch to existing ones, logout, shutdown and reboot
  
  
  • Shell: launch shell commands, including the ability to do things like "run as different user" or "launch in a terminal window"
  
  
  • Solid: Another new addition for 4.4, it lists storage devices allowing one to do what they might from the device notifier plasmoid in KRunner. What's really cool is that it uses the same Plasma::DataEngines as the widget, so code duplication is virtually non-existent.
  
  
  • Web Shortcuts: access all those funky "gg:", "qt:", etc. shortcuts you know and love from Konqueror; as an added bonus, it opens the URL in your default web browser .. which means they now work in Aurora, Rekonq, Firefox, whatever as long as you type it into KRunner
  
  
  • Windows: New in 4.4, this lets you switch between and manages virtual desktops and windows from KRunner's windows.
  
  


• Plasma Desktop




• Plasma Desktop Control: New in 4.4, it's the easy way to open the scripting console in plasma-desktop: desktop console




• Plasma Addons




• Audio Player Control: control any MPRIS enabled media player, which is most of the F/OSS ones. Defaults to looking for Amarok but can be configured to use different players. New in 4.4; it would be nice to see the need to configure it for the non-Amarok case removed or at least mitigated, though.


• Browser History: Return to where you've been in your browser history; speaking of which, I heard that rekonq has been using runenrs as well? If so, neat.


• Contacts: Search through your contacts and email them. Once Akonadi is in greater use (looks like contacts are there for 4.4) this should really be transitioned to use Akonadi; that will make this one a lot less of a performance hog.


• Converter: Convert units and currencies. Did you know that one carat is 0.0002 killograms? :) This uses libkunitconversion which joins KDE's Development Platform in kdelibs for 4.4


• Kate Sessions: Launch Kate sessions


• Konqueror Sessions: Launch Konqueror sessions


• Konsole Sessions: Launch Konsole sessions (a bit anti-climactic by now ;)


• Kopete: Control Kopete if it is running; go online and offline, set status messages, etc. It has code to do contact interaction, but right now Kopete's D-Bus interface isn't very amenable to this as it requires sending all the information over the wire to KRunner; so this support isn't compiled in by default for 4.4. When Kopete 2.0 comes out, we should be able to provide access to individual contact interaction features without penalty.


• Mediawiki: New in 4.4, Query mediawiki wikis. Adding a new wiki is just a .desktop file away, and we whip ones for Wikipedia, Wiki Travel, Techbase and Userbase, each appearing as a separate plugin in the configuration dialog even though they use the same plugin. That neat feature is available to any runner that would wish to do the same thanks to a clever little patch by Sebas.


• Spell Checker: Check your spelling quickly: alt+f2, spell <word>

Many more are possible, and some others are available on kde-apps.org. They can be written in C++, Python, Ruby or JavaScript (with limited functionality; I haven't yet gotten to fully expanding the JS bindings for Runners) and it would be great to see even more.

If you'd like to write one, be sure to visit the Creating Runners (C++) tutorial and find us on plasma-devel@kde.org.

Read More

Is it cold in here, or is just me?

Tomorrow the 25th (or, today the 25th, depending on when and where you are reading this ;) is when the feature and message freeze happens for the KDE Software Compilation v4.4. To quote from the schedule:

"Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.
[...]
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways)."

That means that if you haven't got a feature ready for merging yet, it's 4.5 material. If you have things in the kdereview module, please either move them to their final destination for 4.4, into extragear or back into playground. If you move something back to playground, you can move it back into kdereview when 4.5 opens up.

I spent the day clearing out the Plasma area of kdereview (there is one item left, it will probably move either into extragear or playground tomorrow), but there is still quite a list of items in there, including:

• controlflowgraph


• device-automounter


• ktimechooser


• networkmanagement


• polkit-qt-1


• solid-sysclass


• nepomuk-activities-service


• PolicyKit-kde


• guiplatformplugin_kde

If any of the above are your babies, please ensure they get dealt with quickly so I don't have to bug you about it. :)

Onwards to 4.4, and the feature completion, polishing and bug hunting season! Woo! :)

Read More

Istanbul was once Constantinople

I used to love the They Might Be Giants. In fact, I still harbor a soft spot for their whacky music. I think this is now the second time I've used that song for a blog entry title, and certainly not the second time I've made passing reference to them. However, this is not about them. It's about us. Who? KDE.

In case you've missed it, the 'K Desktop Environment' (which at one graciously brief moment of time was the 'Kool Desktop Environment') is now just 'KDE'. You can read more about how the KDE brand is being repositioned on TheDot, where the overall idea is explained with some detail.

To boil it down to bullet points:

• KDE is us, the people and the organization we form which produces these wonderful artifacts which are shared with all humanity. This highlights the community behind the success quite clearly and elevates 'KDE' to be a shared umbrella, owned equally by all involved.



• 'KDE' no longer refers to one specific piece of software as we have too many projects covering too many topics for that to work without huge confusion. "KDE releases KDE KDE version 4.4" was the old joke in the KDE promo team. Instead, each product or product grouping gets its own brand that stands next to the KDE umbrella brand.



• In one of the more important changes that occurs as a result, the "KDE desktop" is now the "Plasma Desktop" which is accompanied by the "Plasma Netbook" (and eventually "Plasma Mobile", something new-ish people are working on). It's still KDE's Plasma Desktop, and it contains not just the plasma-desktop binary but all the bits and pieces that make up the workspace. KWin, KSysGuard, KRunner, etc. are all part of the workspaces; you can find most of the components in the kdebase-workspace module. Why? Well ...



• This liberates our development libraries from the KDE workspaces. One can use Solid without requiring other pieces of software we create, or forcing your users to use a KDE workspace. That was not clear to many people in the past. Hopefully it will become clear as we take this new communication strategy on.



• This also liberates the individual applications from the KDE workspaces. It can now be clearer than ever that, yes, Amarok does run in XFCE very nicely and that, yes, Digikam does run on Windows. They are KDE software, but 'KDE software' is no longer synonymous with 'desktop'.



• Our epochal releases, such as the upcoming 4.3.4 and 4.4.0 releases, which contain our 'basic packages' providing an application platform, workspaces and many applications, are referred to as the 'KDE Software Compilation'. So it will be KDE SC 4.4.0, for instance. This is not however a brand. It is a common noun that we can use to talk about the epochal releases. It will not be marketed but it will allow us to talk to each other about our release engineering without perpetuating the confusion that "KDE is that exact bunch of stuff over there, meaning that other KDE software requires all the parts of that KDE thing".

It's not really a huge shift. We've kept the names that exist while moving some of them around a bit to make things that are clear to us internally clearer to those on the outside looking in. In fact, you can see some of these ideas already evident in official public communication over the last year or two. We've been actively discussing, designing and working towards implementation of these concepts since a little before the 4.0 release and so some of the ideas were put into practice sooner rather than later. Now is the time to draw up in a solid line, though, and implement it fully.

This is where we all come in as individuals. There is work to be done, from the About KDE dialog (which is already done, actually) to reworking our business cards to reshaping the language and layout of our websites. The work is being coordinated on the kde-promo@kde.org mailing list.

Just as important as that work is how we each carry the message of 'KDE' out into the public. We are each ambassadors of our community and that community's efforts to the world beyond. That world might be our friends and family, it may be our school or place of employment, it maybe a local technology enthusiast group, it may be the press. Wherever we go, we need to each try and communicate as clearly as we can what KDE is and avoid communicating what KDE isn't.

It will take quite a while before the message is fully realized and everyone takes for granted that 'KDE' is that awesome bunch of people who create that kick-ass software that's used all over the place. It will take consistent application of the brand names and, most importantly, the ideas behind them, over a period of time. This is the most important way each of us can help make the re-branding a success.

Which of course begs the question: what would success be? What exactly is the point? The goal is to help people understand what we're doing with enough clarity that they will be able to appreciate it as much as we do. As one person on TheDot commented, "I've always experienced KDE as a community"; that's very true for my own experience as well, and I'm sure for many of you it's been the same. It's time the whole world understood that idea, that feeling, that experience.

Maybe then they'll take another look at that one bit of KDE software that they were always interested in but stayed away from because they didn't want to get locked into using the "whole KDE catalog". Maybe they'll even discover new things to love that they didn't know we did, together, as KDE.

Read More

Javascript plasmoids

The other day I met with a couple of local entrepreneurs whom Chani had met at the recent Qt Dev Days in California. The four of us gathered around some tasty vegetarian vittles and discussed small devices, Qt and Plasma. It was a good time and we found a lot of common ground .. including agreeing that Javascript is a great language for writing little user interface elements quickly that will run reliably.

In that vein, I've been working on getting the Simplified Javascript API for writing Plasmoids ready for creating more than just toys. To that end, all the Plasma user interface elements (pushbuttons, etc) are available including the complex ones like the TabBar, Animations are fully supported, we have AnchorLayouts (and maybe even GridLayouts soon) in addition to LinearLayouts and, perhaps most exciting, we now have the ability to load API extensions.

An API extension is a security controlled set of functions and objects that are loaded on demand. These extensions are requested by the widget by listing the required and/or the optional extensions it wants loaded in its metadata.desktop file. This way, even prior to the widget being loaded we can know what it will want. The Simplified Javascript Engine then decides if the widget will actually get that extension or not.

There are a set of built-in extensions currently defined: FileDialog, LocalIO, NetworkIO, HTTP and LaunchApp. They each do what you expect, with NetworkIO being a generalization of HTTP. I'm busy implementing each of them between now and the end of next week. We aren't limited to these built-ins, however: any QScriptEngine extension plugin can be loaded, security willing, just by listing it in the metadata.desktop file. This means that widgets can be extended with arbitrary functionality.

The security framework is still in development, but all the hooks are there with some of the pieces in place now. Most importantly, we know exactly how we want to implement the missing bits. I'll be working on filling in the gaps as I can, and hopefully when Rob returns with hacking time again (or someone else steps up in the meantime) that will go a bit faster.

The other important bit has been to actually document what the Simplified Javascript API provides. The relevant file in kdebase/workspace/plasma/design/ has been morphing into increasingly comprehensive API documentation. What I need to do is turn this mammoth file int a nice set of web pages that I can add to a revamped plasma.kde.org. Any one out there up to doing some HTML slicing and dicing?

There are also a growing number of examples to augment the documentation and which are just begging for Techbase tutorials to be written around.

Add to this the progress being made with Plasmate and the ability to script plasma-desktop itself with Javascript and things are looking better and better for Javascript in 4.4. Huzzah.

In an unrelated side note, Markey's blog entry on finding a balance in software configurability is really well written and makes several excellent points with great clarity. A must read if you haven't already seen it, in my humble opinion. :)

Read More

let's do coffee ;)

Things have been crazy busy lately on every single front in my life. This has come at the expense of not blogging much at all, which has sucked. So much has been going on, a lot of it very interesting and fun and which I would have liked to share with you as it was happening. Such is life, but we need to catch up. So grab a coffee (or whatever you prefer, tea maybe? :) and let's catch up!

I ended up at a fencing competition as a spectator this weekend cheering on S. (and editing text from the sidelines for the Akademy sponsorship brochure that Claudia, Kenny and Nuno are working on; it's looking great!) and then out for dinner with old friends here in Vancouver the day after that. I also completed one of the last I-just-moved-to-a-new-province tasks as well: I got my car registered and insured with the locals here in B.C. Turns out that my B.C. drivers license expired the same year I got my now previous car insurance in Alberta, which led them to give me 14 years of safe driving and pushing me into the highest discount bracket (and one year away from the highest rating bracket over all). Still, it was one more thing that filled in my schedule.

The KDE promo team is in high gear as well, and that's keeping me a bit more busy. The promo sprint they just had was a great way to punctuate the increase in activity we've been seeing. A Dot story will apparently appear sometime soon detailing what went on at the sprint, but there have already been a number of blog entries on planet.kde.org about it. One outcome of the sprint is that we're starting to organize our communication strategies a bit more. This was not, by far, the most important result of the sprint, but it's the one that's kept me busiest. I was really impressed, and surprised even, to see how many people were at the promo sprint and, as a result, how much they accomplished. But when you have a larger group of people, you need to step up the coordination as well.

I remember the first KDE release announcement I ever wrote. It was just me and a text editor and Coolo reminding me it needed to be ready in a day or two, latest. My how things have changed (and for the better).

I've also been hacking my brains out in a few different areas for 4.4, though I'll blog about some of that later. With the feature freeze behind us, it's become apparent just which items are going to drop off my "can do for 4.4" list, however. Most notably, I'm not going to get to notification queueing or a replacement for the desktop zoom in/out feature. These will have to wait for 4.5 as I work on other items that I hope will have bigger pay offs for 4.4. The items that are being left on the cutting room floor for 4.4 will fit in well with 4.5, though, I think.

I've already come to a determination as to what the focus for the Plasma family will be in 4.5. We've already discussed it a bit on the mailing list, but I won't be announcing it publicly until Tokamak IV which will be in February in Nuremberg. We'll be toasting with the OpenSuse people (congrats on 11.2, btw!) and hopefully enjoying the company of a few friends from elsewhere in industry as well. Most importantly, we'll be setting the Plasma agenda for 4.5. Much love will be had. (Or something, it just sounded like a good ending.)

I'm also in another "prep for shows" cycle. I'm going to hopefully be making it to Fedora's FUDCon in December (congrats on F12 and the KDE spin, btw! Seems to be the most popular spin by a kilometer! :) and am gearing up for one or two others.

One show that caught my eye is the Linux Audio Conference. The people involved in getting it going are quality folk (a big shout out to Armijn!) and if there's an area that F/OSS needs attention it's audio. Our stack is a mess at the moment, and not because of API issues but because we're doing a poor job of system integration, shoving features out to our users way before the software is ready for that and the like. I'm hoping that LAC will be well attended and some positive, useful results that will lead to improvements in how we handle our audio stack with care and respect will emerge as a result. I think it's really interesting that LAC will also focus on using media and will be striving to get media content creators there as well. This should help widen the scope beyond infrastructure navel gazers when it comes to audio and get a lot of great feedback as well as grow our shared community around F/OSS audio.

Now, I couldn't mention shows without talking about the most important gathering in the next six months as far as KDE is concerned. Yes, I'm talking about Camp KDE. I'll be there and I plan to bring a truck load of hugs and inspiration with me. I hope to see you there!

Read More

constructive negativity

Some have noted that the tone on planet.kde.org has been relatively negative lately. Some have said that this is actually a good thing, because it's about being honest with ourselves and that there are silver linings waiting for us at the end. That it needs defending at all is telling.

Personally, what I get out of it is a draining of motivation and hope. It's not because these posts are negative, though. It's because they tend to have few hard facts in them, almost never offer concrete solutions and rarely sound like the author wants to be part of the solution. Which means we get left with, well, negativity and not much else. That sucks. What's worse: I don't think that's at all what is intended.

The KDE community historically has had a tendency towards pessimism. We wrap it in terms like "realism", "pragmatism" and what not, but honestly .. our community is moderately conservative and really good at identifying what's lacking, often more so than our ability to identify opportunities and potential. It's a very typical engineering-and-maths type thing to do. It's also rather easy to fall into a "being the clever critic is cool" mode, and when that's all we have to go on, our efforts suffer.

So I'd like to propose a solution, one that I'm going to do my best to follow as well. (And please remind me if I don't. :) When planning to write a critical or negative piece, something we all do from time to time and often with good reason, let's try to:

• Check our facts: do some research and bounce our thoughts off the people involved directly first. It may turn out we don't have all the facts or know all the details at play. Then we can share an accurate viewpoint versus spread misconceptions.


• Lead with facts: start from a factual basis and follow on with our opinions on the matter. There's a demonstrated tendency to leave out the facts we do know or leave them as little better than footnotes.


• Include the positives: if there are positive points as well, let's note them. It helps preserve balance and can help others discern possible motivations for the decisions thus far.


• Propose plausible solutions: if we are going to spend the time cataloging challenges, let's also spend the time and effort to catalog solutions. This is part of being constructive.


• Be prepared to support those solutions: armchair coaches are a dime a dozen and very few of us have the necessary skill and background to play the role of a professional critic: someone who is deeply knowledgeable about but not a direct participant in the field. So if we talk about a problem and propose a solution, remember that we are driven by doing more than talking. If we can't strike out and breath life into the solution ourselves, be the first to support those who can. This moves us from being disruptive because of problems to supportive of solutions.

Personally, I feel that if some of the above had been applied to each of the recent "negative" entires, they'd feel a lot more motivational, constructive and accurate. As a result, I'd expect to see more people charging into the solutions. If we really want to see something improve we need to offer a realistic assessment, a possible starting point and some inspiration so others can find their legs.

Read More

krunner atop redux

In the comments section on my last blog entry about KRunner finding a new home at the top of the screen there were a few common comments, questions and concerns. I figured I'd answer them today in a place that might be easier to notice or find than buried in the dozens of comments on the last entry. :)

Bullet point list time!

• Can I move the KRunner window when it's attached to the screen edge? Yes, just click and drag it around the top of the screen.


• Can I move it to another screen edge other than the top? No, but I'd be happy to get patches that make this possible. Most of the hard work should already be done at this point in making it attachable to the top of the screen. Making the dragging code move it to different screen edges and setting which borders to paint based on the scren edge shouldn't be hard at all.


• Wouldn't it be cool to just move KRunner to the edge of the screen have it attach itself? Yes, it would. Again, patches welcome as 4.4 is looming and I have a serious TODO list sitting on my desk still. :/


• Does it animate when it shows up? Yes, but you need desktop effects turned on, just as with autohide panels. The animation is very smooth and definitely helps one spot KRunner's entrance, but the screencast didn't capture it at all unfortunately; the animation would have to be uncomfortably long for recordMyDesktop to capture it.


• Does it work with Yakuake? Yes. I'm a Yakuake user, so this is not surprising. ;) They will happily overlap each other but you can also move them out of the way of each other.
  
• Does it work with a top panel? Yes.


• Why not integrate KRunner with Kickoff? KRunner uses a plugin system that is entirely in libplasma so that such things are possible, and in 4.4 Kickoff does indeed use these same plugins for its search thanks to work done by Ivan.


• How about a stand-alone plasmoid for KRunner that you could put in a panel or on the desktop? Great idea, one that's been posited a few times. I think there's even one or two such widgets out there on kde-look.org? If you want to propose adding such a widget you've written to KDE's Software Distribution releases (maybe in kdeplasma-addons?) I'd be happy to see it go in.


• How about making this code more generic to make edge bound windows easier? The majority of the code is already in libplasma in the form of Plasma::Dialog and Plasma::WindowEffects. What's "missing" is something that sets the window geometry according to a screen edge and the click-to-move code. Not difficult stuff to implement, but I'm not sure what the exact use cases would be. We can already use the Plasma Desktop panels for most "stick it to the edge of the screen" use cases.


• What about people who prefer it in the middle of the screen? That is why I introduced an option, something I don't do lightly but when there are certainly good reasons for the various use cases the option represents.


• What about some default matches when you first open it? While possible, and indeed something we do in Plasma Netbook, I'm not sure it really fits very nicely with the intended KRunner workflow in terms of "how often they would be used". It's why we keep a query history in the text edit, however.


• Why isn't there a scrollbar when there are more matches than fit at once? KRunner is meant to be a quick search and launch interface, not a query and wade through 100s of returns interface. Scrolling isn't the primary use case, and a scrollbar diminishes the visual layout; the current scroll buttons could be improved, however. Patches welcome. :)


• Why isn't krunner keyboard navigable? Are you telling me that your keyboard doesn't have a tab key?

Edit: two more quickies that I forgot the first time around:

• Is the multi-screen behaviour where it pops up on the screen the cursor is on preserved? Yes.


• How about making it pop down when the mouse moves to that screen edge? This would be nice, but would require a bit of work in two places: first, it should share the code for this with plasma-desktop (thankfully both apps live in the same module, so code sharing is easy) and secondly, it shouldn't interfere with panels on the same screen edge (easy to detect by looking at the available geometry on a screen). Patches welcome.

Read More

KRunner from the top?

Yesterday I was hit by the idea of putting KRunner at the top of the screen and making it 'slide in' when called up. The "floating dialog" just wasn't doing it for me anymore and so I went ahead and implemented this to see what it would feel like. After working out various kinks, I have to say that I really like it. So I decided to do a quick screencast showing KRunner in action at the top of the screen for you to watch and then, hopefully, offer some feedback on it. It's even better if you can try it out yourself by building from SVN trunk, of course, but I know not everyone can or will do that. If the reactions are generally positive, this will be the default for 4.4.

There are two small problems with the screencast, however. The first one is my fault: I forgot to show that you can click on and move the KRunner window back and forth along the top of the screen. The second problem is the typical screencast software fail: it doesn't capture smoothly enough to show any of the animations so you'll just have to trust me when I say that the KRunner window animates in and out of the screen nicely. Those animations are done by KWin, using the same effect we wrote for the autohiding panels in fact, and they are super sexy smooth.

Anyways, you can watch the screencast on blip.tv, download the Ogg file or watch it in the embedded player below if it shows up for you:

Read More

we all want to be different

In a blog entry the other week I talked about three challenges that arise as the number of individual groups participating in KDE has grown: time line mismatches, differentiation pressures and confidentiality requirements. I wrote a bit about time line mismatches, so let's move on to differentiation pressures. Here's what I said (in part) about this issue in that first blog post:

"When it comes to monetizing and commercializing a F/OSS product, there is often the desire to offer differentiation through features or behavior in the software. This can lead to forking the software to various degrees or reinventing / replacing components or entire stacks.

There is no singular root cause for this, however, which makes it a really interesting issue. Sometimes the differentiation pressure comes from operating in an overly competitive space, sometimes from being in a market that has unique pressures or requirements and other times it comes from the desire to build brand identity. This leads to a situation where sometimes the differentiation is rather frivolous and other times more substantial and the result of a hard requirement."

If such differentiation efforts go wrong, it often will reflect poorly on your project even if it wasn't your fault. If differentiation is too hard, the downstream may look for another project to work with. If it all goes well, you may find a new source for upstream contributions. How we manage this phenomenon to get the best results? Here are some of my thoughts, and I'd love to hear yours as well in the comments section.

Be Aware

If at all possible, keeping some communication open with those who are working with your project is a great idea. This can often help make sure you are aware of what they might be wanting to change. Knowing there's something being shifted around is a great way to catch issues that may result before they happen, which is a great way to help your larger community avoid frivolous or just plain bad ideas. At the very least it can help you make sure that those differentiation efforts don't run into walls that the project team may have unintentionally erected that now stand in the way of these differentiation efforts. Or, if it's one of those twisted scenarios, it may give you the lead time needed to throw up such walls. ;)

Communicate Your Hopes and Dreams

Sometimes people want to differentiate your product in a way that works quite counter to what you have in mind. When this happens, communicate to those downstreams why you feel that way. Maybe they are trying to grab features or code that isn't ready yet (and thereby inflicting great pain on your shared users) in an attempt to beat others to the punch; maybe they are taking the software in a direction that conflicts with other things in the pipeline or which have been tried before and just don't work well; maybe there are opportunities to work together and make something even better. Regardless of the situation, a common cause for mistakes in the drive to differentiate is "we didn't understand the consequences and implications".

Of course, they may not heed your input, but I find that often they will try to and a compromise or even straight out agreement can be found.

Make The Software Flexible

There are going to be some areas in the software that people building products around it are going to want to customize. It could be as trivial as the artwork or template data but it could also be a lot more invasive.

Identifying the areas where such changes are likely to be made can then allow the team to make it easy to make such changes. When it's easy, mistakes will be fewer and the differentiation efforts will go smoother. This is perhaps the most powerful answer to the differentiation challenge because it helps channel efforts (if it's easy to differentiate on A and harder to differentiate on B, many will take the path of least resistance .. which is handy if you want them to stay away from B ;) and can substantially improve the results which in turn reflects positively on you and your project.

Identifying such areas of possible differentiation can happen in a number of ways: clever guesswork based on what you know about your software and the people who use it; talking with the people who are working on differentiation features; watching what different groups tend to add to or modify in your software.

Once identified, think about how to make it easy for people to add unique benefits or tweak what's there properly (whatever that means for your project). Sometimes a plugin interface can make all the difference (avoiding nasty invasive patches being applied to the code base), sometimes scripting interfaces that allow for easy changes at runtime can help, sometimes tools that help craft these changes with or even for the differentiator can be extremely useful. Ensuring that there are clear divisions between data and visualization and other tight-coupling-preventing measures can also help as they lower the cost and danger of changing one specific thing. Perhaps most important is documentation; it is always a winner as it will help people working with your project know what they can do and how best to do it.

When All Else Fails ..

When things turn nasty and a group really bungles up a differentiation attempt and your project is or will be getting painted in a poor light because of it, let that group know that you don't agree with what's going on and why (communication). Perhaps make a polite public service announcement for your users so they are aware of the situation. If need be, distance your project from that particular effort and try to do some damage control. Politely send people who come complaining to you about it politely to the people responsible for the bungle; eventually everyone will get the message.

Due to our projects being Free software, it is impossible to avoid attempts at differentiation being made by others. As much as possible, be accommodating of such efforts and encourage people to do cool things with your stuff. They may do things you don't agree with, but that's the beauty (or price, if you wish to look at it from a negative slant) of freedom. Accepting that can be a great remedy to what could otherwise be frustrating. This doesn't mean you need to be accommodating however; just because someone makes some change to your project that you don't agree with doesn't mean you are now required to offer support to their users for those changes or that your software should be forced to adopt those same changes.

Above all, though, watch what kind of differentiation works .. and then suck the best of those changes into your upstream project so that everyone can benefit.

Read More

flu == documentation?

The P-man (and a few of my friends in town here) had the flu before I left for ABLEConf last week. (I need to blog about ABLEConf as well, but will do so later ..) As luck would have it, it would hit me while I was down in Arizona (I had almost completely lost my voice by the time I left, despite spending the whole last day in bed in the hotel) and I continued to feel "draggy" right through today. So, not feeling up to any overly serious hacking today, I wrote some documentation.

The result is a Runner plugin (as used in KRunner) in KDE Examples and a tutorial on Techbase that goes through the Runner plugin implementation step by step.

It's a first draft and I'm not feeling 100% still, so it will have rough patches still. Please check it out, improve it or ask questions for clarification.

Read More

animations in plasma with javascript on top

We were lucky this summer in that not only did we have a bunch of our own great Google Summer of Code students, but we got one more for "free": a student working with another mentor organization that has a strong working relationship with KDE completed their assigned project rather quickly, and so we inherited them, and another half-project, for the second half of the summer. They worked on animations using the new QtKinetic framework that appears in Qt 4.6 and over the last couple of weeks a number of Plasma hackers descended up on that work. We cleared out some of the lose ends, cleaned up the code, added a bunch more functionality and merged it into trunk this past week.

They are really quite powerful and very easy to use. We're still fiddling with some internal design decisions, but the API is ready to be tested and knocked on.

I recently spent an evening updating the simple JavaScript Plasmoid Engine so we can access them from JavaScript plasmoids. Then today, after spending the rest of it replying to mails and blog comments, working on my presentation for Saturday and closing a handful of bugs in the tasks widget and drag and drop functionality, I did up a small screencast showing the animations in (excuse the pun) action using JavaScript. You can click here to watch it on blip.tv., view it in the embedded viewer below or download the original Ogg file here. Enjoy!

This is all very new stuff, so all the usual "it's only alpha" and "won't be available until KDE 4.4 is released in Q1 2010" apply.

(Oh, and please excuse the cheesy introduction; it was a long day and I couldn't help myself. ;)

Read More

two simple things to improve the user experience

There's a lot of discussion about user experience around these days. That's good, though sometimes the focus is kept on solving "big issues" and a lot of the small everyday type things get missed. Here are two things that I personally run into a bit too regularly that can be easily improved on and which really do help with the user experience.

Jargon Is Bad

We use a lot of jargon when discussing, designing and creating our software. When we're working on something that's complex or new, new words and phrases (or new meanings on old ones) will crop up in our language when discussing it with each other. The world outside our creative circles remains innocent to these new bits of language floating about. This is all well and good .. until the jargon starts creeping outwards and meets people using the software.

In Plasma, we try to keep the jargon we've invented to help us work together out of the user interfaces. It's not a cashew, it's a toolbox. It's not a Plasmoid, it's a Plasma Widget. It's not "Plasma" it's "the desktop shell" or "the workspace" (if we're being more inclusive and talking about KWin, etc as well). It's not a Containment, it's an Activity if it's on a main, full-screen layer (e.g. desktop or dashboard) and something descriptive for the context (e.g. Panel) if elsewhere. It's not always easy because to us these words are just second-nature.

There's a lot more jargon in KDE, though: nepomuk (search service!), krandr (screen settings!), kwin compositing (desktop effects!), akonadi ... If we can keep the jargon out of what we see when using the software, it will help people immensely. We should instead be using terms that describe what it does or why I should care about it when I'm using it.

Micro-Options Suck

KDE has a great history of configuration options. Sometimes, however, we use that as a cop out and instead of making a good decision or a hard decision we make no decision and instead put an option in there. Besides the cost on the code itself (more code paths, etc, etc) there's a cost to the usage of the software.

Every option shown to the person using the software is something they have to read and understand. Then they have to choose whether to interact with that option or not. Is it what they are looking for? What happens if they toggle it? Where is that thing I'd like to control? At some point, people will give up, get frustrated or both. At best it slows them down, at worst it causes them to stop using the software all together.

So when deciding which options should be there, know the audience and its needs (e.g. technical applications will often have a lot more gadgetry to them) and be ready to make hard decisions. If it turns out that it does indeed need to be made optional, it can be added later. Taking back an option once offered is really hard, though. It makes people sad.

The good news is that if a few hard choices are made, including the occasional "no, I'm not going to make that optional even though you and your friend have asked for it nicely", there will be lots of room for other options that are highly valuable and useful.

So think twice before doing the "just make it configurable" dance. It's one step towards how we can have our cake (great configurability) and eat it too (have good looking and highly usable software).

Read More

in Phoenix this weekend

I'll be in Phoenix, Arizona (USA) this weekend attending ABLEconf which is a local F/OSS event that is aiming to increase awareness and use of F/OSS in Arizona. I'll be trying out a new presentation there (something I often do at smaller events) that shares what KDE is doing right now from the lens of fulfilling expectations when it comes to user experience.

If you're in the area, please come check it out. I'm sure we'll have a bunch of fun, or at least some interesting discussions. Besides ABLEconfg itself, I fly in on Friday and leave on Monday, which currently leaves me with a Friday evening and all day Sunday free. If you'd like to meet up then, drop me a note by email.

I used to do quite a few small local shows (including some that have grown to be less small these days :) and I'd like to get back to doing some of those again. I'll certainly be tooling around the Americas more again now that KDE e.V. board duties aren't pulling me over to Europe so often. If you are involved with a good event in the Americas that I should be at to spread the KDE message, give me a shout. (Preferably well in advance of the actual event. :)

(See, I can write short blog entries!)

Read More

kdeexamples

The KDE Examples module is coming along nicely. I spent some time today moving examples from kdelibs and kdebase into it and `tree` now report 71 directories and 130 files. We have examples for KConfigXT, KAuth (new in KDE 4.4), KIdleTime, Phonon (a bunch), Solid (another bunch), Plasma's new QtKinetic based animations (new in KDE 4.4), JavaScript Plasmoids, Ruby Plasmoids and DataEngines, Python Plasmoids and DataEngines and plasma-desktop interactive scripting console.

I'm sure there are many more examples out there to be found and added. If you know of any, either let me know or add it to kdeexamples yourself. If you'd like to write some little examples, that'd be great, too. There are some gems hidden away on pages in Techbase, as well, that need to be reaped.

There is one other thing that I could really use someone's help with: documentation. As usual, I'm stretching the limits of my available time already and it would be great to have mention of kdeexamples somewhere on Techbase as well as some documentation inside of kdeexamples itself describing how to get started with it and what is available. A simple text file could do the trick, old school README style, or if someone is feeling a bit more motivated a nice looking set of HTML files could be pretty awesome.

If you'd like to help add a bit of "welcome to the KDE Examples module, here's how to get rolling" documentation to it, please get a hold of me (aseigo at kde dot org) or find me on IRC and let's get this rolling!

Read More

comparing "KDE 4" and "GNOME 3"

There is small trend currently to write a blog entry or article comparing "KDE 4" and "GNOME 3". Now, I'm not involved in the least with the GNOME 3 efforts (no big surprise there, I'm sure :) so I can't and won't comment on what they are doing now or in the future (they can do so themselves quite well :), but there are two interesting points I keep seeing raised that I really do want to address ... and I don't feel like commenting on every blog post out there. ;)

KDE 4 .. or the KDE Workspace?

What these blog entries are usually comparing is not "KDE 4" with "GNOME 3" but two of the KDE 4 workspace components, Plasma and KWin, with gnome-shell. Little more than that is compared in most of them when the topic is "KDE 4 or GNOME 3?". This is unfortunate because KDE 4 is a lot more than just the KDE Workspace, which is just one product that comes from KDE, just as GNOME 3 will be more than just gnome-shell.

A primary example is the KDE development platform. It consists of KDE's libraries built on top of Qt, Akonadi, Nepomuk/Strigi and others and represents one of the most important products we create. This platform started back in the 90s as a means to an end: getting the KDE desktop workspace functioning and sharing code and functionality efficiently between KDE apps in a way that guaranteed some consistency. These days, while it has kept this same set of purposes as an important part of its mission, the KDE development platform has taken on a much bigger role and a life of its own.

I'd love to see some thoughts that extend beyond Plasma/KWin out there and look at things such as the maturity of KDE's development platform compared to what others are offering right now or, as in the case of GNOME 3, in the near future. I'm really excited how we have Nepomuk shaping up, for instance, or how in the last few releases we have seen integration of KAuthorization which gives us access to PolicyKit (including the upcoming polkit-1 release) on Linux using the same "hide the system level API details" strategy as Phonon, Solid and others which in turn has made the polkit-0.9 to polkit-1 transition painless for KDE applications. We have good, stable libraries built on really exciting technologies. (Just look at what's going on in Qt these days, or Akonadi!)

There are also other products that KDE projects churn out at a remarkable pace as well. Some are released in categorical packages, such as KDE Games (which just got another neat game the other day, a Bomberman-style game which stole some of our time last night here in the house ;), KDE Edu or KOffice; others are released as stand out individuals, such as Amarok. These are all independent projects within the KDE umbrella and most if not all of them are considered part of "KDE 4". They can all be run independently of the KDE Workspace and stand on their own merits.

What I'm saying is that if you lift your eyes up (or cast them further down, as the case may be), KDE 4 is a lot more than the KDE Workspace and we should be sharing those other bits with people too.

"You say you want a revolution"

The other point that keeps coming up is whether there is too much, too little or any actual revolution out there in the workspace. Regardless of what people think of where gnome-shell's approach lands on that scale, there's a subtlety to the Plasma story that I fear may be being missed and it makes me simultaneously beam with pride and cry tears and sorrow. ;)

To be honest: I don't believe in revolutions, because revolutions don't exist except as a story telling mechanism. A "revolution" is a story about an evolutionary series of events with some careful editing: it starts at a random point in time which then gets called "the beginning", skips most of the middle bits and then ends at another point in time convenient to the storyteller that gets called "the exciting end!" If you track beyond the beginning and ends and include all of the middle bits too, it turns out all "revolutions" are actually evolutionary sequences presented in a much simpler (and fun to listen to) way. So maybe we should be talking about the value of different possible evolutionary tracks and what they can or will bring us; talking about revolutions can be left for people retelling our story far in the future?

In any case, several writers have noted that "Plasma" offers a pretty stock desktop with a whole bunch of nice improvements. I would agree there: we've improved the system tray, notifications, widget handling; we've removed a lot of assumptions like "this is the one and only KMenu" or "yes, you must have at least one panel!"; we've added things like a dashboard overlay and multiple widget layouts, extensive SVG based theming and the ability to extend your panels and desktop not only with C++ but also with HTML, JavaScript, Ruby, Python, GoogleGadgets, MacOS widgets and E17 widgets; we've improved workflows associated with device hotplug, application menus, etc. Those are certainly evolutionary and not revolutionary. (Which reminds me, I need to do a new "cool things you can do with KRunner" screencast..)

Beyond what's quite clearly evolutionary, we're introducing things like remote widgets which lets you share and move components over the network between devices without any difficult configuration or set up. A couple of clicks and away you go. We're finally merging Plasma's Activities (multiple widget layouts) with Nepomuk's store and beyond into applications and working on an improved Activities management system. These are a bit more than the usual breed of evolutionary features.

Even then, there's something much more critical to understand here: when I set out to tear apart kicker and kdesktop, the foundations of KDE 3's workspace, I did so with the idea in the mind that this should never need to be so painful to achieve again.

An epiphanous (is that word?) moment for me came in the realization that the current desktop metaphors and ideas are so deeply entrenched in today's users that they can not just be ripped out wholesale and replaced. At least not if you expect any great number of people to actually use it on their desktop or laptop computer. We can evolve it, but we can't just replace it wholesale. But it will evolve and our framework must be able to keep ahead of that curve. That means that even on the traditional form factors of laptop and desktop, the days of building a purpose-built "here's your workspace" system and expecting that to last for any extended period of time are over. The workspace needs to be flexible; it needs to be able to adapt to ideas we haven't had yet; it needs to be able to have a ninja drop into the middle of it and make lightening fast changes to one area to bring that one area forward to the next necessary stage of evolution without running into walls or causing problems elsewhere. It needs to be something completely different than what it is today ten years from now .. without ever being completely rewritten.

Another epiphanous moment (there's that word again!) came when I realized that laptops and desktops were not the only form factors we could target and expect to remain successful with. We needed to build a system that could be remolded with minimal effort and maximal flexibility to fit new places and fit them well. Plasma Netbook makes use of well over a 100,000 lines of code written as part of Plasma for the laptop/desktop space while, by adding a few thousand of its own, offering a user interface that is crafted specifically for the netbook form factor that offers very little in common workflow-wise with the desktop. That means we get compatibility with your desktop/laptop "for free" avoiding the separate silo effect, have invested minimal efforts by changing or adding only what we feel is needed or wanted and can provide something that is both familiar (due to having access to similar features as Plasma Desktop via widgets like microblogging or Google Gadgets) and specially crafted at the same time.

Being able to do this while also being able to deliver a nice and traditional desktop workspace, despite none of that being embedded in the DNA of Plasma itself (it's all in plasma-desktop and a few desktop-specific Plasma plugins), while keeping it all neat, tidy and sane (hacks-be-gone!) has not been the easiest thing to pull off. So I'm really proud when people look at plasma-desktop and observe that it's a nice evolution over what was there before. I also cry a little when people don't realize that there's more to the story. :)

Now, I don't know of a single other serious project out there (in terms of "shipping releases meant for actual production use some day") that is able to pull this same thing off. Do you? Every other workspace project I know is either hyperfocused on one form factor or follows the "here's a toolkit, now rewrite everything above the toolkit for every target application" concept, which is what we've always done in the past.

While designing the fundamental ideas that would later be built by myself and the amazing team of people I get to call my team-mates into this thing called "Plasma", an evolution that doesn't lead to dead ends and lets us sprawl with ubiquity across the computing landscape from device to desktop, from media application to multi-user interaction and wherever else we want to go.

So while we work on the implementation realizations, such as fancy desktop grid effects and what not, we are doing so as part of a big picture that is inclusive of where we've been, where we are and where we may want to go in the future.

Keeping an eye on others without becoming distracted

As a footnote to this entry, I thought I'd share something related but not strictly on this topic that we keep running into with Plasma. We do keep eyes on what others are doing, whether that's Microsoft, Apple, Google, Intel, Nokia, Enlightenment, GNOME or people doing purely academic research work. This helps give us some perspective and reality checks from time to time. It also helps us get some good ideas we may not have come up with on our own. At the same time, we're doing new things in new ways as well, and so while we watch others we also have to remain on guard that we don't end up becoming distracted from our own mission. There's a fine line between keeping tabs on the other cars in a race and chasing their light lights. It's interesting to observe how easy it is for the human mind to start doing the latter. Perhaps that's just part of being a social species?

Read More

KDE example code

When someone wants to learn the techniques and tricks of development with KDE libraries, they can head on over to Techbase. While we have a great amount of information there already with dozens and dozens of tutorials, we're still missing a lot of topics there. We really need to address that over time, but that's a different issue from the one this blog entry is about: example code.

There is a lot of example code scattered around in KDE's svn. Sometimes they are referenced from or even provide the entire basis for tutorials on Techbase. Getting them isn't very convenient or even easy for too many people.

Most of our third party developers do not build KDE's base libraries from source code, they just install the packages from their distribution which only include the binaries, development headers and text documentation. For those that do compile from source, the fact that there are examples hidden here and there is often not known to them. So despite all the work that has gone into those examples that are squirreled away in kdelibs, kdebase and elsewhere, they miss out on what is probably their most important audience.

Inspired by other projects out there, not least of which is Qt with it's inclusion of both an examples and a demos directory in its source tree, I suggested that we should have a "kdeexamples" module. This module would contain as many of our examples as possible and would be offered for download as a single tarball so developers can download them all at once and use them for current and future reference. They may even find a few technologies they didn't even know existed in the process, but more importantly they will have one place to check for examples.

Of course, KDE is a project that thrives because it is people doing rather than people just talking. With some help from the sys admin team (thanks, guys! :) we now have our very own kdeexamples module. You can find it here.

If you have example code that illustrates how to use KDE's various libraries and technologies effectively, please add them to the module. I'll be adding a top-level CMakeLists.txt in a moment for building the examples and examples included should be grouped by topic to make finding things reasonably easy.

A first tarball release will be made as soon as it makes sense to (e.g. there are a significant number of our examples in it) or 4.4 is released, whichever happens first. Personally, I'm hoping for the former. Also, although this is probably obvious: distributions should not package this module as the whole point is being able to study the source code directly. :)

Enjoy! :)

Read More

freedom services

The idea of integrating online services, especially the sort that are (poorly, IMHO) referred to as "cloud computing", is met with resistance by some. The reasons they offer are generally compelling, namely they are concerned about a loss in Freedom. Here we have spent all these years building freedom into our software and along come these online services as an end-run around that, they say.

I actually agree with them on that point: most online services today are not freedom enhancers but freedom eroders. This was equally true of the overwhelming majority of software produced in the 80s and 90s and even much of it that is produced today. Some who have seen the doors close on certain business models framed around proprietary software have tried to dodge this by creating online services instead. Still others have seen the potential of online services and in their excitement and hurry have not considered the implications to the rights and freedoms of those who will use and perhaps even come to rely on their service.

I do believe that there is answer for this, however: Freedom Services. Just as with Free software and its commitments to use, modification and redistribution we need a set of commitments for online services to meet. Then we need to create those services and get people using them.

For the last couple of years, I've been rolling around in my head the question of what those commitments would look like. As we work on exposing online services in our Free software products more and more this becomes a rather more pressing question. Here are my thoughts as they currently stand on what those commitments should be for a service to be considered "Free as in Freedom":

0. Specification: A full specification of the service's complete API must be freely available to all for reference. The specification must also be unencumbered so that anyone else may implement and extend it if they so choose without restriction.



1. Implementation: A reference implementation of the full specification must be made available under a Free software license so that others may study, use and extend it freely.



2. Privacy: A commitment must be made to all users of the service that privacy related issues, such as use or sharing of the user's information, is openly and clearly documented and that any privacy infringing action the service provider partakes in is opt-in by the user. This includes any actions taken by the service outside the scope of the Specification.



3. Data Integrity: A commitment must be made to all users of the service that the data they create is theirs. This means the user must have the ability to easily have their data exported at their request in a useful format to a location of the user's choosing (e.g. a local file or even another service) as well as have the ability to remove any and all information generated by the user of the service from the online service at their request. Should the service shut down for any reason, the user must have a reasonable opportunity to retrieve their data.

Is this even possible? identi.ca comes close, though there is no data export function. opendesktop.org comes close as well, though there is a missing Free software implementation of the specification. So we have gaps to fill and many services to erect beyond that.

A registry of services that match some or all of the above commitments could be quite useful to those of us who care and would like to educate others about the issues as well. It sounds like a job for the FSF or FSFE to me! :)

What would you add or subtract from the commitments listed above? What services would you most like to see completely opened up?

Read More

ah, stats

Cornelius posted a neat summary of the source code heft in KDE's main modules. It was also picked up by some of the general F/OSS community news sites.

Michael Meeks posted an blog entry showing other projects' line count next to KDE's while asking "the real question is not 'is KDE valuable' - of course it is; but how does it compare[?]" In a nicely concise table he shows that Ohloh pegs KDE at 5.5 million lines of code with GNOME at 15.7, Linux at 7.9 and OpenOffice at 8.5 respectively. That makes KDE's code base look smaller in comparison to these other projects, doesn't it?

Unfortunately, statistics are often hard to interpret when aggregated like that. Also unfortunately, Michael's blog doesn't accept comments to it (2000 called and it wants it's blogging software back? ;) so I figured I'd expand a bit on this here.

Cornelius's numbers, as well as the ones on Ohloh, only cover the modules we release as part of the periodic KDE Software Distribution. These are the modules that get known as "KDE x.y". What those numbers don't include is the rest of the code we work on under the KDE community umbrella. That would include all the apps in our Extra Gear repository such as Amarok (175,760 lines), Digikam (478,185 lines), K3B (101,320 lines) and Kaffeine (269,149 lines) to name the four largest. My checkout of Extra Gear contains 1,175,644 lines of code according to sloccount. Also missing from the numbers is the code in kdesupport for things like QCA, Nepomuk and Strigi, Akonadi, Phonon, taglib, KDE/Win utilities, etc. which combined represent some 433,208 lines of code according to sloccount.

Most significantly, however, is the omission of Qt itself. Ohloh weighs it in at 16,028,530 lines of code.

If we look at the Ohloh numbers for GNOME, Linux or OOo they are much more representative of the entire set of code associated with those projects. GNOME, for instance, includes Gtk+ and a comprehensive listing of applications worked on under the GNOME umbrella. That helps explain the 15.7 million number a bit more clearly.

With a similar amalgamation, KDE weighs in somewhere in excess of 23 million lines of code. Even then, nothing is said about code complexity, efficiency granted to applications by sophistication in the lower levels of the stack, etc. That just can't be reflected in such simple numbers as these. Still, it is an interesting data point to look at for what it is worth. (A sentiment that Cornelius shared in his blog entry as well.)

So does this tell us anything useful at all? Well, if nothing else it does show that there is a lot of F/OSS technology out there these days. Between the four projects mentioned here alone there are over 50 million lines of code, and those four projects, while large in their own rights, are hardly the bulk of F/OSS code. That's pretty amazing.

Read More

thanksgiving

Yesterday was Thanksgiving in Canada. (The Americans celebrate it on totally the wrong day. ;) Family and friends descended upon the house here and we commenced to cook up a storm in the kitchen. We used every pot, plate and bowl (and nearly all the cutlery) in the house at one point or another in the day. The result was a very delicious bunch of food: an organic free range turkey (most everyone in attendance was omnivorous), baked mashed yams and sweet potatoes, roasted beats, steamed brussel sprouts and leafy greens, a potato and carrot roast, gravies, stuffings and pumpkin pie. Yum!

Thanksgiving is about more than food, of course. It's about, well, giving thanks. (That and board games, conversation and sharing some drinks with friends. :) I'm thankful for so many things in my life, with my family and home at the front of that list. This is my KDE blog, though, so what am I thankful for right now when it comes to KDE? Here's my non-exhaustive list:

• Qt Development Frameworks for picking up Marco Martin to work on Plasma related technologies. Pure awesome! I really enjoy working with Marco, and I'm happy he now can devote his full attentions to this stuff. I do hope to find more such opportunities for Plasma folk in the future. As the project matures and generates more useful products for others to invest in, I'm hopeful this will happen fairly naturally.


• The KDE PIM folk are communicating more. I took some of them to task recently about the detriments of non-communication and where the responsibility for communicating might lay in a project that has commercial backing. Such dialogs are never the most fun thing one could imagine spending their time on, but several of them did just that, particularly Till. There's been a rolling parade of blog entries and stories that have made it onto community news sites in recent times. For that I'm very thankful to the KDE PIM team. Communication is awesome (and how else would I know how far along Akonadi for Qt, KDE and Gtk+ had come?), improving our processes around it is even more so. PIMsters, keep up the communication, because you rock and we should be able to keep up with that. :)


• User communication improvements are to be seen everywhere in KDE land. From KDE Brainstorm to Userbase to the new crash dialog that has noticeably improved the quality of bug reports since it debuted, these efforts have improved my life. Hopefully they have helped others even more so.


• Our community of contributors continues to do amazing things, and for that I'm very thankful as a user of our software and a member of that community. While the three previous points are more transitory in nature, this one is ongoing. Ever since I started contributing to KDE, the community has been here and been strong. It's the air we breath, and just as easy to take for granted. Thanksgiving is a great reminder for me to stop and take it un-for-granted.

Read More

managing time line mismatches

In a blog entry last week I talked about three challenges that arise as the number of individual groups participating in KDE has grown: time line mismatches, differentiation pressures and confidentiality requirements. I also said I'd write something about possible ways to address each of these issues to smooth out some of the wrinkles they can cause. Let's start with time line mismatches.

In describing this issue, I wrote:

"When a large number of diverse interests come together, each with their own release requirements, market goals and deadlines it becomes inevitable that time lines will not match up across every single participant in the community.

While perfect cadence would be lovely, reality is that different kinds of software and different business interests will have different requirements when it comes to time lines."

A concrete example might be a company working that has a private development contract with a third party that includes working on an upstream piece of KDE. This is actually fairly common and can be seen in Akonadi, Kontact, KOffice and Plasma to name just a few. This may sound like a great thing, but those contracts often come with delivery schedules attached to them. Those schedules may not coincide with KDE's upstream schedules, and diverting KDE's schedules just because company Foo signs a contract this year with government or company Bar doesn't make sense in the least. So what can we do?

Here are some of my thoughts on that question, some (all? :) of which are probably somewhat obvious. As usual, I don't have the definitive set of answers: there are certainly other approaches out there. Please share them with us if you know of some. :)

Communicate

This is the most basic part of any answer: if the larger community around the software knows when your schedules come to a close or when certain milestones must be met then the odds of the rest of the community working to accommodate, or at least not get in the way of, your schedule increases dramatically.

Due to confidentiality requirements, it may not always be possible to be overly detailed about some aspects of the schedule, but almost always it is possible to give at least a general outline of scheduling requirements.

The simple act of communicating has helped us in Plasma a few times, and the lack of such communication has also caused some real problems for us as well. It's amazing how important and useful just one small email can be.

Feature Branches

Sometimes it is necessary to work on features outside of the time windows alloted by the upstream project in which new features can be merged. Feature branches are a great way to work around this. By keeping such development away from the main development area it is often possible to keep feature development going without stepping on the toes of the upstream's schedule.

An important point is to commit to merging that feature branch as soon as it makes sense to do so. Also, as bugs elsewhere are often uncovered while adding new features, make sure that fixes to existing code are either made in mainline and merged back into the feature branch or that the fixes are merged immediately into mainline from the feature branch. This allows mainline to continue to benefit from your efforts and not to diverge too far from your branch when it comes to code not directly related to the new feature set.

Such a "diverge, but as little as possible" approach can accommodate multiple feature set efforts in parallel quite efficiently. Paired with a VCS like git that makes merging easier (than, say, svn *sigh*) features can develop and land fairly independently.

The downside to the feature branch approach is that it gets less testing and can end up conflicting with the design of other features. The more divergent and numerous feature branches get the harder it can be to track each of them and ensure each gets merged in a reliable manner.

In Plasma, when we have feature branches we track their progress fairly closely and try to merge them into mainline as early in the development cycle as possible. This, of course, means knowing when that feature will land, but we rarely have features that take more than two full cycles to implement or that can't be broken up along those lines. We have even taken to doing "merge fests" at our developer sprints, as doing big feature merges in person with a group can sometimes be easier and more efficient.

This helps us keep Plasma from becoming overly "branchy" while respecting the time lines of each developer without keeping the release cycle meaningful in terms of being when we land and integtrate features, test them and get user feedback on them.

Stabilization Branches

Stabilization branches represent the opposite case to feature branches. This happens when someone needs to ship a product around a given piece (or pieces) of KDE while the upstream project is still working on new features or features that are outside the contracted scope. The idea behind such branches is work on stabilization, optimization, etc. of the code in order to make the requirements set out by the schedule.

When the product to be shipped is based on a recent release of KDE this can be very easy: work in the stable branch (e.g. /branches/KDE/4.x/foo/) and forward port fixes into mainline. When the product to be shipped relies on work in mainline or includes features in a feature branch that hasn't yet been merged into mainline, then a new branch may be needed. Remember to merge changes back into mainline as appropriate as you go, however, so that everyone can benefit.

Some fixes aren't merge-able: they might be on a feature not in mainline yet or be an ugly short term work-around for something that is fixed in mainline in a way that can't be in the branch. Those are the exceptions, however, and should remain that way.

The KDE PIM folk have an "enterprise" branch and they regularly merge large sets of patches from that branch into the main line branch. This has proved pretty effective, at least by my observations, in the time they've been doing so. They tend to them in batches, and that seems to be an efficiency measure: they can sift through a number of changes all at once after they've been proven in the stabilization branch and discard the inappropriate ones leaving a batch of commits to process all at once.

I wonder how much of this is done by hand by them (KDE PIM people, any ideas?), and have often craved some nice tools for managing such things. Fiddling with the vcs directly is OK, but I can imagine much better workflows which could be aided with some purpose built tools.

Prevention

Perhaps the most obvious answer to conflicting time lines is to avoid them whenever possible. With one group I worked with this year, we actually pointed out the upstream schedule and the client adjusted their deployment schedule to fit that. This obviously isn't always possible, but it is possible more often than one might at first expect. Upstream doesn't always need to be the point of flexibility, and if the client group has flexibility in their schedule that can often be a much more natural and easy place to flex.

Finis; Now your thoughts?

What methods have you employed to deal with time line conflicts? How well did they work? What are the limitations of them?

The next entry on this topic (in a few days time) will be on the issue of differentiation pressures. It's tricker than time line issues in my experience, so I'm looking forward to writing about it. :)

Read More