fidzu : KDE

One of the 2014 Google Summer of Code projects for Krita is going to be in the next release, Krita 2.9. It's a bit complicated, so here's a short tutorial in using Mohit's Dirty Presets, Locked Brush Settings and Cumulative Undo projects!

1. Dirty Presets

This is a feature a lot of people asked for: It allows Krita to remember small changes made to a preset during a session, without it saving over the original.
You activate it in the brush settings window, by ticking 'Temporarily Save Tweaks To Presets'.

Then, select a preset.

Now, if you tweak a setting, like, say, opacity, Krita will make the preset 'dirty'. You can identify dirty presets by the little plus-icon on the preset icon.

To get the original settings back, press the reload button.

To retain these settings, just save the preset.

2. Locked Brush Settings.

Another often requested feature, this allows you to lock to opacity, or brush-tip, or even texture.

You activate it by right-clicking the lock besides a setting. Then, select 'lock'.

Now, the setting will not be reloaded every time you select a new preset.

This can be used, for example, to keep the same texture over all presets.

You can unlock them by right-clicking the lock-icon again.

There's two options here.

Unlock (Drop Locked)

This will get rid of the settings of the locked parameter and take that of the active brush preset. So if your brush had no texture on, using this option will revert it to having no texture.

Unlock (Keep Locked)

This will keep the settings of the parameter even though it's unlocked.

Finally, the last one.

3. Cumulative undo.

Cumulative undo allows you to have undos merge together. This can be useful if you're the type to make a lot of tiny strokes, or to save memory.

Cumulative undo is activated via the Undo History Docker. Right-click an undo-state to enable it.

Afterwards, you can tweak it's settings by right-clicking the undo-state again.

Start merging time

The amount of seconds required to consider a group of strokes mergable. So if this is set to five, at the least five seconds must have passed for Krita to consider these strokes mergable.

Group time

The amount of time it needs between strokes for Krita to consider the next stroke to be part of a new group. So if it's set to 1, Krita will put strokes that were made more than 1 second after the first into a new merged group.

Split strokes.

The minimum amount of last strokes that stay undoable without being merged. So if you have this set to 3, and make five strokes, only the two oldest ones will be merged.

Disable this by right-clicking an undo-state and disabling it.
After this, you can start undoing large sets of strokes! The merged items will be represented with 'merged' behind their name in the undo history.

31 Jan 2015 3:30pm GMT

You thought you had seen every post about Randa Meetings in 2014, right? Or perhaps you posted about Randa and thought you were super late? Well, abandon all hope: this is the definitive latest post about Randa Meetings 2014 :D

The title may not be surprising to you if you have organized a developer meeting before or if you have attended one in which you are close to the ogranizers (e.g. as a volunteer or as a curious person). But coming from a country in Latin America where no serious developer meetings happen, and reading about KDE sprints here and there all the time, you might have an impression that those things happen out of the blue. In my case, I thought there was some sort of machine sprint organizers turned on, put in some money and it would spit out a sprint. Notice that I don't consider Akademy a developer sprint, so I was very much aware Akademy is an organizational nightmare challenge.

But attending Randa Meetings 2014 changed my perspective about organizing sprints. Starting with the fundraiser, then the coordination of arrivals, and other things we could follow through e-mail and blogs, I was able to see that this organization was big. But that was just part of it. You would have to arrive to Randa and see how the organizers were taking care of details like network access, food, name tags, food, coordination of visit days, food, our field trip and most importantly, and I think I have not mentioned this before… food. This was, of course, the result of the collaboration of many, not only Mario Fux, who is the usual name associated to Randa Meetings. In particular, I have to thank Mario's family for all the food, which I think was an important part of the meeting and I haven't mentioned it. I was able to discuss many matters of the organizational details with Mario while we walked from Zermatt to Randa, and this helped me understand the dimensions of organizing a sprint like that one.

KDE has many sprints throughout the year and my experience in Randa has helped me appreciate both the importance and the challenge of organizing these. BlueSystems office in Barcelona has been really helpful in making it easier for people to organize these sprints, but there is still a lot of manual work organizers need to do. You can help and be part of this by donating to KDE.

30 Jan 2015 7:09am GMT

It's almost time to leave and I can't wait to see my friends from the OpenSource world again and for my first experience at FOSDEM.

