small steps every forward

Besides helping Ana get the new widget explorer in place and handling the usual set of important distractions, I've been looking into various ways to help with performance in Plasma. Marco and Alexis have done a ton of great work already here, improving our SVG caching system substantially in recent months.

Today I managed to get rid of one in memory pixmap for every Plasma::Applet with a background and cut back on the use of the SVG cache at the same time; in doing so I found a couple of subtle bugs in the use of the SVG cache by Plasma::FrameSvg and fixed those as well. The end result is that Plasma now uses a bit less X11 pixmap memory (or whatever the equivalent of that is on the host system if it isn't x.org based), backgrounds for Plasma::Applet objects are correctly cached and the blast of disk activity that was being triggered while resizing widgets is gone.

Now that parts of Plasma, particularly libplasma, are maturing we are able to go through and do more of this kind of work. As we work on Plasma Netbook more (Marco has been doing a stupidly awesome job recently, but more on that whole scene tomorrow) and target smaller devices, this becomes ever more important. We already run quite well on quite modest hardware, but we can do even better.

In other terrific news, Alex Merry killed the last known major crasher in the tasks widget recently. The fix will be in the next 4.3 release as well as 4.4. Way to go, Alex! :) There's also a patch on review board to preserve the manual ordering of the panel when the tasks widget has manual ordering/grouping set and a feature like "show only windows on the current desktop" or "show only windows on this screen" are turned on.

Small steps, perhaps, but it's the small stuff that makes the polish that takes it all to the next level. We have much more to do, but we're getting there.

In the next two months I'll continue to work on such things, but mostly I'll be concentrating on two sets of features: a new activity overview mode to replace the current zooming system we have and Kiosk action restrictions with the goal of surpassing the flexibility that Kicker and KDesktop offered sys admins.

Read More

continuous communication

Different projects within the KDE and Qt worlds and their leadership have different viewpoints on how external communication could or should work. By and large, we do pretty well in our extended community in this regard. However, there has been an increasing number of lost opportunities as well as unfortunate incidents related to the way communication is being handled by some projects in our community. I certainly do not have all the answers and there is no "One True Approach", but in general I am a believer in continuous communication beyond one's borders.

I'll try and describe in this blog entry what "continuous communication" means, its benefits and its challenges from my point of view. I'll try and be thorough, so if some of the time spent in definition is a bit tedious, I apologize in advance. I hope you find something of use for your own projects and that you can also add to the following ideas so that everyone, including myself, can benefit from new ideas and personal growth.

What Is Continuous Communication?

Continuous communication is a consistent application of information flow from within the project's core community, to its extremities and beyond into the wild unknown beyond the core members' awareness horizon.

