Subscribe to Planet KDE feed
Planet KDE -
Updated: 8 min 46 sec ago

I need your help. Diploma thesis about media choice and usage in KDE

Tue, 02/11/2014 - 14:50

Dear KDE mates and contributors

Finally the end of my studies is near and thus I’m currently in the process of writing my diploma thesis. I’ve worked hard during the last weeks and months on a questionnaire which shall collect some data for my thesis. Furthermore the data of this survey will be interesting for the KDE community as well.

So please take some time and add it to your todo list or, even better, go directly to my questionnaire and help me make a great diploma thesis and improve the KDE community in some ways.

The questionnaire takes some 20 to 30 minutes and will show you some interesting facts about our community in the last 15 years. At the end of the questionnaire you’ll find a way to participate in a draw where you can even win something nice.

So once again: Old and young people of KDE, documentation writers, developers, translators, bug reporters and triagers, packagers and all the others of you who contribute to all that makes KDE a great community with great software and more, please take some time and help me to filled in questionnaires from all over the world.

Thanks to all for reading and helping and towards the summer of 2014 you can read here what all the data you gave me showed us and where we can learn and improve.

Thanks in advance
Mario Fux

Doxyqml 0.2.0

Tue, 02/11/2014 - 14:12

I finally got around to release version 0.2.0 of Doxyqml, the Doxygen input filter to document QML code. This new version comes with the following changes:

  • Support for readonly properties (Thanks to Burkhard Daniel) ;
  • Support for anonymous function (Thanks to Niels Madan) ;
  • Keep all comments. This makes it possible to use features like Doxygen @cond/@endcond blocks ;
  • Improve handling of unknown arguments ;
  • Add support for \return and \param in addition to @return and @param ;
  • More tests.

Some of the changes have been sitting in Git for some months now so you may already have them. Others, like support for @cond / @endcond are more recent (like, last-week-recent).

That's it, you can now go back to write documentation for your code :)

First look at cockpit, a web based server management interface

Tue, 02/11/2014 - 09:37

TuxOnly recently the Cockpit project was launched, aiming at providing a web based management interface for various servers. It already leaves an interesting impression for simple management tasks – and the design is actually well done.

I just recently came across the only three month old Cockpit project. The mission statement is clear:

Cockpit is a server manager that makes it easy to administer your GNU/Linux servers via a web browser.

The web page also states three aims: beginners friendly interface, multi server management – and that there should be no interference in mixed usage of web interface and shell. Especially the last point caught my attention: many other web based solutions introduce their own magic, thus making it sometimes tricky to co-administrate the system manually via the shell. The listed objectives also make clear that cockpit does not try to replace tools that go much deeper into the configuration of servers, like Webmin, which for example offers modules to configure Apache servers in a quite detailed manner. Cockpit tries to simply administrate the server, not the applications. I must admit that I would always do such a application configuration manually anyway…

The installation of Cockpit is a bit bumpy: besides the requirement of tools like systemd which limits the usage to only very recent distributions (excluding Ubuntu, I guess) there are no packages yet, some manual steps are required. A post at highlights the necessary steps for Fedora which I followed: in includes installing dependencies, setting firewall rules, etc. – and in the end it just works. But please note, in case you wanna give it a try: it is not ready for production. Not at all. Use virtual machines!

What I did see after the installation was actually rather appealing: a clean, yet modern web interface offering the most important and simple tasks a sysadmin might need in a daily routine: quickly showing the current health state, providing logs, starting and stopping services, creating new users, switching between servers, etc. And: there is even a working rescue console!

Main login view Default server overview Default server view in wide screen browser Detail view of host name and system basics Network traffic Listing services Log watcher Adding a new server to Cockpit. Two servers registered Creating new users Rescue shell System restart

And where ever you click you see quickly what the foundation for Cockpit is: systemd. The logviewer shows systemd journal logs, services are displayed as seen and managed by systemd, and so on. That is the reason why one goal – no interference between shell and web interface – can be rather easily reached: the web interface communicates with systemd, just like a administrator on such a machine would do. That also explains why Cockpit currently is developed on Fedora: it ships with fully activated systemd.

But back to Cockpit itself: Some people might note that running a web server on a machine which is not meant to provide web pages is a security issue. And they are right. Each additional service on a server is a potential threat. But also keep in mind that many simple server installations already have an additional web server for example to show Munin statistics. So as always you have to carefully balance the pros of usable system management with the cons of an additional service and a web reachable system console…

To summarize: The interface is slick and easy to use, for simple server setups it could come in handy as a server management tool for example for beginners and accessible from the internal network only. A downside currently is the already mentioned limit to the distributions: as far as I got it, only Fedora 18 and 20 are supported yet. But the project has just begun, and will most certainly pick up more support in the near future, as long as the foundations (systemd) are properly supported in the distribution of your choice. And in the meantime Cockpit might be an extra bonus for people testing the coming Fedora Server. ;-)

Last but not least, in case you wonder how server management looks like with systemd, Cockpit can give you a first impression: it uses systemd and almost nothing else for exactly that.

Filed under: Fedora, Linux, Monitoring, Screenshots, Shell, Technology, Thoughts

DBus-Activated Systemtray Plasmoids

Tue, 02/11/2014 - 09:35

In this article, I’m describing a way to dynamically load Plasmoids into the systemtray. It’s interesting for you if you develop Plasma addons, or if you’re interested in the design of Plasma by KDE.

One of the wishes that came up during the latest Plasma sprint in Barcelona was a more dynamic way of showing functionality in the systemtray, that little notification area sitting in the panel next to the clock. The systemtray can have different kinds of “things” in them: Statusnotifiers, which are basically systray icons of applications, and Plasma widgets, which allows for much more functionality and freedom in UI development. Statusnotifiers are instantiated by applications, so their lifetime is entirely in the hands of the application they belong to. For Plasma widgets, this is a bit different, they’re currently loaded on startup. Ideally, we want to load specific services on-demand, say when a specific service becomes available.

You may have guessed by the title already, this feature has now landed in Plasma Next. It was actually quite easy to do, yet it’s a very powerful feature. First, let’s see what it looks like:

This feature allows loading and unloading Plasmoids when dbus services come and go. Applets can specify in their metadata which service should control their lifecycle.

This has the following advantages:

  • We can dynamically only load widgets when they’re useful, reducing clutter in many cases
  • Applications can provide widgets that appear and disappear based on the application running
  • We can load controls for system services dynamically as they come and go
  • It makes it easier to delay loading of widgets in the systemtray until when a specific service appears, cutting down startup time
  • It makes widgets and their features more discoverable as they’ll be able to appear automatically

