Qt in education

I came across a really nice blog entry by Hanne Linaae entitled Teach Qt!. That led me to the Qt course materials and I grabbed a few of the course material sets.

When I settled in to look at the first one I was very pleased to see three things:

• They are creative commons licensed, allowing for broad usage


• There are PDFs and PowerPoint formats, yes ... but there is also an ODF version in there


• KDE is mentioned a few times, including getting its own slide in the intro slide deck with a pointer to Techbase

The course materials look really good and the approach seems solid. Nice work Qt people! :) The more educational materials and documentation we can have around the Qt and KDE ecosystem the better.

Read More

four point six

another january, another awesome release

read all about it at dot.kde.org

Read More

kdeexamples moves to git!

My KDE hero of the day is Nicolás 'PovAddict' Alvarez who dove into the KDE Examples module and turned it into a git module, complete with history even of the examples that existed prior to the creation of the KDE Examples module intact! When I queried Ian Monroe the other day about how much work it would be to migrate this module over, Nicolás simply jumped in and attacked the problem with the usual KDE gleam in the eye.

The sys admins were also as usual right on the ball and the server-side stuff was set up very quickly. Did you know that they now have a repository request form that makes it even easier? It's brand new, and I didn't even know it was there until Tom Albers pointed me to it.

The result is that you can find KDE Examples on projects.kde.org and clone it with "git clone git://anongit.kde.org/kdeexamples" or (for read-write access) "git clone git@git.kde.org:kdeexamples".

This module is open for all KDE libraries and applications that wish to offer example code to help other developers get up to speed quicker. If your app has plugins, KDE Examples is a great place to host an example or three. If you publish a library, KDE Examples is the perfect place to show how it can be used. In fact, just last week I used the Attica example in KDE Examples to quickly figure out how to use it for my Hot New Stuff needs. It really works! :)

Something I'm really looking forward to with kdeexamples being in git is that I can now very easily have local branches where I keep variations on the Plasma examples that I use for testing Plasma features while I work on them. These modifications are not usually suitable for pushing to the main repository as examples: usually it's just uglifications and debug spewing to meet my testing and debugging needs. With git it's so much easier to keep all that straight and tidy.

Oh, and the repository now takes 1/3rd the space on disk: 3 vs 9 MB. Win.

Read More

thinking about library modularity

It'll be a topic at Platform 11, it's a topic that is ever more important KDE developers working on constrained mobile devices, it's a topic that app developers moving to or already using Qt are wondering about more and more: How modular are KDE's libraries?

The short answer is this: more than they used to be .. but with a lot of room for improvement.

We have a growing number of libraries that only depend on non-GUI parts of Qt such as KDECore, Solid and Attica to name three off the top of my head. We have more than only rely on Qt and no other KDE libraries. This is rather better than the "big glop" of libraries in kdelibs in KDE 3.x days. Are we getting the most out of this? Sadly, not really.

Here are three avenues of thought for those of us involved with writing, maintaining and/or packaging KDE's libraries to consider that could help improve things:

Packaging With More Modularity

While most of our downstream packagers tend to split up applications into separate packages, KDE's libraries tend to come in big chunks that reflect the source packages. On OpenSuse, the distribution I'm using, there are two main packages: libkde4 and kdepimlibs4. The both contain large collections of libraries that are vaguely related to each other. The downside to this is that if a Qt app developer wants to use Solid, they end up having to pull in all of libkde4.

Open questions:

• What can KDE library developers due to improve this situation through build system or module layouts?


• What information or other help for packager would help drive more modular packaging?


• What libraries are most worth modularizing into their own packagers for application developers?

Identifying and Justifying Dependencies

Even if libraries were split out more efficiently, there are some interesting limits to that right now due to dependencies between our libraries. In the "pre-4" days we really didn't pay much attention to inter-library dependencies, nor did we have many good reasons to do so. Today, with a more modular Qt, a growing Qt app ecosystem and targets like mobile, we now do have some pretty good reasons to do so.

Let's take libsyndication as an example. libsyndication is the library used by applications such as Akregrator and Plasma DataEngines to fetch and process RSS feeds. It depends on KIO, a library which pulls in a fair number of dependencies with it. If we examine what it uses KIO for, we find out that KIO is used in just one file: dataretreiver.cpp. Within that file, it is used for one purpose only: to fetch feeds over the network, usually (exclusively?) it seems via http. It would be possible to use QNetworkAccess for this instead, which would use KIO in a KDE Workspace, turning KIO into a runtime dependency driven implicitly by the user. Without those few lines of KIO usage, libsyndication would only require KDECore, QtCore, QtNetwork, QtDBus and zlib.