(An "awareness horizon" is what you are able to perceive from your point of view. In communication the horizon is limited by the size and diversity of one's social network as well as the resources available to take in information from both the social network and additional sources of relevant information not directly a part of that network such as news organizations.)

The two key points are consistency and broad reach. People often fault on these two aspects of communicating their project's status either by communicating exclusively (rather than inclusively) to those close to them or by communicating very sporadically.

With continuous communication, the goal is to build an audience, keep an audience and increase your relevance within the topic(s) your work covers. By doing so, one can hope to increase the level of usage of your work, open new opportunities for coordination with others and be ready to not only address challenges as they arise but to avoid them in the first place.

How does it work?

"Are You Asleep?" And Other Questions You Can't Answer With "Yes"

States of inactivity are only identifiable to an outside observer by a lack of activity. A living animal may stay perfectly still and appear at first inspection to be asleep or even dead despite being quite alive. A sleeping animal has a hard time emulating a non-sleeping one, and a dead one simply can't emulate a live one.

That means that no visible activity, even if one is alive and awake, is often indistinguishable from a sleeping or dead entity. Given that there is no way for the sleeping or dead to say otherwise, the awake and living tend to assume the worst in those cases. Usually very little deeper investigation is done to see the actual state of the organism in question due to a lack of time or interest.

This is why the trick of "playing dead" works so well for animals that employ it.

When a project is kept "under the radar", it is for all intents "playing dead". Others will tend to assume that it is, indeed, no more. Those who did know about your project will tend to assume it has become an ex-project and go elsewhere, and those who didn't know about your work will remain blithely ignorant of it.

So what, right? You'll come back later with lots of news once your project is nearer ready for prime time! That plan rarely works, however.

Most People Prefer To Party With The Living

People will not wait for a project to magically (re-)emerge at some inflection point. That can be a harsh reality check as to our own importance, but it's true. People will find others who they perceive to be alive and well to engage with. Bonus points can be earned for being easy to approach and subsequently get along with, but to even get into the running one needs to be open for engagement.

In F/OSS projects engagement means users and contributors. It means other projects may end up cooperating with your project. More people will adopt it. More people will use it. More people will contribute to it.

Conversely, lack of engagement means people will stop using it. They will drop it. They will take up with other projects and make them successful instead.

It is, in fact, better to engage with others even if your project isn't quite ready because that will help you get the resources needed to get it to completion than to play it conservative and subsequently starve your project of resources. All that results from the non-communicative strategy is creating your own special island that nobody else cares about. If there are competing projects that do engage others, even if they aren't as good, they will eat your lunch.

To Make An Entrance, You Need An Audience

There's often the desire to make a big splash all at once with a Big Bang Announcement. We often see companies that product proprietary software do such things, after all. A common misunderstanding of this methodology, however, is that those Big Bangs is the meat of the strategy. But they aren't, they are simply the sizzle around the actual meat of communication.

Imagine making a grand entrance at a fancy ball. You dress up fabulously, have a great partner lined up to walk in with and you've even practiced your dance step. If you show up to an empty ballroom, it hardly matters. Show up when there's people actually there and you can have the effect you were hoping for.

One builds an audience by communicating with them regularly before (and after) Big Bang announcements. This is why continuous communication is so important: it ensures that you have an audience when you really need one the most.

Continuous, Not Constant

One quite understandable objection to continuous communication is one of resources: how much time and effort does it take? An important understanding is that it isn't constant communication, it's continuous. You really don't have to invest a lot of project resources into communication, the most important thing is that it's regular.

It is far more useful to have 500 words of text published at the start of every month for a year than it is to have 6000 words (or even twice that) published once and then having nothing said again for the rest of the year. Breathing, and many other bodily functions, happen every so often. They may not be completely predictable (it would be a bit odd if one used the toilet at 14:38 every day on the dot, for instance) but they tend to be expectable.

When communication can be expected, this helps others feel confident you exist, you're alive, doing well and that there's something to engage with. As a result, they will.

Communication Eases Discomfort

Sometimes communicating is uncomfortable. People may take what is said or written the wrong way or the may react poorly in response. These events are often kept to a minimum, however, when communication is continuous. A continual flow of information allows others to gauge how to engage with their own efforts in a way that will compliment your own as well as help avoid nasty surprises that lead to poor response. In this sense, communication is as much a preventative measure as anything else. In a big community like KDE, this is priceless.

There have been a few unfortunate incidents recently where one project runs broadside into another project's plans and creates a mess. These cases could almost certainly have been avoided through continuous communication from the earliest points of those efforts. An additional and important hint is that these same situations are being dealt with by practicing continuous communication between the affected parties and beyond.

You Don't Know What You Don't Know

There are projects who do an awesome job of communicating .. to themselves. Everyone currently involved knows exactly what's up, contributors are connected to each other and the milestones are being met. Isn't that enough? It could be, but often it isn't and usually it's certainly contributing to that project losing out on opportunities. The thing about opportunities is that they rarely remain unfilled; they are like vacuums: something nature abhors and which get filled whether or not you show up.

Another aspect of opportunities is that we rarely know what all the opportunities are until we start throwing out lines of communication and broadcasting. This reaches people who may be have or know of opportunities that were previously beyond the awareness horizon of the project.

If you think you know all, or even most, of the interesting (let alone possible) opportunities out there, you have a vastly overinflated view of your own knowledge, connectedness and insight. Unfortunately, this is exactly what some projects will claim and then use that as a reason to not engage in more continuous communication practices.

Being Part Of Something Bigger

Being part of something bigger like KDE gives us the opportunity to do something bigger with our smaller, individual efforts. When we go silent, however, it doesn't help the larger community and the various projects, even the ones who are communicating continuously. When communication happens, everyone benefits. We find new chances to coordinate and cooperate between ourselves an our collective reach is extended that much further as people outside of our community are able to more accurately measure the overall health and wellbeing of the community.

In many ways, it comes down to the "weakest link" principle: a project will often be measured by the lowest height achieved. It is often unfair, but it is very often true. One project's refusal to communicate will often reflect on others under the umbrella they share as a community.

A project doesn't have to be the shiniest or the loudest or the most sexy, but it shouldn't appear dead when it isn't, either. Some of the smaller and more niche projects within KDE do a great job of communicating on a regular basis and in my experience dealing with people from beyond KDE those efforts really do help a lot. It also gives us a way to bond better and have more fun as a community.

Limits

There are limits to all of this; the universe isn't perfect, after all. Continuous communication doesn't require perfection, just a reasonable amount of transparency that extends beyond the project's own borders at least somewhat demonstrated on a regular basis.

Sometimes we aren't allowed to say anything because of commitments you've made to others. Often one can find creative ways to communicate about related things that stays within the boundaries of those commitments, but if you can't such is life.

Sometimes we don't have the time or ability to communicate effectively. In that case, reach out into the community and ask for help to communicate. There are often people who are able to help out, sometimes much closer than we'd expect at first.

There are a number natural limits and potential blockers to effective continuous communication, but very rarely do they prevent all and any communication. Every project can do some communicting and, most importantly, do it on a regular basis.

Does Continuous Communication Work?

Continuous communication is not, by itself, a guarantor of success or smooth sailing. It is an important tool, but a project still needs to deliver on features and quality as well as be open and welcoming to newcomers. As a tool to achieve the benefits talked about above, however, continuous communication can be extremely effective.

If one looks around the current F/OSS landscape it becomes very apparent how much continuous communication plays a role in the success or lack thereof in a project. Take most any F/OSS technology category, be it a software project or a packaging effort, and compare the perceived front runner and the "also rans" in the category. Often a key difference is continual communication, sometimes to the point of making up for functional deficiency. It's also interesting to watch what happens to a project when it stops continual communication as a practice; they almost always slide off sideways into the proverbial ditch (though which comes first, the problems or the lack of communication, is often not clear).

Whether I can write about the topic convincingly or not, looking around the F/OSS landscape should help you decide for yourself.

So What Now?

If you are part of a team that isn't communicating regularly beyond your own borders, perhaps it's time to make a conscious effort to do so. Track what changes and improvements, if any, result when a regular practice of communication is put into place. I find it takes at least one release cycle to really get the hang of it and to see results start to emerge, so stick with it.

For the companies involved with KDE, I doubly urge you examine how you interface with the community and how the community interfaces with you. Be the good examples for others to look towards for guidance and help everyone reap the benefits of communicating early and regularly.

Read More

a use case for remote content

I've been meaning to follow up on Marco's blog entry on associating applications with Plasmoids. It's a really cool little feature, and if you haven't yet I really recommend checking out Marco's blog on it and checking out the screencast on youtube.

I don't, however, want to give the impression that this is a set of features that we've just been throwing into the pot only because the feature is cool. (Which, admittedly, it is. :) We usually do such things in Plasma with a purpose in mind, a use case. So here is one of our use cases for this set of features, and though many more such use cases can be generated it represents one of the primary driving forces behind this feature set:

"Plasma Pete is viewing his online calendar. Pete drags a calendar entry to one of his Plasma activities and he selects 'Event Tracker' from the menu that pops up (after Plasma has determined the kind of data that's been dropped, even though the data is from a remote source). The Event Tracker might even use Akonadi to show the information or it might just show a "web slice" of it. Pete notices that one of the events contains a typo, so he clicks on the 'maximize' icon that's right next to the configure icon in the widget's handle and up pops a site-optimized window that embeds his online calendar application. He makes the change, closes the window and the Event Tracker widget updates."

The ability to jump between widgets that display overviews and provide at most a small convenience interface to full feature applications (perhaps Event Tracker would launch Kontact, for instance), site-optimized containers for web apps or a generic web browser (and back again) will, we hope, tie the whole user experience together much nicer. This is particularly true, we feel, in more constrained devices / form factors such as netbooks but is also quite useful in the laptop/desktop space.

Enjoy. :)