One immediate user for this is the media controller widget, which will now only be loaded once an MPRIS2-compatible media player is running (as indicated by a dbus interface becoming available on the session bus.)

How do you do that? It’s quite easy. Two things need to be done: the widget should indicate to be loaded into the systemtray automatically, and it needs to specify a service which triggers loading it. That’s two lines in your metadata.desktop file, looking like this for example:

X-Plasma-NotificationArea=true X-Plasma-DBusActivationService=org.mpris.MediaPlayer2.

That’s all. Enjoy your cleaner, more dynamic systemtray!

Releasing the Muses DVD

Tue, 02/11/2014 - 09:32

After quite a bit of delay, we can now announce the final release of the Muses Krita Training DVD by Ramon Miranda! Today UPS dropped two big boxes full of lovely DVD's!

And that means that tonight I'll be busy pasting address on envelopes to send out all the pre-ordered DVD's. Thanks guys, thanks so much for supporting Krita and for being so patient!

And, of course, there are plenty of DVD's left to order, so if you didn't pre-order, get your copy now! The regular price is € 32,50 including shipping.

Muses by Ramon Miranda

Watch the trailer:


Or checkout the contents, nearly five hours of video:

Part I -- 110 minutes

Chapter 1. Understanding the UI 
Chapter 2. Workspace and Dockers
Chapter 3. Toolbox 
Chapter 4. Navigation 
Chapter 5. File Handling 
Chapter 6. Setting The prefs 

Part II -- 60 minutes

Chapter 7. Brushes & presets
Chapter 8. Layers 
Chapter 9. Blending Modes

Part III -- 118 minutes

Chapter 10. Sketching Techniques.
Chapter 11. Blocking 
Chapter 12. Color 
Chapter 13. Styles 
Chapter 14. Printing

Sprinter: public APIs and rounding out the feature set

Mon, 02/10/2014 - 15:25

Sprinter is nearing that lovely state known as "feature complete". There is still some work left in the results paging support, but otherwise everything is pretty well there as intended. The codebase is still a bit smaller than the RunnerManager classes in libplasma (~150 less than in libplasma2, and ~400 less than in libplasma1) while doing quite a bit more, so I'm happy about that. Plugins are about the same amount of code, which is to be expected as the patterns for them, while adjusted, are not completely changed. Here's a quick wrap-up of significant changes since my last blog on the topic:
Library prepped for public useThe Sprinter library, cleverly named libsprinter, is now ready for public usage. The classes are wrapped in a Sprinter namespace and the public APIs are properly exported with headers ending up in include/sprinter/.Clearer namingThe last few days saw some significant changes to class names in the library. With feature completeness within reach and installing headers, it was time to do a review of the nomenclature for clarity.
Applications wanting to use Sprinter to fetch and show results from either C++ or QML need only one thing: QuerySession. QuerySession evolved out of libplasma's RunnerManager, a name that used to make sense: it managed the runners and the application dealt with the matches that came out of it. In Sprinter, all the management now happens behind the scenes (via the runner model exported by QuerySession) and QuerySession became a model that is used to access all the results. This turned RunnerManager into an object that represents a query session, so the name was changed to reflect that clearly.
Plugin writers have QueryContext, QueryMatch, Runner and RunnerSessionData to work with. Runner was AbstractRunner, which matched a naming pattern in Qt4 but which really adds nothing, particularly as there are now no pure virtual methods. QueryContext was RunnerContext, though realy it is context for the query and not any specific runner plugin. QueryMatch and RunnerSessionData should hopefully be self-explanatory.
Beyond class names, I've tried to clear up some API warts along the way. A full API review is in order, but I will look for some help with that after the first release.Single-Runner ModeIn KRunner as shipped with Plasma Workspaces, you can put it into "single runner mode". In this mode not only does your query get sent to just one plugin (e.g. the applications runner), but it also would send the runner a default query that it deduced from the runner's "QuerySyntax". 
KRunner called with `qdbus org.kde.krunner /MainApplication displaySingleRunner solid`Wanting to make this trivial to do from QML as well as C++, the functionality to manage this went into the runner model. The application can enable (or disable) any number of runners it wishes, which makes "single runner mode" a special case where only one runner is enabled and all the rest are disabled. The disabled runners are still loaded, they just are not included in future queries. To get the "default" matches (as seen in the screenshot above) a method in QuerySession is provided: requestDefaultMatches.

This is rather more flexible and less purpose-specific than the single runner mode features in RunnerManager while having a perfectly symmetric API and no special paths in the code, something that made RunnerManager rather more complex than necessary.

Runner plugins can now tell if the default result set is being requested quite easily with `bool QueryContext::isDefaultMatchesRequest()` and advertise that they have such a set of matches by calling setGeneratesDefaultMatches(true).Discarding QuerySyntaxWith the "single runner mode" handled, I was left with what to do with QuerySyntax. In RunnerManager days, this was used to describe the syntax a runner would accept. It was used in single runner mode (no longer needed) and to show a "help" listing of all recognized queries when the user requested it ... only the list was unusable, so why bother. Help on what each plugin does will come via a more straight-forward mechanism: plain old documentation, perhaps included in the plugin's json file. Discoverability of functionality is still an open question, but one that is left for the application using Sprinter rather than Sprinter itself.
This left nothing left for QuerySyntax to do in Sprinter and so I discarded it. I can imagine a more useful replacement that could one day appear, such as a directed graph representation of the query input supported by a plugin that can be programatically traversed and utilized, but I have no current plans for such a thing.ImagesIn RunnerManager plugins could attach an image to a QueryMatch with setIcon(QIcon). Problematically, there was no good way of knowing how big that icon should be, so runners that needed to provided something more than just a standard icon would end up subclassing QIconEngineV2 just to get reasonable resizing. Additionally, the images had to be ready before the match was returned to RunnerManager making it a completely synchronous process, albeit in another thread. This worked better than one might expect, but it wasn't pretty.
In Sprinter the application now tells the QuerySession what size of images it wants and this gets passed in to the plugin via the QueryContext. Runners then size any image it has for a match to this. Since Sprinter allows asynchronous updates of existing matches, plugins may also lazily fetch the images and add them to matches as they arrive. This is entirely QImage based, which is rather more friendly for plugins accessing online services or non-icon data for their images.
One possible improvement would be to allow the QuerySession to request images on demand so that only matches being viewed in the application UI would have images created for them. Given the patterns of usage in applications using RunnerManager, this probably wouldn't win much other than to introduce more UI updates, so I didn't bother. Similarly, having a simple QIcon for matches is now a couple lines of boilerplate code in each plugin, but it isn't enough to encourage me to add public API for that.DocumentationDocumentation is also finally coming along now that the API is stabilizing. There are a couple public classes that need API documentation still, but that will get filled in before a first release. There is high-level documentation in the docs/ folder, however, which attempts to cover usage of Sprinter both from the application and plugin perspective. It also contains the TODO file which is being rigorously kept up to date.
Release?The goal is to do a first alpha-quality release in the next week or two which I will label v0.1. There will be no binary compatibility commitments so as to allow useful adjustments to be made as needed. There must certainly be bugs to be found in there, and hopefully a release will encourage some usage so that they can be identified and shaken out. Post-release I will start porting over various and sundry runners that ship with Plasma Workspaces 4.x, which should also help test the library.
Before release, however, there are a couple of items remaining in the TODO file .. so I should probably end the blog entry here in hopes of having time to get to them sooner rather than later.