I've gotten my luggage ready and I'm (almost) ready to leave.

The KDE T-shirts packed and ready for the road.

Route to FOSDEM.

And I've prepared my best and most representative T-shirts.

FOSDEM, Here I come!

29 Jan 2015 8:08pm GMT

29 Jan 2015 10:30am GMT

It's here! Plasma 5.2 has been released just yesterday and you don't have to wait a single minute longer to update your beloved Fedora boxes :-)

I won't go into detail here about all the new awesome things that are waiting for you in Plasma 5.2, but I totally recommend that you go and read Plasma 5.2: The Quintessential Breakdown by Ken Vermette while you are waiting for your package manager to wade through the update. You can also read the official Plasma 5.2 release announcement, it has fancy animated screenshots ;).

And there's other news related to Plasma 5.2 and Fedora: Fedora rawhide has bee updated to Plasma 5.2 too. This means that KDE SIG will ship Plasma 5 in Fedora 22! Of course we will still maintain the Copr repository for our Fedora 20 and Fedora 21 users.

So, how to get Plasma 5.2 on Fedora?

On rawhide, just do dnf update. On Fedora 20 and Fedora 21, if you are already running Plasma 5.1.2 from dvratil/plasma-5 Copr, then all you need to do is to run dnf update. If you are running Plasma 5.1.95 (aka Plasma 5.2 beta) from dvratil/plasma-5-beta Copr, then it's time to switch back to stable:

dnf copr disable dvratil/plasma-5-beta
dnf copr enable dvratil/plasma-5
dnf update

If you are still running KDE 4 and you want to update to Plasma 5.2, just follow the instructions on dvratil/plasma-5 Copr page.

And if you don't feel like installing Plasma 5 on your production box right away and would like to just try it out, there's a live ISO for you. This time I did not forget to add Anaconda, so once you decide that Plasma 5 is good enough for you, you can just install it right from the ISO ;-)

EDIT: I might have included Anaconda, but did not add grub2 to the ISO, so the installer would fail anyway. This has been fixed and updated images are available now on the same link. If you are planning to install from the live ISO, please download the updated images (29-Jan-2015 00:42)

Oh, and if anyone is around in Brno next week for DevConf, let us know and we can informally meet for ceremonious consumption of beer to celebrate the Plasma release ;)

28 Jan 2015 9:01pm GMT

With Plasma 5.2 out I wanted to update the tutorials on how to write a Plasmoid. Going through all of the steps from hello world, to using Plasma Components to configuration through to differing form factors.

It made sense to publish them as blog posts before I copy them to the wiki.

Behold, the first rather wordy blog post in a series of 7.

Intro

With Plasma5 we have embraced QML as our technology of choice. It is the only method of writing the UI for plasmoids.

Whilst Plasma4 offered a range of language, QML is the only way of interacting with QtQuick, the technology that powers the Plasma Shell. By using this we we get to provide a better developer experience as there is a wealth of existing QML resources. Some of the best links are:

• http://doc.qt.io/qt-5/qml-tutorial1.html
• http://qmlbook.org/

Before you get started with writing plasmoids, it is recommended to read through the basics of these and have a bit of playing to get used to the language.

Writing plasmoids is effectively the same as writing any other QtQuick QML, with a few extensions:

• We have a specific folder structure with metadata for our plasmashell to be able to load the files.
• We provide a massive collection of libraries that extend the QtQuick library both with functionality and widgets that blend in with the Plasma theme.
• Special API exists to interact with the shell, allowing you to save configurations or set default sizes.

In this series of tutorials we'll go through the steps of writing a real plasmoid from scratch, using some of the plasma libraries.

By the end we should have a completely working, deployable RSS reader.

Hello world

Initial Folder Structure

Plasmoids follow the simple KPackage structure. In the top-most folder there should be a file titled metadata.desktop and a single folder called "contents".

Inside the contents folder we place all our QML, assets and other additional files. We split the contents into subdirectories: config, data and ui to make things easier.

In our tutorial we will be making an RSS reader so everything is named appropriately to that.

The basic directory structure should be as follows:

myrssplasmoid/metadata.desktop
myrssplasmoid/contents/ui/main.qml

metadata.desktop