Read More

Plasma: Where we are going

One of the great things about our semi-annual Tokamak developer sprints is that it's a great way for us to refocus our energies on the future. By doing so, we make sure that the path that our feet are on today is a good one. At Tokamak 3, several goals and vision clarifications emerged and I'd like to share them with all of you.

The Device Spectrum

Plasma has always been designed to make rapid development of small components with little or no bias towards where these components would eventually be used easy to accomplish. We have the Plasma Desktop Shell, but it is only a shell. It's sculpted to aid users of today's laptop and desktop systems, but it's evolving how we do that while not fixing the scope of Plasma those kinds of use cases only.

So now we have Plasma Netbook which is a new shell along with a few new components (Containments and Plasmoids) designed for devices that have smaller screens than the typical notebook computer but bigger than a phone which are used primarily in mobile and online scenarios. We do not believe that the full potential of the netbook form factor can ever be achieved by stuffing a desktop interface onto them and calling it a finished product. We're putting our code where our mouth is with Plasma Netbook, and relatively little new code has had to be written and nothing had to be rewritten to accomplish this.

So now we have Plasma that was only on the desktop broadening it's scope by taking a lateral step into netbooks. To us this is simply natural since we do not see the world divided up into form factor categories that are therefore their own completely separate worlds. The Linux kernel does not believe in this either, and so it runs across the entire device spectrum from small embedded systems to the largest supercomputers and everything in between. Likewise, Plasma aims to run on devices with user interfaces across a large spectrum. We also aim to work with devices Plasma can not or should not run directly on via things like Remote Plasma.