Talk and Interview at FOSDEM

Mon, 02/10/2014 - 12:57
KDE Project:

Hacker Public Radio FOSDEM edition is up now for those wanting a podcast packaged full of geek interviews. My interview is 27 minutes in and talks of KDE, Kubuntu and how Baloo will make the KDE world slicker. MP3 file.

And the video of my talk Do you have to be brain damaged to care about desktop Linux is up on FOSDEM's website. Mixing the highs and lows of severe head trauma with the highs and lows of developing a KDE Linux distribution.

Last month (January) in Red Hat KDE

Mon, 02/10/2014 - 12:50

Straight back from the tremendous, here's the regular update of what's going on in Red Hat and KDE. Let's have a look how we spent the last month.

Network management (plasma-nm | libnm-qt | libmm-qt)
: jgrulich, ltinkl plasma-nm | libnm-qt | libmm-qt

  • libnm-qt 
    • added new properties/methods from NM 
  • libmm-qt 
    • implemented (new) Oma MM interface 

#329315 - IPv6 privacy extensions should be enabled per default for new connections
#329355 - Bridge connection is active although the plasmoid icons represent it as inactive
#329342 - Network manager forgets the 802.1x settings as soon as the dialog box is closed
#329288 - Crash involving the authorization prompt
#329545 - Applet icon does not scale horizontally when embedded in a panel
#329630 - Password field always empty for the openvpn connection
#329827 - Make notifications disappear after some time

#328985 - A shared wifi network cannot be restarted after being turned off
#329580 - VPN connection asks for too many passwords
#329871 - The VPN (vpnc) connection editor dialog has no Domain field

: dvratil
  • finished rewrite of Akonadi search functionality and Baloo support 
  • removed MySQL Embedded support from Akonadi 
  • fixed BKO #330010 - Broken .desktop files parser in Akonadi 
  • fixed BKO #330215 - Crash on Akonadi shutdown when using PostgreSQL 
  • fixed BKO #324932 - Can't rename folders on some IMAP servers 

: dvratil
  • created patch for RHBZ#1036568 - RHEL6 - KWin does not move windows from a disconnected screen (backported upstream patches) 
  • fixed RHBZ#1056251 - KScreen allows to active more displays than supported by GPU (upstreamed) 

Fedora updates

VDG Weekly Update #2

Mon, 02/10/2014 - 10:01

In which we slam open the doors to the new home page, the new forums, invite new community participants, talk about webdesign, marketing and icon work but focus our attention on Plasma NEXT and the themes and ideas behind it.

Its been one hectic week! Our webdesign crew have worked their little fingers to the bone collecting assets and content, trying to marry webdesign with our ideas for visual design with Plasma NEXT (more on that below) but they pulled it off after a lot of 11th hour panic! Elena, Cuan and David have really gone and been superhuman in their efforts. A special thanks to the Sysadmins in KDE is in order!

Please check out our new group page at ! We will try to post assets to it in the future, links and tutorials so keep it handy and bookmark it for future reference. I have too many "huzzah's" and too few exclamation marks in my computer to explain how happy I am with everything so far.

But wait, there's more! We've also kicked open the doors to the forums at the KDE-forums where we will not only try to organize our work from now on, not only post ideas and future plans but also invite YOU to comment, contribute and be a part! Post your needs if you're a dev. Post suggestions if you're a designer! Or comment! It's all there!
A mighty hearty "thank you" to the admins of the KDE-forums for putting up with us! You guys are fantastic!

Beyond that the week has been a hustle and bustle of trying to get a solid set of design ideas going for Plasma NEXT with not only a set theme (presented here and in the forums shortly) but with mood boards, asset-specs and wild ideas!
We have a future move into a new icon theme for Plasma that will slowly slowly unveil (you will like it a tad too much).
There is also work under way porting a few popular GTK icon themes to KDE (with their designers blessing) so you guys can enjoy all the icon-wonder that exists "on the other side of the fence" while we (sloooowly slooooowly) work and unveil the new icon theme.

"But wait!" I hear you say. "You said something about Plasma NEXT and themes and stuff?" you cry.
Right, I did... Lets start this off with talking about themes and moods. Themes are relevant because they provide a starting point on which to build further design work. The mood, the sensation you wish to convey with all your work - from marketing to icons, to fonts, to windows, to colors, to layout - everything hinges on your collaborative mood.

So what is the mood we're going for with Plasma NEXT in the VDG? A few years back I read Chuck Paluhniuk's "Invisible Monsters" for the first time. In it the characters at one point go up into the Space Needle in Seattle built for the 1962 World Fair - an exhibition about the future seen from the eyes of people in the 60's. Standing at the top the protagonists throw out postcards down to the street below - postcards from the future that never was to the reality that is.

One of them writes "When did the future switch from being a promise to being a threat?". For all of us with an interest in art history and scifi you know what it refers to. Around the late 1970's the Future changed into a vision of a dystopia or an apocalypse. Before that, the future was Star Trek, Barbarella, the Jetsons - shining white corridors, a sensation of humanity overcoming all odds with the aid of amazing technology. Free from the bounds of our current reality humanity explored, lived and created. All this with a sincere trust in the wonders of technology and science.
But then the 70's came and things changed from the Seattle World Fairs vision of shining airy rooms and windows looking out over verdant forests into an atomic disaster with raiders battling over gasoline in an ever-reaching desert or an underground dystopia ruled by machines.