[Desktop Entry]
Name=RSS Plasmoid
Comment=Shows RSS Feeds
Encoding=UTF-8
Icon=applications-rss
ServiceTypes=Plasma/Applet
Type=Service
X-KDE-PluginInfo-Author=David Edmundson
X-KDE-PluginInfo-Email=davidedmundson@kde.org
X-KDE-PluginInfo-Name=org.example.rssplasmoid
X-KDE-PluginInfo-License=LGPL
X-KDE-PluginInfo-Version=1.0
X-KDE-PluginInfo-Website=http://techbase.kde.org
X-Plasma-API=declarativeappletscript
X-Plasma-MainScript=ui/main.qml

Most of the fields here should be fairly self explanatory.
If in doubt, copy this and change the relevant fields.

main.qml

import QtQuick 2.0

Item {
    Text {
        anchors.centerIn: parent
        text: "Hello World!";
    }
}

Providing you have followed the recommended reading this should be fairly self-explanatory, we have a text item in the middle of the plasmoid which will say "Hello World".

Over the next few tutorials this will get somewhat larger, we will also see some of the problems with this example; here translations aren't implemented and the text won't match the Plasma theme colour.

Installation

From the directory above run

plasmapkg2 --install myrssplasmoid

It should now be visible in the plasmashell in the "Add widgets" option along with every other plasmoid.

We can then it to our desktop or panel like any other installed plasmoid.

You will see that that the border and handles are automatically added, and that it is automatically sized to fit the implicit size of the text.

Next

Next tutorial, we will cover getting data from external sources.

28 Jan 2015 8:36pm GMT

Packages for the release of Plasma 5.2 are available for Kubuntu Plasma5 14.10 and our development release. You can get them from the Kubuntu Next Backports PPA for 14.10, users of the development release will get it as a regular update.

The 14.10 packages include updates to Qt 5.4 which will remove any Unity packages.

28 Jan 2015 8:07pm GMT

We have a nice new style for planet.kde.org. I think it is generally an improvement over what we had, but sadly it decides to force the oxygen font over my browser selected font.

If you're like me and can stand the oxygen font being forced over the font you chose on your configuration have a look at this article to see how to disable downloadable fonts.

Update: Unfortunately if you do that you'll lose the K-logo on the left because instead of an icon we're using a font to render it. So now I have to decide between unreadable (for me) oxygen font a having the broken K-logo on the top.

28 Jan 2015 7:13pm GMT

Season KDE is KDE's annual project to give helpers a more structured way to take part in KDE. It's inspired by Summer of Code of course.

Today I had the pleasure of launching the new Planet KDE website theme done by Ranveer Aggarwal. It looks very lovely and importantly makes the site a pleasure to browse on your phone. Everyone hug him and do report any bugs to bugzilla.

.

by

28 Jan 2015 6:57pm GMT

Hello, guys!

Last post was about my Google Code-in experience in general. This time I want to tell you about my work with Marble.

First of all, what is Marble? Marble is a virtual globe application which allows the user to choose among the Earth, the Moon, Venus, Mars and other planets to display as a 3-D model. It is free software under the terms of the GNU LGPL, developed by KDE for use on personal computers and smart phones.

(here is a screenshot of Marble)

So, what did I do for Marble during GCI-2014?

There were different kinds of tasks such as porting different widgets and plugins, I did two such tasks. The tasks I liked most were about creating my own game based on MarbleWidget.

(here is a screenshot of my Marble game)

One task, which I liked, too, was about creating my own historical map for Marble(in mercator projection). It is based on Baur map from 1870.

(here is a screenshot of my map run in Marble)

And the last three tasks were about creating my tour, which can take you to places all over the world. You can watch one here:

Last things I want to say are: special thanks to Torsten Rahn, Abhinav Gangwar and Jonathan Riddell(not from Marble team). These people are the best mentors ever!

Thanks for attention, use Qt and love KDE!

28 Jan 2015 5:49pm GMT