Applications As Decomposable Components

So much of what we are able to do, from broadening our footprint on the device spectrum to adding whole fields of new features to allowing "foreign" widget frameworks (e.g. Google Gadgets) to be hosted without hackery, are possible in large part due to having created a system that is unrelenting in its focus on components that run largely independently (Plasmoids, Containments, ContainmentActions, Coronas, Views, etc.) but also with rigidly defined relationships between each (which is why there are no Containments-in-Contianments and Applets-hosting-Applets is frowned upon except in very specific cases).

We remain committed to the idea of building our applications out of such components due to this success. It will continue to open new doors for our existing code. On a phone, perhaps each Plasmoid will run full screen, not to mention the power of Remote Plasma with such devices. As we continue to evolve the desktop experience, we can keep our previous years' work and just reshape the parts around it.

Components give us a fluidity in our movements and are helping to purge the need for rewriting.

The Network

The network is still underutilized by computers. Hooray for Web 2.0 and all that, but being able to send components between two computers in both structured as well as fairly ad-hoc manners is a whole new kind of world.

Being able to integrate online (aka "web") content directly into our primary user interface components is also powerful: no longer is the web a place we go to but it's what feeds our desktop, laptop, netbook, PDA and phone.

Being able to pull snippets or summaries from online content and then "zoom" them into site specific applications will start to pry the web browser as we know it out of the hands of users. Yes, web browsers are great .. for browsing. Plasma is doing its part to help free the web from the browser (where appropriate) as part of a bigger movement within KDE as a whole to accomplish this for our users.

The People

I got into software (instead of pursuing a natural science such as physics or neurobiology, two fields I seriously considered as a young person) because I realized that computers were communication devices the like we'd never seen before in history. They were the seeing stones from Tolkien's worlds, the doorway to the Oracles of Greek mythos and the embodiment of democratic discourse the American founding fathers could only have dreamed about. I still, though with some added maturity and probably a little more jadedness, hold to that idea.

The social networking revolution on the Internet has taken off in ways few if any could have predicted. Many in the Free software world, let alone KDE itself, are looking at ways to make software more people oriented, more social, more open to interaction.

So we're working on ways of opening doorways to online services with an emphasis on people and communication through Plasma.

Contextual Computing

"Who am I?", "Where am I?" and "What am I doing?" should drive the compass point of your computer. The map it navigates is the full set of data it holds: your files, your contacts, your dates, your interests. We want to allow the computer to adapt more to you as a personal artifact rather than make you fit it in some perverse "this is a mass produced item for a mythical human norm" concept. Nepomuk is key here, but so are things like geolocation and environmentally available components via Remote Plasma.

Organics and Beauty

It's an obvious one, but it's also important to re-affirm our commitment to beauty and organics. From subtle and useful animation to adhering to "how this would work if it were part of the real world, assuming the real world was more like a computer interface" is all part of it. So it attention to detail, and why we fuss nearly endlessly over various parts of the interface that "already work".

The goal is simple: create objects of desire that others measure their own efforts next to, that cause those who use it to smile and those who don't to covet them.

Choice

At the end of it all, freedom is an undeniable rock bed. All must be free to use, modify and distribute what we do. You need to be able to make Plasma what you want, whether you are an end user, an OEM, an entrepreneur, a KDE distributor, etc. We certainly can't make room for every imaginable feature or option directly within the software we ship by default (sometimes they run counter to core design principles, other times it's just a judgement call), but we don't try and destroy choice wantonly and ultimately the code is there for you to hack on. With the highly componentized approach, you also need to only work on the bits that you want to most.