The theme of Plasma we're going for is the "Future that never was". Based on the technological wonders of KDE, all the brilliant things going on behind a sleek facade, we will try to instill the users (us) with a sense of wonder and optimism for the future, for sci-fi. A trust in technology and breakthroughs for a better tomorrow.
Clean, effective but still human and inviting. Brightness, contrast and open air but with rounded shapes intersecting sharp lines and warm, strong spot colors to balance and help bring a human feel to it.
Turning back the clock to a time when amazing technology helped us to boldly go where no man had gone before.

Next time we'll talk colors of Plasma NEXT, how changes will be handled and go into specifics about icon work.

New Driver Manager for Kubuntu

Sun, 02/09/2014 - 18:19

Hola Kubuntu users

Ubuntu ‘recently’ deprecated jockey and moved to ubuntu-drivers-common. ubuntu-drivers-common is a python backend which will try to figure out which drivers are best suited to your system. Up till Kubuntu 13.10 we were still relying on the backend called Jockey which is python2 , however for the 14.04 cycle, one of our major tasks was to rehaul the driver manager interface and use the fancy new ubuntu-drivers-common backend which is python3 based.

By leveraging this new backend, we are now at feature parity with Ubuntu when it comes to driver handling. Packages are now available to trusty users and can be acquired by installing the ‘kubuntu-driver-manager’ package.

Once installed you’ll find it in your System Settings Menu under “Driver Manager for Kubuntu”


If you find any bugs , please report them here

KDE Plasma at the movies

Sun, 02/09/2014 - 02:03
KDE Project:

For several years, I used to maintain a collection of clippings showing the KDE workspaces in use in interesting settings - popping up on TV shows, on public terminals in odd locations, in articles on leading scientific endeavours. All sorts of cool cases. More recently I haven't been collecting as diligently anymore, though, for perhaps the best possible reason: It's happening so frequently now that individual examples have lost much of their novelty.

But from time to time it still provides me with a (pleasant) shock to the system to see our software help others push the envelope and create amazing things. The latest example occurred just the other day, while I was watching the making-of documentary for Alfonso Cuarón's impressive film Gravity:

KDE workstation at Framestore

KDE workstation at Framestore

Framestore worked for several years to provide the majority of the film's effects shots, and their London-based offices seem filled to the brim with workstations running KDE Plasma. It's particularly fun to see Yakuake carve out a spot on many of their panels :).

Interestingly, Framestore isn't the only London-based VFX house using KDE software. I previously collected a snapshot of Doctor Who VFX provider The Mill using Plasma Desktop in their work as well.

One factor driving this adoption is likely the synergy between our and the industry's extensive use of and familiarity with Qt - many high-end 3D modelling and video editing/compositing packages now use Qt for their UI, and often provide PyQt as convenient extensibility solution for in-house dev teams at the studios. The same is true of KDE. But I'd like to think providing a damn nice desktop experience also has something to do with it :).

In the thick of competition, or looking purely at market share data, it's sometimes easy to forget just how much real and compelling use the stuff we make is seeing in absolute terms. And the degree to which our software permeates the foundations that big chunks of our culture get built on top of.

It's nice to reflect on that now and then.

Gravity has been nominated for ten Academy Awards, including the Best Visual Effects category. I have a feeling it has a pretty good chance.

You better work!

Sat, 02/08/2014 - 23:44

In which we gush a little bit of praise for music, talk about personal experiences with work ethics and organizational techniques (from a personal perspective), coming events and talk about the bliss of working with talented people.

Image ©darrentunnicliff,  CC by-nc-sa 2.0

Right now the song Supermodel with RuPaul is going on repeat: "You better work!" I may not "make love to the camera" (which any photo of me will be uncontroversial proof of) but my work ethic and the rest of the VDG teams, could make Martin Luther blush in shame in comparison.

One month have passed since I promised my soul to KDE for a year. Leading up a project within Open Source is one of the most rewarding things I have ever done. Its allot of work but its also a good moment to think about how to organize several talented and genius people within an open structure. Trying to get their talents to best use. Trying to make certain that they will get rewarded for all the genius work they contribute.

The more I think about it the less this has to do with the common AD work I've done before and more with union and nerdy work. I've been a union member most of my adult life and with a background within the left wing (this is in no way a political statement - its just who I am and my background) as well as in the nerdy convention circuit.

There are some lessons from these areas that I take with me into this:

Dig where you stand!
Trying to make things change elsewhere is never as good as starting with where you are. You dig where you stand creating the change you want in the reality you are first then it can spread.

Its not what you say, its what you do!
Talk is easy, but its only in action and movement that we define the direction we're going. Self doubt and care is not as relevant as creating stuff now and fixing them as the issues crop up. Less talky-talky more worky-worky.

Collaboration is better than the Lone Genius!
You suck when you work alone. You might feel empowered by being the one making all choices but you're fooling yourself. You will never be able to keep it up for long and it only works if no one in the world is as good as you. Which isn't true. Swallow that pride and just ask for help. Know when people are better than you, shut up and just learn.

Pride is not the same as Honor!
They may feel the same - but they aren't. Honor is knowing when to back down, pride is refusing to. Honor is being gracious and kind, pride is when you're not. An honorable person is someone who is happy for others successes and helpful when others fail. A person filled with pride is not.
Being proud of what you've done is good - but without some honor its only boastful nonsense.

Always remember the team!
You stand and fall with them. When you take a hit for the team - you will be rewarded for it. When you let them down or betray them - you will ruin it for all. The team should be able to go on with out you, that's what you should aim for - but you can never go on without the team, that's inevitable and unavoidable. Invest in the team - invest in the feeling of a team and you will always come out a head even if you lose.

A magnificent failure is always better than a mediocre success!
This is one of the hard earned ones because its counter intuitive. Failing is never an option until it is. Every time you fail you gain XP because that's when you learn. In all failure but only in the greatest successes. The mediocre ones teach you nothing and will be forgotten quickly. So aim high, crash hard, invest in a helmet.

But lets talk about whats coming for a second. Soon we're gonna go public in a big way. Next week will be allot of work for everyone and we have started to hammer out a workflow which will be based in the KDE forums with constant reposts and reports here, via the mail list and elsewhere (twitter for example and the KDE group at Google Plus).