Combined with more modular packaging, this would open libsyndication to a much broader Qt app development audience, with no loss of functionality. Of course, libsyndication is just one example (it came up in an email conversation with a Qt and Gtk+ app developer last night, actually). How many other KDE libraries have similar unnecessary dependencies?

We don't want to sacrifice integration or functionality, but there seems to be a lot of possibility here. How many can we identify? How many identifications can we turn into realized improvements?

To Split, To Aggregate?

Another avenue for exploration is the lines along which our libraries are split. In working towards the first version of KDE Platform 4, we re-arranged the classes in KDECore and KDEUi so that KDECore had not GUI dependencies. This brought a very nice division of tasks between the two. There is so much more opportunity for this, however.

KDEUi itself is an interesting, though highly complex, example: it has all sorts of useful UI bits in it, some of which are applicable to QtQuick applications and some which only make sense to QWidget based ones. Is this an opportunity?

Nepomuk libraries in kdelibs combine both data and user interface elements: does it make sense to split that into two, so more Qt apps could take advantage of Nepomuk with fewer dependencies?

How about libplasma, which has a number of both data and user interface elements in it? It's still an unresolved question as to whether we'd gain anything from splitting out the data elements (DataEngine, AbstractRunner, etc) from the user interface bits, or along which lines such a split would actually happen. It might make more sense to cleave it into "QtQuick-appropriate" and "QGraphicsWidget" parts.

This becomes a balancing act: too many libraries and load times go up; too many libraries and maintenance of the code as well as of packaging and building goes up; too few libraries and the audience decreases due to lack of clear focus and odd dependency chains.

... and more?

There are indeed more topics to mull over, such as the relationship between kde-runtime and kdelibs. What goes into kde-runtime and what goes into kdelibs is pretty well defined these days: build dependencies go into kdelibs, runtime dependencies go into kde-runtime. However, when it comes to dependencies and use cases between these two modules, what then?

Or how about the icons situation: we have a large chunk of very high quality icons .. but do we need to install them all together, or can they be modularized as well, e.g. into "in the icon spec", "also needed by kdelibs", "needed in the workspace" and "used by specific apps"?

How do we best prep the KDE Platform for QtQuick? Several parts of that answer were worked on at the recent KDE Mobile developer sprint, and we have code to show for it. Where do we go from there?

If you are a library developer, a packager or an app developer: what topics related to modularity can you think of?

These are the kinds of questions that swirl around the exciting life and times of a KDE library developer. It's the kind of querying we'll press upon ourselves in the amazing alpine environment of Switzerland's Valais region in June. Our work in 2011 will be tinted by the answers and ideas that sprout out of these lines of thought.

If you've ever pondered getting your hands dirty and your feet wet (or other body-in-substance metaphors ;) with KDE platform and library development, there's probably never been a better time to do so. For the curious, we coordinate most day-to-day development of the libraries on kde-core-devel@kde.org, use the "kdelibs" group on reviewboard.kde.org for patches and hang out in #kde-devel on irc.freenode.net.

For those of us already foot, knee, waist or neck deep in the code, we owe it to our selves, our code and our users to think about the above and take action to push the state of our art. It's a path to more users of our libraries (which also means more contributors!) as well as a way to embrace more of the Qt ecosystem and in turn be embraced right back.

Read More

Platform 2011 sprint update