Wow ...

I know, and so does everyone in our team, that the above is not trivial. There's a lot of ground to cover. It's big picture, holistic and scoped broadly. The above isn't marketing driven; if it was there'd only be three items in the list, more buzzwords and be easier to grasp in the form of a thirty second video. The above isn't an implementation plan, either; if it was, there'd be lots of discussion of milestones and definite feature definitions. It is, instead, our vision of the landscape around us as we see it. It is what guides our hands and feet as we build things, and it evolves over time as we do so. It is what allows us to measure how "Plasma" something is: it's not unusual to hear someone say "that's very Plasma" or "that's not Plasma" to describe something someone is working on.

Ultimately, it's our core project belief. By stating it we gain purpose and direction and even open the possibility for others outside of our little team to decide what parts make sense to them and how they might be able to work with us or us with them.

Personally, I wish that more KDE projects would have a similar "core project belief" that they can and do state publicly. It would help us all align even better, even when there are differences. It would also help challenge and shape the Plasma vision, likely for the better.

Read More

Plasma 4.4: Update on where we are

Back in July, I blogged about our plans for Plasma in 4.4. It's now September and the obvious question is: where are we now?

• Improve kiosk based lock down and deployment management: there is the new plasma-desktop scripting support, but action restrictions and more fine grained kiosk controls are not yet done. Let's call this one 50% done.



• More JavaScript: DataEngine support is in, but it's just the basics still. Full Qt/KDE/Plasma QScript bindings have been started with Amarok's Ian Monroe taking the lead on a Smoke-based approach. A QScriptGenerator based solution was tried but proved too resource heavy; after a discussion between Plasma and Amarok folk at Tokamak 3, we in Plasma decided to get behind Ian's project and see where that takes us. Help welcome! Let's call this one 25% done.



• Plasma Netbook: Plasma Netbook is now in kdebase, we have it running quite successfully on modest ARM based hardware (e.g. an 800Mhz ARM7 chipset) and cool things are afoot there as we work on improving and streamlining the interface both functionally and visually. Early reviews have been positive, and much has happened since then. We're certainly on track and then some with this one, even if 4.4 were to ship next week.



• Media Center Components: work continues on this with quite a bit of code already written. A plan for how and when to merge this into mainline is still missing and there is more work to be done. At least we have progress on the media center side, something that languished for the year prior.



• Remote Plasma: This works and is merged into mainline already. There's GPG signing left to finish so we can support the full range of TrustLevels we've defined (Invalid, Unknown, Valid, Trusted and Ultimate credentials), but otherwise this item is pretty well done and ready for 4.4.



• Pluggable Containment Actions: Works and is merged into mainline. There is one very small bug left but we have a patch that fixes it, though it requires Qt 4.6 which it looks like KDE 4.4 will require anyways. The configuration UI could use a bit more love, but it has also improved. As with Remote Plasma, this item is pretty well done for 4.4.



• Widget Explorer: The new widget explorer is much more Plasma in its nature and is also in mainline already. There are a few points of integration still missing, but the holes are filling in quickly and the results are nice. It's particularly good for Plasma Netbook and will be as well for Plasma Screensaver Overlay when that integration is completed.



• Improved KWin Integration: Slide in/out effect is now in KWin and we're working on a new Activities Overview interface that will also work better with KWin. Plasma Netbook and KWin also have been working on common needs. This isn't an item that can even really be considered "done" as much as it can be considered to be "where we need it to be right now", and we're getting closer and closer to that. It's certainly already improved of KDE 4.3, thanks to both the Plasma and KWin developers. Eventually, I'd like to see a new "composited window manager features" specification so Plasma and other window managers can work really well together and so that we have some documentation of all these tricks as well as opening them up to usage by non-workspace applications. Sort of a "EWMH" for the next generation.



• Plasmate: Git integration works and you don't need to know anything about revision control to use it, projects can be created and edited, plasmoids can be previewed ... it's coming together. Still more work to be done before it can go into mainline (either kdesdk or into extragear; still not sure which :), but major progress has been made already.



• KUIServer Resurection: This has been completed and it works. Now jobs can outlive Plasma and be viewed by other apps (e.g. Konq/Dolphin in the future?) simultaneously. Some glue and string left to put into place, but generally ready to go.