Three of the team members have been sweating over a homepage that will (with the sys-admings blessings) go up tomorrow if they can tame the beast of weird SSD-things - the adress will be The version they have done is great but will get greater over time with more and more information added as time go by, lets do a quick check list of whats coming:

  • A KDE subforum to post needs as well as suggestions and comment.
  • A set of mood boards and a specified design language available to all, improved over time.
  • A swath of design assets to help the budding designer in their work.
  • A coming questions column where we post all questions we get over mail. Not only about design but designers asking all those tech questions we may be too embarrassed to ask in public. (its fine, we all have them)
But thats whats on the closer horizon - later on plans are to create short courses in design matter available for all.
None of this could have been done without the 13 people, the skilled designers and graphics geniuses in the Visual Design Group that I have the current pleasure to be working with. The work on homepage, sketch-ups for ideas and logo work that has been going on so far has been amazing and next week it will get even more amazinger (it's a word now). It's weird, inspiring and humbling asking someone to do it and see them do it better than you ever could! Everyone have done an amazing job but our webteam, Cuan Kneggs, David Brandl and Elena Ramirez have gone far, above and beyond all expectations. 
On monday there will be a more detailed report as well as "things to come" hold on to your keyboards - this year will be amazing!

(as a side note - I, Jens Reuterberg, tend to start writing like a viking saga when tired - allot of split shields and dramatic sayings and considering my current 18 hours of work a day, you will hear allot of Viking Epics from me ;-) )

kate: intelligent code completion for all languages!

Fri, 02/07/2014 - 22:38

... well, maybe that's a bit of an exaggeration, but it's certainly much more intelligent than before. Look:

Code completion in CSS... bash... Lua... PHP
even Gnuplot!Note how this one has a different set of possible items for the same query, respecting the context.Even Mathematica ;) This image shows a problem which still needs to be fixed: in case-insensitive languages, all completion suggestions are lowercased (which is not technically wrong of course, but a  bit ugly). It's easy to fix but simply not done yet.There's unexpected profit from this in quite some areas, even KDevelop: for example, through this we now get code completion for all keywords in doxygen comments:
Completion for doxygen keywords inside a doxygen commentOf course, those only appear inside actual doxygen, and not C++. When the cursor is in C++ code, it shows the C++ keywords instead (but they will not be very visible in KDevelop, since they're sorted below KDevelop's suggestions, which are better).
How does this work?Short answer: magic! Correct answer: it uses the highlighting files. For highlighting, kate has a list of possible keywords for languages listed in highlighting files (/usr/share/apps/katepart/snytax/$language,xml). Those keywords are even context-sensitive: you will notice that e.g. the PHP highlighter does not highlight PHP function names inside comments or strings. So, the highlighting engine needs to know which keywords are valid at which position. Those are precisely the keywords which are suggested in the list.
What now?Now that we have this feature, I think we can make more out of it in quite some cases. Especially, I want to invite you to have a look at your favourite language, and make sure all keywords / builtin functions / etc. are actually listed. Because of this feature, it might make sense to list keywords for languages where they are not terribly helpful for highlighting; a prominent example would be HTML, where currently the highlighter is totally generic and does not actually look at e.g. the tag names (thus, there's no completion). If you'd fix that by actually listing all valid HTML tag names, you'd (1) get better highlighting, e.g. you can mark undefined elements (think typos) as errors and (2) completion for free with that.

Another thing which can be improved is the context sensitivity. Some languages already do this rather well, but many languages will higlight keywords also in places where it'd be easy to detect that the keyword does not make sense there. That doesn't matter that much for highlighting only, because generally users write code which makes sense, but still -- if you can detect it, both consumers of the highlighting data (the actual highlighting, and the completion engine) gain something from it. So, extra motivation for making things more exact! ;)

I'm sure we can do more cool stuff with this. If you can come up with a good idea -- tell me, I'm happy to talk about it.

Krita on Steam!

Fri, 02/07/2014 - 20:32

Krita on Steam... It started out as a weird idea. Sort of... If Blender can do it, why not Krita? Besides, Steam is a whole new community, and if there's one thing we love, it's welcoming new Krita users. And then, SteamOS, Steam on Linux... We started imagining Krita Sketch on the Steambox, and from there the idea started to go wild...

Fast-forward a bit, and there we are. The Krita on Steam Greenlight campaign has started! The way it works is that Valve will only let applications on Steam that the Steam users tell them are wanted. So iIf you're a Steam user and would like to see Krita on Steam, we need your vote!

Imagine Krita running on a huge television set in Big Picture mode with a wireless Wacom tablet... Create awesome fan-art for your favourite game, or textures for your marketplace mods. Because what's going to be published is Krita Gemini, the innovative 2-in-1, face-changing version of Krita. Now it's a laptop or desktop application, now it's a tablet or big picture application!

Now to be absolutely clear:

Krita is Free software, licensed under the GNU Public License, version 2 or any later version at your option. Any work done to make Krita integrate with the Steam platform will, of course, be Free Software. Any work done to improve Krita will be open source. Just like Krita Gemini is part of the Krita 2.8 release (February 26th...). This is just another chance to help fund Krita development, through KO GmbH, and make Krita better and better, for everyone.

Let's get Krita through the Greenlight!

Making plasmoids QML API better

Fri, 02/07/2014 - 20:09

For the next iteration of Plasma, we are not only revising the user experience, but also making better the developer story.

This article is pretty long (sorry no pretty pictures this time ;), and is probably easy to just TR;DL it, but it will give some important guidelines if you will ever interested to write a plasmoid for Plasma Next, such as “how the hell can I make my plasmoid have a correct size in the panel.”

First of all I’ll start with a short personal note: I just started with a new position in Blue Systems, where I’ll work towards making the next iteration of the Plasma technologies, both as a framework and as a desktop ready for prime time, aiming to give the best experience possible on the all new Qt5, Frameworks5 based Plasma Desktop by KDE.

Plasmoid and attached properties

In QML1 plasmoids, you had a global object accessible from everywhere in the plasmoids called with much imagination, “plasmoid”
This is useful to access everything that is related with the ambient it’s loaded in, the scene and the containment, so you can read things like:

  • The formfactor: are we in the desktop? panel? is it horizontal or vertical?
  • The title/icon etc:data for the plasmoid: you can set a different title, which a containment can decide to show (such as in the new system tray) or the icon, that will be used when the plasmoid is iconified in a panel
  • Configuration: the whole mechanism for handling the configuration for plasmoids is abstracted in a neat object “plasmoid.configuration” that is usable as any JavaScript Object: configuration keys are accessible as members or as keys of an associative array. It’s possible to write or read on them, and the QML property binding mechanism will work, even when the configuration is modified by somebody else (such as the desktop scripting)
  • The compact and the full representations
  • And much more