I'm helping arrange a KDE development platform sprint that I've been referring to, rather unimaginatively, as "Platform 11". (I admit I've been tempted a few times, in the name of general irreverence, to change the name to "Platform's Eleven" and show up as George Clooney minus the good looks and money. ;)

We have a location for it now as well: Randa, Switzerland. If that name sounds familiar, that's because we held Tokamak III there. It's so beautiful, we just had to go back. Ok, and having Mario offer to host it along with two other sprints helps. (Mario is a superhero of developer springs; I think that KDE e.V. should sponsor a superhero costume for him: Sprint Man! But no capes!) Mario being in Zürich is also a bonus, as it will make it easy for me to collaborate with him on logistics starting in March. The sprint is currently scheduled to take place on the first week of June.

There is the usual sprint planning wiki page for it and the number of people who have already signaled interest is great. I want to see a good mix of kdelibs hackers, packagers, developers and our key partners such as Qt devs there.

What is the goal of this sprint? To lay down a near-future practical roadmap that covers the next 2 or so years of development for kdelibs, kde-runtime and our engagement of the platform ecosystem around us. Getting down to work will also be important, so that we can leave not only with plans but also something to show for it all, even if it is just early steps, in the source code.

The participants will ultimately end up driving the actual topics and direction, let alone the conclusions, but here are the points likely to be hot at this sprint:

• Modular, Baby! Did you know Solid only depend on QtCore? What other dependency chains can we streamline? How can downstream packaging strategies shift to reflect these changes so more app developers can take advantage of this progress?


• Mission: Platform Profiles In 2010, we began the work of creating target platform profiles, particularly to differentiate mobile, tablet and desktop usage of the libraries. We have a lot more knowledge of the internal and external needs after this early effort, and need to take it to a compelling milestone.


• The Orphans of 4.0. Some areas of kdelibs did not get the API and design love they deserved, and other libraries got, leading up to 4.0. KIO is one such library. We need concrete plans for them.


• Embracing and Extending Qt Ok, that's a phrase that's most often associated with nefarious plots to do nasty, predatory things to other people's technologies. In this case it's completely friendly, however. We have a number of open questions regarding the role of KDE's libraries and Qt, how to best roll in things like QtQuick effectively without it feeling like a tack-on, how to identify and limit duplication between Qt and KDE libraries, etc. There are many opportunities here to broaden our reach, gift more app devs with ever better tools and help make Qt rock harder. (Relevant to recent bits of news: I've already invited dconf-qt devs to join us for this part.)

If that doesn't sound exciting and challenging to you, you probably aren't a library developer. ;) To me, however, it gives me that feeling I get when at the top of a roller coaster hill: excitement mixed with a little stomach churn. It's going to be an amazing ride.

To get involved, please add your name to the wiki page. If you have already added it, please make sure that it contains approximately how much it will cost to get you there so that I can do up a budget for KDE e.V. to take under consideration. I do need to start adding more meat to the bones of that wiki page as well, and will do so over the next few weeks. I'll keep you all posted.

Oh, and we need a kick ass logo for the event, too. Preferably with a George Clooney reference in it. Ok, maybe not. We do need a logo, though. ;)

Read More

Qt acceptance growing, next: colaboration process?

As some of you probably have already seen on Mark Shuttleworth's blog, Canonical is embracing Qt. They have even started developing apps in-house using it, such as Unity-2D, which is great.

Within KDE, we've long espoused the idea that the user doesn't care what tools the developer uses and that we should be working to give them the biggest and best choice of applications that work together well. Seeing others, particularly groups who have historically taken rather heavy-set stances that worked against that, start to come around more and more to the idea is good for Free software and our users.

There is still work to be done, however. Mark suggests that Qt developers should start using Canonical's Qt add-on libraries for things like dconf so that Qt apps integrate properly with Ubuntu. This is not that much different from saying that Qt apps should just use Gtk+ for rendering so they fit in better, just doing so at a different layer in the stack.

One of the great strengths of Qt, and something that KDE benefits from greatly, is portability and the wide availability of common infrastructure as a result. We've done a lot of work to make Qt and KDE apps work well on all sorts of platforms. This has taken the form of Qt Platform Plugins, porting Oxygen to other platforms, dialog button awareness, Qt's NetworkAccessManager and much more. Part of the "much more" has also been standardization, of the "weak" sort where it's more about conventions and sharing than strict ISO/ECMA-style standardization, of tools and protocols in use, often aided by freedesktop.org.

To get applications working together as well as possible, the answer is not to start creating Ubuntu-targeted versions of Qt apps, but to work on the issues below the application developer's line of sight. If settings are an issue, then there are two avenues that should be pursued: identification of which settings ought to be widely shared and identification of management processes that ought to be shared. The former can be approached through standardization if nothing else, and the latter is probably a technology problem.

Solving this means working together, not thinking that we are individually capable of coming up with the best ideas ever and that the world should simply bend to our whim of the day. That is a strategy fraught with risk and is socially unrealistic given the number of stakeholders.

