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.
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.
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.
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:
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!
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.
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.
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.
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! :)
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! :)