This will be the last post on this subject with the SoK tag, as the program comes to a close this week. I will however be contining
my efforts past the program dates. With that said..
I have been busy! The last couple weeks I have worked out the job DSL from scratch in Java/Groovy for the job-dsl-plugin.
This of course entailed, dusting off the bits of programming I took in university and learning much more.
My DSL takes a json config file and reads the variables in and proceeds to generate a full fledged job in Jenkins. This
makes job creation much simpler!
Due to the complexity of the task, and the extra effort put in to getting windows and OSX builds to
actually build (beyond the scope of the task) Ben has been nice enough to extend my project beyond the initial sok dates.
I plan on continuing my work with this for as long as necessary, and will maintain it if they allow.
As a student, this opportunity has been invaluable and I encourage anyone in the future that wants that extra experience to
refine your skills to participate in KDE's Season of KDE! You do not have to be a full time student to apply, I graduated years ago.
My new skillset includes:
Java/Groovy
Python
Jenkins
Docker
Building Qt5 + apps on 3 platforms (Linux, Windows, OSX)
KDE infrastructure

To say the least it has been a wild ride!

28 Jan 2015 12:17am GMT

Part of my project for Season of KDE was to make a UI for the existing Star-Hopper feature in KStars. I recently got to finishing it and decided to document it.

The Star-Hopper is an amazing feature present in KStars which allows you to find a path between two points in the sky. It is very commonly used in astronomy. If you have a bright star as a reference and you want to find an object in its vicinity, you start from your reference star and trace a route to the destination traversing a sequence of stars/pattern of stars.

The existing Starhopper backend present in KStars was showing the results on the terminal. So I worked on developing a frontend to display the results.

Here are steps on how to use the Star-Hopper feature in KStars :

1. Right click on your reference object on the Skymap to get a drop down menu. This object is your start point.

2. In the drop down menu, select "Starhop from here to" option.

3. A dotted line will appear. Move the mouse to your destination object and right click on it.

4. A dialog box requesting for FOV appears. If you have already selected FOV symbols. you will get a drop down menu to select within those FOV symbols. Otherwise you will be asked to enter the FOV in arcminutes.

5. Upon entering the FOV and clicking okay, you will either be presented with a dialog box containing list of objects in the Starhop route or an error dialog box if the Starhop route couldn't be computed (mostly because of small FOV)

The dialog box has options to produce details of the object, center the object in the map and go to the next object and center it in the map. It also gives directions to the current selected object below the list of objects.

Hope this blog post helps in using the Star-Hopper features. Any questions, feel free to drop into #kde-kstars

Cheers! :)

27 Jan 2015 6:57pm GMT

Yesterday I released version 0.8 of AppStream, the cross-distribution standard for software metadata, that is currently used by GNOME-Software, Muon and Apper in to display rich metadata about applications and other software components.

What's new?

The new release contains some tweaks on AppStreams documentation, and extends the specification with a few more tags and refinements. For example we now recommend sizes for screenshots. The recommended sizes are the ones GNOME-Software already uses today, and it is a good idea to ship those to make software-centers look great, as others SCs are planning to use them as well. Normal sizes as well as sizes for HiDPI displays are defined. This change affects only the distribution-generated data, the upstream metadata is unaffected by this (the distro-specific metadata generator will resize the screenshots anyway).

Another addition to the spec is the introduction of an optional <source_pkgname/> tag, which holds the source package name the packages defined in <pkgname/> tags are built from. This is mainly for internal use by the distributor, e.g. it can decide to use this information to link to internal resources (like bugtrackers, package-watch etc.). It may also be used by software-center applications as additional information to group software components.

Furthermore, we introduced a <bundle/> tag for future use with 3rd-party application installation solutions. The tag notifies a software-installer about the presence of a 3rd-party application bundle, and provides the necessary information on how to install it. In order to do that, the software-center needs to support the respective installation solution. Currently, the Limba project and Xdg-App bundles are supported. For software managers, it is a good idea to implement support for 3rd-party app installers, as soon as the solutions are ready. Currently, the projects are worked on heavily. The new tag is currently already used by Limba, which is the reason why it depends on the latest AppStream release.

How do I get it?

All AppStream libraries, libappstream, libappstream-qt and libappstream-glib, are supporting the 0.8 specification in their latest version - so in case you are using one of these, you don't need to do anything. For Debian, the DEP-11 spec is being updated at time, and the changes will land in the DEP-11 tools soon.

Improve your metadata!