• Notification Improvements: Some, but not all, of our goals here have been completed. Queue control and logging are still open, but things like close buttons on all notifications (including ones with actions) and obeying the Persistent flag are done. More to do, but already improved over 4.3.



• Kinetic: There's a patch on review board for this. It needs some more work, but recently two other developers joined in and I hope to see it in mainline soon along with a good number of effects. We already have kinetic scrolling in mainline, in fact, which is great for the organic feel (one of the Plasma goals) as well as touchscreens.



• Plasma Desktop D-Bus Access: This one is currently on hold. It probably still needs to be done, but the ability to control plasma-desktop using Javascript really makes it less of a priority, and exposing plasma-desktop naked on the bus is a little scary from a security POV.



• More KRunner: Not a whole lot of KRunner work as of late, but small improvements including someone appearing with a Kopete runner among others. KRunner always seems to develop at a slower pace than the rest of Plasma, but it does get new features and increased stability with every single release.



• Plasmoid Updates: This is still pending the Get Hot New Stuff improvements as well as some of our own security work related to signing and Trust Levels.



• Notification Item Goes Prime Time: KNotificationItem is in libkdeui now so any KDE based app can safely use it. The team is busy getting more and more KDE applications to do so by submitting patches to various developers of applications in KDE's svn via review board. We've also submitted a draft specification of the full system to freedesktop.org and a lot of good review has resulted. Things like making sure it works properly between machines with different endianess really only happen with such scrutiny. We're now working on ways to allow applications to associate Notifications with their Notification Items, which means instead of one massive list of notifications we can converge notifications and system tray entries and even buttons in the task bar. So while this one is at 100% as far as our KDE 4.4 goals are, we're continuing to build further on its successes to date. We're still looking for other projects such as GNOME, Enlightenment, XFCE, LXDE, etc to start picking it up as well; until then, only KDE 4 will let you escape the dark ages of the system tray and enter into one where you can do magical things like have a 16 pixel panel where everything fits and uses your selected icon them. ;)



• Improved Documentation: This is improving, albeit slowly. We're doing much better at documenting the things we've added for KDE 4.4 than previous releases. Then there are things like the new "how to do $THING" animated micro-screencasts that have popped up. It's all an ongoing effort, however, and can really use more hands on it. It's also something one can do even if they aren't a hard-core developer.



• New Configuration Dialogs: the global Plasma theme settings are now to be found in System Settings alongside the widget style selection and the Activity and wallpaper settings dialogs have been split out as well. Other improvements to various widget's configuration also have been done. More work? Yep. Lots accomplished already for 4.4? Yep.

That wraps up what I covered in the Plasma in 4.4 blog back in July. As usual, however, other valuable things have popped up as well. What kinds of things?

The device notifier in 4.4 will no longer require a pop up dialog when there is more than one action (they appear in-line in the notifier widget) and will support greater control over what's shown (e.g. not just hotplug devices and a show/hide of individual items that mimics the Places view as seen in Dolphin and the file dialogs).

The system tray can now aggregate full Plasmoids alongside Notification Items and legacy System Tray Icons. Plasmoids offer more flexibility and greater integration possibilities within Plasma as a whole, with Notifications Items being easier to talk to from external applications and legacy icons being, well, still just annoying. ;)

You can drop remote content onto a Plasma surface and the right things just happen, including setting of wallpapers.

Lots of improvements to Lancelot have been made and the Network Management widget progress is very nice as well. The Online Knowledgebase widget is also in mainline now and others are waiting in the queue. We're examining ways of teaming up with Qt Lively and extending our reach across the device spectrum.

Large numbers of bugs, performance bottlenecks and mis-features have been addressed and a good number of those have been backported for subsequent 4.3.x releases.

So it looks like 4.4 will be yet another massive release for us in Plasmaland. It's not 100% smooth sailing everywhere all the time, to be certain, and we're getting ever better at being agile enough to alter course when and where needed. It's a wild ride, and 4.4 will be another great pit-stop along the way.

Read More

Dropping remote content and wallpapers

Today Sebas and I put the finishing touches on a couple of neat features and I felt compelled to share them with you via screencast because together they are just that cool! ;)

The first feature, which is mostly thanks to Sebastian (I just did some janitorial work on the patch), is the ability to drop remote content onto a Plasma::Containment such as a desktop activity or a panel. Plasma, via KIO, tries to figure out what you are dropping and then offers a set of matching widgets, if any, to create for that content.