There are ways to fill in remaining gaps such as configuration related issues that are well within our combined reach, and which we remain quite motivated to continue to fill in. KDE has led the way in not just helping define standards (including ones Canonical now uses), but adopting ideas from the outside (just look at all the freedesktop.org initiatives KDE Platform 4 uses!), working with others on specs (including things like integrating dbusmenu with StatusNotifiers, something Canonical and KDE worked on together to make happen) and working to improve the mechanisms by which such standardization happens. We're open and wanting to work with others, and Free software users would benefit from as many in the Free software ecosystem adopting a similar approach.

As more groups warm to the beauty that is embodied in Qt, I hope that the message of working together (rather than dictating, for life or otherwise) also spreads. That mode of operation is what got Qt and KDE Platform, as high quality developer tools, to where they are today. It is what motivates us to look at the development platforms we build for application developers and ask ourselves, "How can we make this as painless as possible for the developer while giving them access to as many platforms as seamlessly as possible?" It's a way of thinking that helps create a superior result, and we're always looking for new ways to expand the benefits it brings.

Read More

synchrotron update

Synchrotron, an OCS-compatible web service that makes it easy for upstream to push application addons and updates to them to users, has reached another couple of milestones.

First, it has its own project page on projects.kde.org and it has moved out of my personal scratch area and into playground. From here, I hope to submit it to the KDE Review process and have it out of playground sometime in February.

Second, the shared sources repository also is up on projects.kde.org and is starting to get populated with addons. I added a README to it so others might be able to figure out how to add their own feeds and addons without needing to find me on irc or by email, and the KDevelop team used that to add a feed for library help files.

This leads to the third update: synchrotron can now be used to point to downloadables that are hosted elsewhere. This was driven by KDevelop's massive qch files which are already hosted on api.kde.org. Instead of duplicating all that in the Synchrotron sources repository, there is a new directive that can appear in the metadata file: X-Synchrotron-ContentUrl. It took all of 10-15 minutes for the KDevelop hackers and myself to figure out what would be a "best case scenario" type solution and all of 5 minutes for me to implement it in Synchrotron.

I'm not done yet, though! Besides working on getting Synchrotron ready for KDE review in the next week or two, I will also be putting up a testing/staging install of Synchrotron for developers to work with and test their apps against. I will probably make it track a branch of synchrotron-sources so that new feeds can be set up and tested live without actually appearing on the shared Synchrotron install immediately. The goal is to have this up by end of Sunday (tomorrow) my time (PST).

The README file currently in the synchrotron-sources repository will eventually be transferred to Techbase in the Tutorials area, but I'll hold off on that until I've found a permanent home for a shared KDE Synchrotron. I've already had some offers for homes, but I want to coordinate with KDE Sys Admin first.

If you have an application hosted in KDE's svn or git and would like to take advantage of Synchrotron, please simply add an entry to the synchrotron sources repository. There's no need to ask for permission to get started, but I'm always around to answers questions you might have.

Also, if you'd like to hack on Synchrotron itself, we'll have a review board install for it up very soon, but even now I'm happy to receive patches by email. There's a TODO file in the Synchrotron repository with a number of things that can be tackled.

Finally, Synchrotron isn't KDE specific in the least, nor does your KDE app have to share a Synchrotron with every other KDE app (having a shared install is really just more for convenience). It's rather easy to set up a Synchrotron instance somewhere, as the INSTALL file in the Synchrotron repository outlines, and all you need on the other side is something that speaks OCS. For Qt applications, the easiest approach is probably to use libattica, but rolling your own shouldn't be too hard, either.

Enjoy. :)

Read More

plasma desktop scripting API updates for 4.7 release

I've been adding useful bits of API to the Plasma Shell Scripting with every release since it debuted. The Plasma Workspaces 4.6 release slated for this month will have "API version 3", which is backwards compatible with all previous releases and adds the following:

• theme: read/write string containing the name of the desktop theme to use for the interface, e.g. default, Air, Oxygen, etc.


• multihead: read-only boolean, true if the system is running with multiple screens in a "Xaphod" multiple display server configuration


• multiheadScreen: read-only number which, if multihead is true, contains the (real) screen id of the current screen

Not tremendously exciting, but that's because we don't add random bits of API hoping that they could be useful to someone, somewhere, sometime. When we find new use cases, either due to our own use of the API or because someone else who uses it (e.g. distro packagers, power users...) sends us an email or files a feature request, we examine them for validity and how best to service that need.