This call goes especilly to many KDE projects! Getting good data is partly a task for the distributor, since packaging issues can result in incorrect or broken data, screenshots need to be properly resized etc. However, flawed upstream data can also prevent software from being shown, since software with broken data or missing data will not be incorporated in the distro XML AppStream data file.

Richard Hughes of Fedora has created a nice overview of software failing to be included. You can see the failed-list here - the data can be filtered by desktop environment etc. For KDE projects, a Comment= field is often missing in their .desktop files (or a <summary/> tag needs to be added to their AppStream upstream XML file). Keep in mind that you are not only helping Fedora by fixing these issues, but also all other distributions cosuming the metadata you ship upstream.

For Debian, we will have a similar overview soon, since it is also a very helpful tool to find packaging issues.

If you want to get more information on how to improve your upstream metadata, and how new metadata should look like, take a look at the quickstart guide in the AppStream documentation.

27 Jan 2015 4:48pm GMT

The ever-amazing Plasma team from KDE just put out a new release of Plasma. I won't spend much describing how big of an improvement it is - the release announcement at KDE has all the details needed to whet your appetite.

And of course, now it's the turn of distributions to get out packages for the users at large.

This is also the case for openSUSE. The KDE:Frameworks5 repository hosts the new 5.2 goodness for released distributions (13.1 and 13.2) and Tumbleweed. Packages have also been submitted to Tumbleweed proper (pending legal review, so it will take some time).

Don't forget the rule of thumb, in case you find problems: bugs in the packages should be directed towards the openSUSE bugzilla, while issues in the actual software should be reported to KDE. You can also discuss your experience on the KDE Community Forums.

27 Jan 2015 3:27pm GMT

Today we released Plasma 5.2 and this new release comes with two fixes for security vulnerabilities in our screen locker implementation. As I found, exploited, reported and fixed these vulnerabilities I decided to put them a little bit into context.

The first vulnerability concerns our QtQuick user interface for the lock screen. Through the Look and Feel package it was possible to send the login information to a remote location. That's pretty bad but luckily also only a theoretical problem: we have not yet implemented a way to install new Look and Feel packages from the Internet. So we found the issue before any harm was done.

The second vulnerability is more interesting as it is heavily related to the usage of X11 by the screen locker. To put this vulnerability into context I want to discuss screen lockers on X11 in general. In a previous post I explained that a screen locker has two primary tasks:

1. Blocking input devices, so that an attacker cannot interact with the running session
2. Blanking the screen to prevent private information being leaked

From the first requirement we can also derive a requirement that no application should get the input events except the lock screen and that the screen gets locked after a defined idle time. And from the second requirement we can derive that no application should have access to any screen content while the screen is being locked.

With these extended requirements we are already getting into areas where we cannot have a secure screen locker on X11. X11 is too old and too insecure to make it possible to fulfill the requirements. Why is that the case?

X11 on a protocol level doesn't know anything of screen lockers. This means there is no privileged process which acts as the one and only screen locker. No, a screen locker is just an X11 client like any other (remote or local) X11 client connected to the same X server. This means the screen locker can only use the core functionality available to "emulate" screen locking. Also the X server doesn't know that the screen is locked as it doesn't understand the concept. If the screen locker can only use core functionality to emulate screen locking then any other client can do the same and prevent the screen locker from locking the screen, can't it? And yes that is the case: opening a context menu on any window prevents the screen locker from activating.

That's quite a bummer: any process connected to the X server can block the screen locker. Even more it could fake your screen locker. How hard would that be? Well I asked that question myself and needed about half an hour to implement an application which looks and behaves like the screen locker provided by Plasma 5. This is so trivial that I don't see a point in not sharing the code:

#include <QGuiApplication>
#include <QQuickView>
#include <QQmlContext>
#include <QScreen>
#include <QStandardPaths>
#include <QtQml>

class Sessions : public QObject
{
    Q_OBJECT
    Q_PROPERTY(bool startNewSessionSupported READ trueVal CONSTANT)
    Q_PROPERTY(bool switchUserSupported READ trueVal CONSTANT)
public:
    explicit Sessions(QObject *parent = 0) : QObject(parent) {}
    bool trueVal() const { return true; }
};