Wait, what are “The compact and the full representations”? to find out, skip to the next paragraph ;)
In Plasma Next, besides the global plasmoid object, accessible from anywhere (any item and any qml file in the plasmoid), we have also an attached object, called “Plasmoid” (uppercase) that provides the full plasmoid api (is the same object, really) as QML attached properties of the root Item of your plasmoid, so you can have a very, very convenient way to read and write properties, and to do signal handlers.

import QtQuick 2.0 import org.kde.plasma.plasmoid 2.0 //needed to give the Plasmoid attached properties import org.kde.plasma.core 2.0 as PlasmaCore Item { id: root Plasmoid.title: "My custom plasmoid title" Plasmoid.onformFactorChanged: { if (plasmoid.formFactor == PlasmaCore.Types.Horizontal) {... // My custom JavaScript handler code to react to a formfactor change } //rest of your plasmoid code }

Compact and full representations

two important new properties of the Plasmoid object are compactRepresentation and fullRepresentation: plasmoid can collapse in an icon when they are resized to a too tiny size for their usual UI to make sense: in this case you usually get an icon that will show the full plasmoid in a popup when clicked.
The plasmoid will switch at a size that you can set with the properties


For those properties you should use preferably not pixels, but dpi independent measures, provided by the “Units” system, as explained here.

By default, you’ll have an icon (that’s one of the things the “icon” property of the plasmoid object is for) as the compact representation, and the whole root object is taken as the full representation.

But in some cases, an icon is not enough, you may want something more complex, like in the case of the clock.
To do that, you just have to define a cutom one.
Imagine you implemented your digital clock in a file called DigitalClock.qml:

import QtQuick 2.0 import org.kde.plasma.plasmoid 2.0 import org.kde.plasma.core 2.0 as PlasmaCore Item { id: root Plasmoid.switchWidth: theme.mSize(theme.defaultFont).width * 10 Plasmoid.switchHeight: theme.mSize(theme.defaultFont).height * 15 Plasmoid.compactRepresentation: DigitalClock {} //rest of your plasmoid code }

One thing that is neat, being compactRepresentation a Component, it doesn’t actually get instantiated until you actually need it.. why wasting memory on the graphical representation of the icon if it will never be iconified for its whole lifetime?

at the same time, it’s realistic that a plasmoid can sit in your panel (or , in Plasma Next is also possible to collapse them when in the desktop) for hours before you have to open it, if at all: why it should take startup time to instantiate its contents? (and why they should always take memory if they are not used?)

In Plasma Next, you can assign the full representation too, so to redo the previous example, if you want to show a calendar when you click on the clock:
import QtQuick 2.0 import org.kde.plasma.plasmoid 2.0 import org.kde.plasma.core 2.0 as PlasmaCore Item { id: root Plasmoid.switchWidth: theme.mSize(theme.defaultFont).width * 10 Plasmoid.switchHeight: theme.mSize(theme.defaultFont).height * 15 Plasmoid.compactRepresentation: DigitalClock {} Plasmoid.fullRepresentation: Calendar {} //rest of your plasmoid code, only data model related items, there won't be any graphics object here anymore }

Plasmoid.fullRepresentation will probably usually contain the most complicated code since it may be abig and complex UI, but when it’s in the panel it won’t get created until the user opens it, so it won’t cut on precious startup time.

Therefore, in Plasma Next, the recomended way to write a QML plasmoid is:

  • Write a root Item as simple and lightweight as possible
  • Use the default icon as compact representation when possible (to have that just don’t define any compactRepresentation, it will take the default)
  • Put all of the UI under Plasmoid.fullRepresentation
  • Under the root object, put all the dataengines and the models that you need to access from both representation, but only and always non graphical pure data model stuff.
Making your plasmoid to behave well in a layout

Since Qt 5.1, QML2 has a new set of components: the Layouts.
Those are similar to the good ol’QWidget layouts, we have linear (row and column) and grid layouts. This makes construction of plasmoids and containments way easier.
What i want to talk about here, is the size hints that those layout provide.
As the Plasmoid object that I wrote about before, is now available another attached object called Layout, and is documented here.
You can define one inside of any Item, and when/if that item will find itself in for instance a RowLayout, the layout will respect the size hints defined as attached properties (minimumWidth, maximumWidth, fillHeight etc).

We are using the same attached properties for the plasmoids themselves.
If toy define the Layout sizehints properties inside either the compactRepresentation of the fullRepresentation of the plasmoid, they will be used for several things:

  • when the fullRepresentation is in a popup, the popup will never be smaller than the Layout.minimumWidth/Layout.minimumHeight of the fullRepresentation
  • If the plasmoid is collapsed in the panel, all hints of the compactRepresentation will be respected by the panel layout
  • Same thing for the fullRepresentation: for instance the taskbar is a plasmoid that always stays in fullRepresentation, which has the Layout.fillWidth property set to true: this way the taskbar will always take all the available space there is left in the panel.

Let’s add this to the usual clock example:
import QtQuick 2.0 import org.kde.plasma.plasmoid 2.0 import org.kde.plasma.core 2.0 as PlasmaCore Item { id: root Plasmoid.switchWidth: theme.mSize(theme.defaultFont).width * 10 Plasmoid.switchHeight: theme.mSize(theme.defaultFont).height * 15 Plasmoid.compactRepresentation: DigitalClock { //make sure the collapsed clock is at least 5 "M" wide in panels Layout.minimumWidth: theme.mSize(theme.defaultFont).width * 5 } Plasmoid.fullRepresentation: Calendar { //make sure the popup is at least 10x10 "M" Layout.minimumWidth: theme.mSize(theme.defaultFont).width * 10 Layout.minimumHeight: theme.mSize(theme.defaultFont).height * 15 } //rest of your plasmoid code, only data model related items, there won't be any graphics object here anymore }

Reasonable DPI in Plasma Next

Fri, 02/07/2014 - 17:28

We are currently looking into how we can improve Plasma (but in extension also other applications, including QWidget-based ones) on hardware that sports unusually high DPI (also called “reasonable DPI”). In this article, I’ll outline the problem space and explain our tools to improve support for high DPI devices in Plasma.

First, let’s take a step back, however, to explain the problem space to those who haven’t yet spent that much thinking on this. Most of today’s desktops and laptops have have roughly the same amount of pixels per square inch of screen space. The amount of pixels per inch is measured in DPI (dots per inch) or PPI (pixels per inch). This value is around 100 DPI for laptops. Tablets and smartphones are already available with much higher DPI screens, making for sharper fonts and overall higher fidelity graphics. A while ago, Apple has started producing laptops with high DPI displays as well, these are the so-called Retina screens. There are Macbooks on the market with 220 DPI.

Test Plasmoid showing a scaled UI

Test Plasmoid showing a scaled UI

Some people have complained for years about the low DPI value of screens available on the market (and I am one of them), higher DPI simply allows for nicer looks, and reduces the need for “dirty tricks” such as subpixel rendering algorithms (which come with their own set of problems). Graphics chips also have become fast enough (and with enough memory) to not have a problem with high resolutions (think 4K on your laptop, for example).

I’ve done some research (Well, lazy-webbing, mostly), and it seems that higher DPI screens for desktop systems, but also for laptops are still quite rare, and when you find one, they’re often really, really expensive. I believe this is caused by two reasons: production-line quality is not always good enough to produce high DPI screens, one could say that the more pixels there are on a given device, the higher the chance that one or more of them are dead, making the display unsellable, and thus increasing the price of the ones that are pixel-perfect. Also, tablets and smartphones, which often already sport high DPI screens are currently taking up almost all of the production capacity. The obvious result is scarcity and a high price. I believe it’s only a matter of time until high DPI displays become more common, however. A few friends of mine already have high DPI displays, so there is a real need to support this kind of screen well.

Battery Widget without icon scaling

Battery Widget without icon scaling

So what’s the problem? Many applications assume a fixed DPI size, or at least that the DPI value of the screen is within a certain range, so that when you render an icon at 22 pixels, it will look like a small icon, compared to text, and that its details are visible. Also, icons and sizing of fonts are loosely related, so an icon that is way smaller than the size of the text as rendered will look weird and cause layouting problems. (Imagine huge letters and cut off text, for example.)
For graphical elements, this is a real problem, but less so for text. Today’s text rendering engines (Freetype, for example) take the DPI value of the screen into account. This means that this at least partly solves our problem. Luckily, it solves the problem for very complex cases, so at least this is not of great concern. It’s only a partial solution, however, so this at best eases finding a complete solution. We need to fix these problems in different areas, and all need to have well-thought out solutions.

Limitations in X11

The bad news is that this problem is only partly solvable in an X11 world. X11 has no real concept of different DPI values per screen. This is not so much a problem for single screen systems — we just use the DPI of the only screen. As soon as you attach a second screen that has a different DPI, this is going to be a problem, and it’s not possible to solve this completely in an X11 world. We’re planning to first make it work in a single DPI environment, and then work towards supporting different DPI values per screen. (Of course we’ll keep multi-DPI-screens in mind, so that we don’t have to take too many steps back once we are actually in a position to be able to support this. This means Wayland, basically.)

Battery Widget using icon scaling

Battery Widget using icon scaling

Cheating with fonts

A pretty easy, yet neat solution is to use font metrics to compute sensible dimensions for graphical elements on the screen. The very short version is to stop thinking in numbers of pixels, and to start thinking in lines of text and with of characters as they end up on the screen. This is not a pure solution to the DPI problem, which in many cases is actually an advantage. The size (for example height) of a given letter rendered on the screen depends on a number of properties:

  • The DPI value of the screen which is used to render the text
  • The font size setting
  • The size of the font itself, as it is designed (this is usually more relevant for the aspect ratio between width and height)

This means that taking the font height as rendered, we actually can compute values for sizing elements that not only take the low-level technical properties of the hardware into account, but also user preferences (or system presets). In Plasma 2, we started using this mechanism in a number of places, and so far we’re pretty happy with the results. Some examples which where we use this is the sizing of popups coming out of the panel (for the notification area and the calendar for example), but also the sizing of the icons in the notification area (or system tray). This means instead of hardcoding pixel sizes, these UI elements grow and shrink depending on your settings. This solves a part of the problem, but is obviously not a complete solution. If you would like to implement this mechanism, here’s two snippets of code, which, with some necessary adaption, you can use to make your app work well on High DPI devices.

in Qt C++ code:

const int fontHeight = QFontMetrics(QApplication::font()).boundingRect("M").size().height();

This gives you the height of the letter “M” as it would be rendered on the screen. It’s a useful mechanism to get you a pixelsize that is dependent on the DPI value of the screen. Note that you want to use an int here, in order to not end up aligning UI elements at half pixels, as this leads to blurriness in your UI.)

We’ve bridged this API in the Plasma Theme class, which is available from QML applications by importing org.kde.plasma.core (the global property theme will be automatically set, which allows you easy access to Plasma::Theme from everywhere, in case you’re wondering where the “theme” variable is coming from).

import org.kde.plasma.core 2.0 as PlasmaCore /* Paint an orange rectangle on the screen that scales with DPI This example makes the rect big enough to paint about 8 rows of text (minus spacing), and allows for a column with of about 60 characters. Mileage varies on fonts used, and the text itself, so this is an approximation. */ Rectangle { width: theme.mSize(theme.defaultFont).height * 8 height: theme.mSize(theme.defaultFont).width * 60 anchors.margins: units.largeSpacing Item { anchors.fill: parent /* ... more stuff ... */ } }

In the second example, you see that we’re using another property, “units.largeSpacing” for the margins. This is another piece of DPI-dependent UI which you can use to apply margins and spacing that take DPI (actually font-as-rendered-settings) into account.
To get the size of a piece of text on the screen, in QtQuick code, you can use the paintedWidth property of a Text elements, but not that this can be tricky due to text elision, line breaks, etc., so this is to be dealt with with care.

Icons and other graphical elements

Another interesting case which affects the usability of our graphcal interfaces on high-DPI screens is the sizing of icons. We are using standard sizes there, which you access via properties “units.iconSizes.small”, “units.iconSizes.large”, etc.. In Plasma, these sizes now get interpolated with the DPI value of the screen, while making sure the icons are still getting rendered correctly. The sizing is done in steps, and not linearly to avoid getting washed-out icons. This mechanism works well and automatically solves another piece of the puzzle. The result of doing this is a more balanced look and better alignment and spacing across some widgets (notably the battery gains quite a bit of beauty with this treatment).
In other UI elements, especially the toolkitty widgets we provide in PlasmaComponents, we often already scale with the text, which works just fine for reasonably-but-not-excessively high DPI values. We have done some experiments with scaling up the graphical elements that are used to, for example, render a button. As we are using SVG graphics throughout the user interface, we don’t have to resolve to dirty tricks such as doubling pixels, and we can get quite neat results. This needs some more work, and it hasn’t been merged into master yet.

The Higher-Level Picture

Now, having discussed lots of technical details, how does the user-facing side of this look and work? The changes we’ve done right now only affect the user in one way: More UI elements scale with the DPI of the screen, this means no change for displays around 100 DPI. On my laptop (which has a 180 DPI screen), this gives a more balanced picture.
As Plasma is making its way onto a wider range of target devices (think tablets, media centers, as well as high-dpi laptops or monitors), this topic becomes increasinly important. I have good hopes that we will be able to solve this problem in a way that really leverages the power of this kind of hardware. In Plasma Next, we’re now providing some of the basic tools to make UIs work well on high-DPI displays, and we’ll continue this route further on. The user will notice that in Plasma Next, most of the problems that could be seen on high DPI screen are gone, and that the whole behaves much better without many tricks.

An experiment in space building

Fri, 02/07/2014 - 16:10

Greetings, fellow humans! Some people may have noticed a lack of FOSS-y contributions from me over the last year or so. A lot of that time went towards running the first full year of SYNHAK, the Hackerspace in Akron, OH that I helped found in 2011.

As it began to grow and take off, my interests in FOSS moved towards the infrastructure that actually makes a Hackerspace tick. Hackerspaces are wonderful things: autonomous collections of people where even the organization structure itself is designed to be resiliant and hackable. From the outset, I wanted SYNHAK to have a minimal bus factor. Being the first person to come with any kind of workable plan and convince some others to help it out, I had a significant hand in constructing the foundations that we maintain today.

Before SYNHAK, I was very involved in KDE and Linux spheres for a good number of years. FOSS is an amazing environment for new ideas to sprout and take hold, and a lot of that is due to the infrastructure supporting it: the tools, public and open documentation, instantly hackable sources, community governance, and more. I wanted to bring that to SYNHAK. I feel that for the most part, it has been highly successful on all of those fronts. I would argue that SYNHAK bears the right to be called an Open Source Hackerspace.

Forking SYNHAK

SYNHAK’s infrastructure is easily forkable. You can have your own local copy of SYNHAK up and running in a day, if you’ve got the time. I drew a lot of my design decisions from the FOSS world. Almost all of SYNHAK is available online in git. The rest is in a wiki. We are incredibly transparent with heaps of documentation, discussion, and documentation of discussion.

In particular, the ideas I brought from FOSS were:

  • The community governs itself
  • Release early, release often
  • Transparency in operations
  • If it didn’t happen on the mailing list, it didn’t happen
  • Meritocracy

Over the next few days, I will be publishing a series of articles I wrote on the various pieces of infrastructure I contributed to for SYNHAK during it’s first two full years of existence in an attempt to build an open source hackerspace from the ground up.

Leveraging the Power of Choice

Thu, 02/06/2014 - 18:51

People have quite varied opinions of Plasma and other KDE software, but most agree on one thing: When it comes to flexibility and offering choice for users, we’re unbeaten!

This, however, comes with the danger of overburdening especially novice and casual users of our software with too many options. That fine line between too little and too much choice is difficult to strike. While other companies or communities have decided to opt for giving users what they think is best for them, especially experienced users of KDE software have come to expect a great degree of flexibility. So how can we cater to both novice/casual users and experienced “power-users” with the same peace of software?  In many cases the answer is: We can’t. What we can do, though, is offering each group (and there may be more groups then those two) an individual piece of software that works well for them, but not necessarily for the other group(s).

Plasma (both the current and next iteration) provides an easy way to do that with different Plasmoids. For the same purpose, we can have one Plasmoid which strives for simplicity and one that strives for maximum flexibility and power. The only catch: It’s currently a bit complicated to switch between the different Plasmoids. You have to go into configuration mode, remove one Plasmoid, search for the new one, and place it where the old one was. This is likely to prevent many users from making extensive use of Plasma’s flexibility, simply because it’s not important enough for them to invest the effort to switch Plasmoids.

When the problem of having to strike a balance between simplicity and flexibility came up again on the plasma-devel mailing list in the context of the Digital Clock Plasmoid, I remembered a discussion I had with Àlex Fiestas a while ago about the same topic. He suggested to provide a way to easily switch between different Plasmoids for the same purpose if we know which purpose a Plasmoid serves. I was about to suggest that on the mailing list, but Marco Martin beat me to it with this mail:

interestingly enough, i was thinking the other day that it would be interesting providing in plasmoid desktop files something like X‑Plasma‑Provides=org.kde.plasma.clock that would be similar to the provides keyword in rpms to provide alternatives, so then in the plasmoid config dialog there may be alternatives listed…
…but this is definitely for next+1

That was exactly what I had in mind (and I assume Àlex as well), and it would be a great way to leverage one of Plasma’s biggest strengths: Flexibility, which offers choice! Of course maintaining multiple Plasmoids for the same purpose also means multiplied work, but not all Plasmoids have to be created by the core Plasma team. Everyone can write a Plasmoid for a certain purpose, add the X-Plasma-Provides line to the desktop file and thereby plug it right into this system! With this in place, whenever a user complains that a Plasmoid is either too complex or offers too little choice and an alternative exists, we can point them to it and they can easily switch.

As Marco said, this feature definitely won’t come in the first release of the next Plasma, but I’m looking forward to it nevertheless and will keep nagging the developers until it’s available ;)

So, dear readers, what do you think about this? Do you think this would help, or should we rather try to create Plasmoids that work for everyone?

Filed under: KDE, Uncategorized, User Experience

"Of Missing Persons" Russian-based open movie project!

Thu, 02/06/2014 - 16:24

365mult is a small open movie project based on the story "Of Missing Persons" by Jack Finney and using only opensource software in its production: Blender for 3D modelling and Gimp+Krita for texturing and concept art!

The project was started in the end of December 2013 and was declared to publish updates every single day. Artur Shamshadinov, the founder of the project, says: "Every day we must do a small piece of work and the same day we must publish a report about it! That way everyone can follow the progress and we have no opportunity to relax and shirk from making out movie rock!"

The main part of the team is located in Kazan (Russia), but they would be glad to accept contributors from all over the world!

Here are their first concepts of the landscape around the barn: 


And the main character (surprise! ;)

Kubuntu 12.04 Update Released

Thu, 02/06/2014 - 15:27

Our current LTS release has had an update, 12.04.4. It adds all the current bugfixes and security updates to keep your LTS systems fresh. Download now.