Even though 4.6.0 isn't out yet, we already had a backlog of items for 4.7 since we got a small raft of requests after the feature freeze for 4.6. I implemented them all over the past few days, however, so API version 4 will also include:

• boolean applicationExists(String name)


• mixed defaultApplication(String kindOrMimetype [, boolean storageId = false])


• String applicationPath(String name)


• String dataPath([String type[, String path]])


• Array[String => Array[String]] knownWallpaperPlugins()

As usual, they are all documented in full on the Plasma Shell Scripting page on Techbase.

Those following development in trunk can try out the new API right now and feedback is quite welcome. If you have a use case that isn't being met by the current API, please let us know sooner rather than later so that I can schedule them for the 4.7 release.

Read More

light up the synchrotron

There was quite a bit of constructive feedback from my blog posting the other day about Synchrotron, my recent pet microproject to make it easy to create and maintain OCS feeds for application addons, and so I thought I'd spend a few minutes sharing some of the feedback and thoughts with you here.

Let's start with the whimsical: Parker Coates suggested this song by Canadian alt-rockers Carbon Dating Service as the theme song for the project. Who knew there'd be a song called "Light Up The Synchrotron"? Awesome.

On a more serious note, some asked as to the security of the service. Well, it's pretty simple: All data sent back in response to requests comes from the PostgreSQL database. All requests are written to be safe against things like SQL injection. If someone managed to find a way to do something untoward with the SQL queries, the scripts that power the public API use a database user with read-only writes to the database with one exception: it can insert rows into the IP access time log table. This (nearly) read-only user can not delete or update anything in the database. PostgreSQL just rocks in how easy it makes to add and manage a layer of security right inside the databas itself.

Other than this database access, the public API scripts do not touch the filesystem at all. So I'm pretty comfortable with it, though I'm still very much interested in people actually looking at the code, however, to ensure everything is indeed in good shape.

Speaking of which, I forgot to mention that there is a TODO file as well as some sketchy documentation in the repository in case you are wanting to get started on something. We also started up the respository for the actual addons where we are starting to collect items.

A few people asked if Synchrotron could replace kde-look.org or kde-files.org and the simple answer is: "no". The reason is that Synchrotron is not meant to allow for uploads and sharing of content by users. It is quite specifically an upstream tool. It's designed to make our lives as upstreams as easy as possible, in fact, but this makes it rather useless as a public file and data sharing hub. In theory it's possible for Synchrotron to be extended to be such a thing, but I have zero personal interest in that. :)

Something I do have interest in is using Synchrotron as a component in some larger projects that have been waiting for attention for a while, such as Plasma Classroom. So I do hope to reclaim the ~2 days spent on this project many times over.

Finally, Josef Spillner pointed out to me that there is the Hotstuff project that he started back in 2004 that strives to do some things similar to Synchrotron. Indeed, this was the project that helped birth the whole Get Hot New Stuff feature that can be seen in many KDE applications today. Sadly, I wasn't aware Hotstuff was still active and a viable candidate, as the last time I'd had a discussion about it I was left with the impression that the Hotstuff server wasn't really being kept up. Hotstuff is written in Perl, which is even less my language than PHP is, and is significantly more complex (and so probably does all kinds of nifty things Synchrotron doesn't); I'd probably still be struggling away by now instead of having something that works if I'd tried to go with Hotstuff. Still, Hotstuff is an interesting bit of software, it's been there for quite a while (nearly 7 years!) and Joseph is still interested in the Hotstuff code. So if you find Hotstuff to be something more like what you need, please get a hold of Joseph! :)

For that matter, if Hotstuff gained the features of Synchrotron and was easy to install/maintain, I'd probably drop Synchrotron for it myself. Necessity, however, is indeed the mother of (re-)invention. ;)

Read More

fire up the synchrotron!

Over the Christmas holidays, I spent some time coming up with a solution to a new challenge we have been running into in Plasma, and which I suspect other KDE teams may be as well: quick and easy deployment of application addons.

An Overview of the Problem