int main(int argc, char **argv)
{
    QGuiApplication app(argc, argv);

    const QString file = QStandardPaths::locate(QStandardPaths::GenericDataLocation,
        QStringLiteral("plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreen.qml"));

    qmlRegisterType<Sessions>("org.kde.kscreenlocker", 1, 0, "Sessions");
    QQuickView view;
    QQmlContext *c = view.engine()->rootContext();
    c->setContextProperty(QStringLiteral("kscreenlocker_userName"),
                          QStringLiteral("Martin Graesslin"));
    c->setContextProperty(QStringLiteral("kscreenlocker_userImage"), QImage());
    view.setFlags(Qt::BypassWindowManagerHint);
    view.setResizeMode(QQuickView::SizeRootObjectToView);
    view.setSource(QUrl::fromLocalFile(file));
    view.show();
    view.setGeometry(view.screen()->geometry());
    view.setKeyboardGrabEnabled(true);
    view.setMouseGrabEnabled(true);

    return app.exec();
}

#include "main.moc"

This looks like and behaves like the real screen locker, but it isn't. A user has no chance to recognize that this is not the real locker. Now if it's that simple to replace the screen locker why should anyone go a complicated way to attack the lock screen? At least I wouldn't.

And is there nothing which could be done to protect the real locker? Well obviously a good idea is to mark the one and only screen locker as authentic. But how to do that in a secure way on X11? We cannot e.g. show a specific user selected image. This would conflict with another problem with screen lockers on X11: it's not possible to prevent that other windows grab screen content. So whatever the screen locker displays is also available to all other X11 clients. Also the window manager cannot help like preventing fullscreen windows to open fullscreen as can be seen in the code fragment above: it's possible to bypass the window manager. Built in feature by X11.

Many of these issues could be considered as non-problematic using the old pragma of "if it runs, it's trusted". While I personally disagree, it just doesn't hold for X11. If only clients of one user were connected to the X server one could say so. But X11 allows clients from other users and even remote clients. And this opens a complete new problem scope. Whenever you use ssh -X you open up your local system to remote attack vectors. If you don't control the remote side it could mean that the client you start is modified in a way to prevent your screen from locking or to install a fake locker. I know that network transparency is a feature many users love, but it's just a security night mare. Don't use it!

Overall we see that attacking a screen locker or preventing that it opens up is really trivial on X11. That's an inherent problem on the architecture and no implementation can solve them, no matter what the authors tell how secure it is. Compared to these basic attack vectors the vulnerability I found is rather obscure and it takes a considerable amount of understanding how X11 works.

Nevertheless we fixed the issue. And interestingly I chose to use the technology which will solve all those problems: Wayland. While we don't use Wayland as the windowing system we use a custom domain-specific Wayland-based protocol for the communication between the parts our screen locker architecture. This uses the new libraries developed for later usage in kwin_wayland.

As we are speaking of Wayland: how will Wayland improve the situation? In the case of Plasma the screen locker daemon will be moved from ksmserver to kwin, so that the compositor has more control over it. Screen locking is a dedicated mode supported by the compositor. Whether a context menu is open or not doesn't matter any more, the screen can be locked. Also the compositor controls input events. If it has the knowledge that the screen is locked, it can ensure that no input goes to the wrong client. Last but not least the compositor controls taking screenshots and thus can prevent that clients can grab the output of the lock screen.

27 Jan 2015 11:49am GMT

Dear lazyweb,

using a ThinkPad X1 Carbon with Debian unstable and KDE 4.14.2, I have not had battery warnings for a few weeks, now.

The battery status can be read out via acpi -V as well as via the KDE widget. Hibernation via systemctl hibernate works as well.

What does not work is the warning when my battery is low, or automagic hibernation when shutting the lid or when the battery level is critical.

From what I gather, something in the communication between upower and KDE broke down, but I can't find what it is. I have also been told that Cinnamon is affected as well, so this seems to be a more general problem

Sadly, me and anyone else who's affected has been unable to fix this.

So, dear lazyweb, please help.

In loosely related news, this old status is still valid. UMTS is stable-ish now but even though I saved the SIM's PIN, KDE always displays a "SIM PIN unlock request" prompt after booting or hibernating. Once I enter that PIN, systemd tells me that a system policy prevents the change and wants my user password. If anyone knows how to get rid of that, I would also appreciate any pointers.

25 Jan 2015 8:44pm GMT