Dropping HTML? Get a web browser widget or a link to that page. Dropping an image? Get a picture frame or an icon pointing to that image.

What happens when you drop something that one of the wallpaper plugins understands? Well, you get an entry for that wallpaper in the resulting menu of choices. That means you can drag an image from a remote system, say off a webpage, and it will download it and set it to your wallpaper. Each wallpaper plugin can define what kind of data (mimetype) it can accept, so this feature is completely dynamic depending on what wallpaper plugins you have installed. That's quite a bit more flexible than what we had in KDE 3, where the drop file types were hardcoded inside of kdesktop.

So that's one new and cool feature (remote content drops) combined with one (improved) feature many people have been asking for (wallpaper drops).

Interestingly, I told several people (including people at distributions) how a patch to do the wallpaper drops would look like. In spite of many people insisting that this feature was of imminent importance, nobody sent in a patch even though the "how" was spelled out in detail. Finally, I got around to implementing it at Tokamak 3 one evening after someone mentioned it on IRC. I was too tired to work on anything serious so I figured I may as well implement wallpaper drops. The "moral" of the story is that I'm happy to help you with the "how" of writing a proper patch for a given feature, but if you don't do it then you'll have to wait until it rises to the top of my priority list which may be, depending on the feature, unpredictable.

Without further ado, I give you "Dropping Remote Images To Set Your Wallpaper" via blip.tv (where there is also an OGG video version available and waiting for you):

Read More

Spiffying up the interactive console

Since people quickly jumped to various questions about the look and feel of the interactive console, I figured I'd give a small update today about it. After working on a few things around it, I ended up implementing the buttons as actions, a toolbar and using a text editor part if available (and falling back to the plain text editor widget if none exists).

It now looks like this:

As you can see, there are some issues with scrollbars and I still need to do things like turn on line numbers and what not. Code folding and syntax highlighting goodness are all there now though.

If anyone would like to do up a Kate syntax highlighter file for the plasma-desktop scripting, that would be truly awesome. The syntax description XML dialect is described here and the plasma-desktop additions to the standard ECMA script runtime are here.

Read More

scripting plasma-desktop

One of the (many) goals for the Plasma project in KDE 4.4 is to make management of the Plasma Desktop Shell (plasma-desktop) easier by introducing a power tool: an ECMA Script environment.

Sys admins, KDE distributors and power users can now write small ECMA Script snippets and execute them in the new interactive scripting console:

They can also be put in share/plasma-desktop/init/ to set up Plasma layouts on first log-in (or whenever there is no existing configuration) or in share/plasma-desktop/updates/ to alter the plasma-desktop configuration on its next start.

I did up a screen cast to show some of the things that can be done, which you can watch on BlipTV (OGG video version) or in the embedded player below:

The current API can be seen here and I'm looking for input as to what else to add. For instance, in the current plasma-desktop defaults we check to see if there are any batteries by asking the battery dataengine; that's currently not possible in plasma-desktop ECMA Script environment, but would be pretty easy to add. What's there now is what I consider the bare minimum to be useful (and it's a fair amount already), but I know we'll need/want some more things in there. Your input, particularly if you are a sys admin or KDE distributor, will be instrumental in helping put together the list of use cases the scripting needs to accommodate.

In other Plasma news, you can now drag-and-drop images, or any other file that a wallpaper plugin might in future support, to the desktop and have it become your wallpaper.

Both of these features landed during Tokamak 3.

Read More

home

I'm back home in Vancouver (still sounds odd to say that) and am currently sitting in the upstairs office trying to stay awake (damn you, timezones and the jetlag you induce!) and get some work done.