An increasing number of Plasmoids are relying on web services that we don't control: share (nee, pastebin), weather, public transit, remember the milk, etc. etc. When these services change (which they do randomly, web developers seem to have very little awareness of service stability) our users get stuck with Plasmoids that don't work. We've been working on making the Plasma components that rely on such webservices scriptable so that it would, at least in theory, be easy to post updates that anyone could install on their system. Artur recently made the share DataEngine use Javascript for this, just like the comics and some other DataEngines have done for a while.

Similarly, we've been adding more and more scripting options and features in Plasma Desktop and Netbook. KWin is now quite scriptable (why isn't that blog entry on Techbase as a tutorial? :), and the Plasma Shell Scripting now supports "snippets" that are stored in nice little packages. This isn't unique to Plasma, either: Kate, Amarok and many other KDE applications have also gained similar scripting support.

Problem is: we don't have a good way to distribute these add-ons. There's opendesktop.org, but there are four major downsides:

• Creating a new download type (e.g. a feed for share DataEngine backends) there means making a request of the opendesktop.org crew; they are usually quite responsive, but it's still one more set of human roundtrips


• Anyone can post additions there and there is no way for an upstream such as Plasma to approve select items


• It, understandably, remains a manual process where one has to package the results up, upload them, etc.


• It is driven by non-free software

Even without the last matter, the first three practical matters are not great and probably not easily solvable. opendesktop.org is meant to be a social networking driven community creation site, and it does a great job of that. In this use case, however, that just isn't what we need or want.

My dream solution

So I sat down and sketched out what my dream solution would be, namely:

• A git repository to hold the add-on files


• A simple config file in the repository in which I could define feeds


• Open Collaboration Service compatible feeds automatically created from this, so it can be used via knewstuff (aka "Get Hot New Stuff")

This would make the workflow to start a new feed for the share DataEngine (as an example):

• Edit the providers config file in the repository with:
  [org.plasma.share]
  compression=zip
  packageSuffix=.plasma-addon
  metadata=content/metadata.desktop


• Make a directory called "org.plasma.share" in the repository


• Commit the addons in org.plasma.share, each in their own sub-directory


• Push the changes to the main repository

Adding a new addon would mean adding a new directory and committing. Updating an addon would mean editing the files and committing. Simple, easy and fits the development workflow we have seamlessly: it's the same way we write any of our code.

Synchrotron

I carved out a few days to work on this idea and finished up the last bits today. I called it synchrotron. It goes with the whole particle physics naming theme in Plasma and sounded like something out of an awesomely bad sci-fi movie. Win-win, really.

You can find the code, currently in what I'd consider to be "alpha" state in my scratch space on git.kde.org. (I'll be requesting a move to playground and starting a review so that it can be moved somewhere more permanent later.)

Synchrotron consists of:

• a PHP script that scans a local clone of the source git repository and builds feeds, packages and a database cache (currently using PostgreSQL) of the providers and content


• a set of pretty simple PHP scripts that power the (minimal) OCS feeds, allowing for listing and downloading only (no voting, no uploading, etc. supported)

All in just a hair over 2,000 lines of code, not that I tried very hard to keep things minimal, though. Huzzah!

Now I just need to get some code review, put it all on a KDE server somewhere, start the source git repository and start having fun.

The path forward

If you found yourself thinking, "I could make that so much better!" or "I could totally write a bit of PHP for that item in the TODO file!", please don't hesitate to get involved. Send me patches, clone the git repo and get hacking .. I am not a web developer and PHP is not my specialty, so I'll be the first to admit that there are problem a bajillion ways to improve on what's there. Some features, like i18n for names, simply aren't implemented yet.

If you found yourself thinking, "I could so use that for my KDE application!" please get a hold of me by email or on irc and let's coordinate. I think KDE Games, KDE Edu, KWin, Kate, Amarok and who knows how many other KDE application teams could benefit from something like this, and I'd love to share an addons repository with all of them! :)

There are some interesting possibilities for improvement in knewstuff, too. For instance, it would be great if the Share Plasmoid could check on startup for addons in Synchrotron and either grab them automatically or offer to. It would also rock to be able to check periodically for updates to installed addons and have them drawn down automatically.

So in some ways Synchrotron is just a beginning, even though its functional already on my laptop and does what I set out for my "dream system". If you're interested in helping out, don't hesitate to clone the repository and get in touch.

Right now, though, I'm off to make some dinner before popping off some requests to KDE's sys admin super hero league to get the Synchrotron spinning. :)

Read More