One of the first things people think of when talking visual design is icons. Now as "design" this is a very tight definition since a large chunk of it is so much bigger. But icons is a part of it all and it is something that is the most obvious change visually. Icons are also something very very difficult to do well as there is not only several very strict rules and concepts to consider while doing them, there is also a very large amount of work involved (thousands of icons for starters). Beyond that there are issues that make it even trickier.
As icons are very direct visually - they are often victim of harsh criticism (or downright harassment) but further than that the BASE theme of a distro have to follow even stricter rules if it want to be accessible to as many as possible.
Now we using Plasma do not have the huge wealth of icon themes as the boys and girls over at GTK, but we are getting there ever so slowly and today I would like to present one of the latest icon themes to get ported to KDE - Moka by Sam Hewitt.
More than 800 people participated in our online sorting of the KDE Network Manager details. In this article we present the results.
To achieve this we doubled some information into a tool-tip. This will of course only be an advantage for non-touch-users. We replaced the ‘connected’-statement in the current interface by the IP address and information about the current connection speed. Also, seeing the large amount of different information available for a single wireless connection we propose to split this information up into the sections ‘My computer’, ‘Speedgraph’, ‘Connection’ and ‘Router’.
Kubuntu 14.04 LTS Trusty Tahr is an official derivative of Ubuntu 14.04 LTS that uses the popular KDE desktop environment. According to information from the development team, this version offers more stability and also brings the latest apps for KDE.
As Xubuntu 14.04 and Lubuntu 14.04, Kubuntu 14.04 come with long term support. The long term support means it comes with the promise of at least 5 years of support, including patches and bug fixes.
KDE tries to be as much customizable as possible: All freedom to the user! This leads to an extended configuration that might be confusing to new users. Additionally, modules from different sources are aggregated in a way that not necessarily fits the mental representation of users. For instance, the distinction between ‘workspace appearance’ and ‘window appearance’ is not common in other desktop environments.
‘May the fork be with you’ is a term we often hear in the free software community as it’s extremely easy to take the code and fork it to scratch your etch. What’s really difficult (and that’s something really counts) is to actually come together, collaborate and merge code-base to create something which helps more people, which is not just about scratching your own itch, but to do something which benefits more and more people.
Remember Playkot's Supercity? Game artist Paul Geraskin liked has just started a crowdfunding campaign to support working on a new indie game, inspired by Howard Lovecraft: Road to Providence. As with Supercity, Road to Providence will be created with open source tools: Krita, Blender, and jMonkeyEngine.
The 14.04 release of Unity unfortunately shipped with a few security vulnerabilities in the newly introduced screenlocker. As we will also ship a reworked screenlocker in Plasma Next I started to do another code audit, add more unit tests and try to make the code easier to understand and maintain. Furthermore I think it’s a good reason to explain how screenlockers work in general on X11 (and why it is easy to introduce security vulnerabilities) and the screenlocker in Plasma Next in particular. To make one thing clear: this post is not meant to shame Ubuntu for the issues. Some of these whoopies would have been possible in Plasma, too, and that’s the reason why I looked at the code again in more detail. On the other hand I think that our screenlocker in Plasma Next could be a solution for Unity’s use cases and I would appreciate if Ubuntu would adpot our solution.
For quite a while now the KDE team has been severely understaffed. We maintain
a lot of packages, with many different kinds of bugs, but we don’t have enough
people to do all the work that needs to be done. We have tools that help us
automate the update to new upstream releases, but that’s just the tip of the
iceberg of our work and so we are writing to invite more people to get
involved in the team and help us get KDE software in Debian into better shape.