I started the day by stumbling about the house, opening my eyes a bit and then phoning S. to chat a bit this morning. Then P. came over (his mom though I wasn't getting back to this afternoon, so was a bit surprised when I left a message on her phone last night) and we fell back into the usual routines.

I still have to get to the grocery store for some provisions as well as deal with a handful of issues that arose while I was away (including my car developing a small problem which make it unhappy but which was fixed without much hassle and finding out why my landlord still hasn't replaced the old appliances). Such is the never ending stream of things to deal with.

Before I head out to run some errands, though, I popped an external disk onto the Mystery Device which I'm now referring to as "ARM, M.D." in my head (small things amuse me). After some great success with the thing at Tokamak 3, I talked with the people I got it from to figure out how to move it to the next step. The build approach we were using (and by "we", I really mean Artur :) was something we came up with at the moment lacking a proper SDK for the thing. The response was: build stuff on the device itself. Ermmmmmm...

Needless to say, it doesn't exactly have the disk space I need to compile on nor does it have a processor capable of making binaries in reasonable time frames. So I installed icecream on the device so I can actually compile at a reasonable speed using other machines here in the office and added .5TB of storage to it via USB. I half expect this thing to be building for much of the remaining week. It's sort of like going back to my first KDE dev machine: a PII 400. At least while it's compiling, I don't have to pay much attention to it and can do other things.

It is impressive how the machine doesn't get even warm in the least despite being in a small little box with no fans.

Aside from that, I managed to implement a small feature in Plasma::RunnerManager for Ivan so he can clean up some remaining TODOs on the Plasma::Runner integration in Kickoff's search. I also got out a good amount of email and read through the article that Sebas will post tomorrow about Tokamak 3 on theDot. Thanks to Sebas efforts combined with all the proof-reading and fact checking done by Jos and the crew on plasma-devel, it should be a pretty good read. Huzzah!

I have one more feature to implement in the Plasma Desktop Interactive Scripting Console (PDISC! Acronyms are falling from the sky today!) before I can do a proper screen cast of it. It's already pretty interesting what you can do with it, but I figure I may as well wait and show a fully functioning battle station when all that's left are a few laser cannon turrets. Or something like that. Maybe I should try to sleep a bit first. ;)

Read More

tokamak 3 on the home stretch

We've been in Randa for nearly 5 days now and it's been a spectacular experience thus far. Some of the attendees could, understandably, only stay for part of Tokamak 3. A week makes for a long sprint and some could only stay for three, four or five days. Some have already returned home due to work or school requirements. Most are here for the whole thing, however.

Our daily nature walks have given us not only breathtaking mountain views but also time to discuss what we are working on without the distraction of our email and music players and build some team bonds. One day we built a small dam in a river as a group. With half an hour of physical work, we had quite a nice little stone wall. It was an interesting exercise in working together and fun on top of it.

The entire environment here has been quite interesting. We've made our own bread twice a day and different people have taken turns doing this daily job. Dishes and basic chores are also part of the routine here. It makes it feel more like a family living together rather than a bunch of people just working together.

Of course, it's not all walking in mountain forests, wading in streams, drinking wine in the evening and baking bread ... we've also been insanely busy here with the code.

We've talked about future features and existing flaws in Qt with Qt developers. We've merged three different GSoC branches: remote widgets, widget explorer and KAuth. We've done profiling of Plasma and increased the speed of various things, sometimes radically: job tracking for file downloads will take virtually no CPU in 4.4 and very little (though a bit more) in 4.3.2. We've worked on context and integration with Nepomuk; better activity management and integration with KWin. New work on WebKit based technologies in KDE 4 has made leaps during our time here. We've put KDE 4 on a small ARM based device and, with Qt 4.6, Plasma runs really smoothly; compared to Enlightenment EFL apps on the same hardware, the performance is at least comparable. In fact, zooming out and in of Plasma is faster on that device with Qt 4.6 than it is on most of our latops here with Qt 4.5. Desktop theme settings have been moved into system setting and the background and activity settings streamlined. Mouse plugins are working smoother and JavaScript control of plasma-desktop has improved greatly. Control panels can now execute actions very easily with greater privileges, finally filing in the gap that removing "Admin mode" left, with a cross-platform authentication system backing it up. (On Linux it uses PolicyKit in the backend; backends for other platforms are needed, though.)

A full report of everything we've done (yes, there's even more!) will appear in a story on theDot once we're done here. We've even made a few videos of people here showing what they have been working on.

At the end of this week, we will be leaving no doubt a bit more tired than when we arrived, but we will be a stronger and more tightly knit community for it. (We were joined by Markey and Mamarok today, too!) Plasma and other parts of KDE will have jumped forward another set of leaps as well to the benefit of every one of the people in our community of users and contributors.

It was a bit expensive to bring people from Brazil, Canada and all over Europe here for a week, but it's paid off tremendously. It has been the perfect setting for our projects and our team.

I am left wondering, however, what language "HE HAKPbIBATb" is. I know it means "do not cover" or something like that, but it's the only one of the 9 languages I couldn't identify on the radiator in the bathroom. ;)

Read More