The Fedora KDE SIG brings you all the new and cool stuff from KDE Frameworks and Plasma Next worlds!
First, our Copr repository with KDE Frameworks has been updated to 4.99.0 release, so go get it! All frameworks are co-installable with KDE 4, so you can develop against KF5 without needing any special setup. Also KDE Frameworks 5 were approved as feature for Fedora 21, which means that in next Fedora release, we will ship all Frameworks in the Fedora repositories! There are already some packages imported into rawhide, the rest will follow in next weeks.
We packaged as much as we could (but still not everything!), including Rekonq, Dolphin, System Settings, Baloo, Milou and more - all built against Qt 5 and KDE Frameworks 5 of course.
If you are really interested in trying locally, you can check out all the additional packages from kde-frameworks-unstable and plasma-next COPRs, but remember that all packages from those repositories install to /usr, so you will get conflicts with KDE 4 packages.
First technological preview of KDE Frameworks 5 has been released few weeks ago, a clear signal for us in Fedora KDE SIG to roll up our sleeves, heat up the builders and start packaging. For the last few days Martin Bříza, Jan Grulich, Lukáš Tinkl, Siddhart Sharma and I were working on bringing KDE Frameworks and Plasma 2 to Fedora. Now we are done and you can try out current technological preview of KF5 and Plasma 2 directly on your system without having to compile anything or messing up your default profile.
If you are a KDE developer, a Qt developer interested in using KF5 in your application or just a curious user, all you have to do is adding kde-frameworks repo to yum and install the packages! The repository is available in Copr, just download the repo file to /etc/yum.repos.d and you can start using Frameworks and Plasma 2. All Frameworks packages are prefixed with kf5- to prevent conflicts with regular packages and at this point they are installed into /opt/kf5 prefix instead of /usr
If you install kde5-workspace package, you can also have a sneak peek at what Plasma guys are doing for Plasma 2! Your display manager should have “KDE Plasma Workspace 2” entry in session types list, which will log you into Plasma 2 session. Just remember that Plasma 2 is still under heavy development and not yet ready for day to day use.
We will now start making the KDE Frameworks 5 packages co-installable with KDE 4 into regular prefix and hopefully we will ship KDE Frameworks 5 as a feature in Fedora 21 available to everyone.
Btw if you are coming to Brno for DevConf (February 7th - 9th) and want to know more about KDE Frameworks and Plasma 2, make sure to visit “KDE Frameworks 5” talk by me and Siddhart Sharma ;-)
As some of you might have noticed, display management in KDE is not really something we could be proud of. It does not work as expected, it lacks some features and it’s not really maintained. Time to change it, don’t you think? :-)
The effort was initiated by Alex Fiestas (who is too busy to making KDE rock, so the blog post is up to me :-)). Alex has written the libkscreen library that provides information about available/connected/enabled outputs and notifications about their changes. He also intends to write a KDED daemon that would listen for these events and depending on connected monitors (every monitor can be uniquely identified by it’s EDID) it would load specific configuration. For example, docking your notebook into a docking station at work would automatically turn on a second monitor and place it left of the notebook screen (or whatever you configure the first time you do it). Undocking the notebook and connecting a data projector in a meeting room would automatically set clone mode etc. etc.
This also requires a new UI in System Settings which is the part I’m working on.
It’s written in QML and allows you to configure your displays by dragging them around rather than configuring them through combo boxes. Picture is worth a thousand words, and when it’s a moving picture, well…..
Download OGV (1.8 MB)(in real time the animations are faster and smoother of course)
The best part of all this is that users won’t be exposed to the KCM very often, because connecting an already-known monitor will configure it and place it automatically depending on the last configuration. Connecting a previously unknown output should pop up a simple window/dialog where user can quickly select whether the display should be left/right/clone of the active screen or open the KCM and perform more advanced configuration.
New Output Plasma Notification
(Note: this is just a preview, we will have the icons made by someone sane)
Right now I’m abusing the krandrtray icon for the applet. It does not provide any rich features like krandrtray though, it only has a context menu with a single action to start the KCM. This should be enough because unlike current krandr-based display configuration there most things will work automagically.
And of course we will take care of displaying these dialogs and windows on the correct screen (that is the one that is connected and enabled) :-)
Finally, we want to use KWin scripting engine to display a black overlay over the entire desktop when changing display configuration in order to hide Plasma flickering and resizing from users and make it look like a smooth transition.
This semester I attended Advanced Topics of Linux Administration course on my university. To successfully complete the course, one must pass an exam, have a presentation and write an article on a related topic. I had a presentation about libvirt and decided to write an introduction into using libvirt’s API (the article has been published (in English) on Czech Linux portal ABCLinuxu.cz).
As an example, I have written a Plasma Applet in QML (yay, my first QML thingie!) and a Plasma DataEngine that serves data about QEMU/KVM virtual machines running under local libvirtd.
On the applet you can watch state of all virtual machines, you can boot/pause/resume/shutdown and reboot them and configure soft and hard memory limits and amount of virtual CPUs allocated to each machine.
Pictures!
I must admit that I was always a bit skeptical about QML, but my two previous encounters with QML made me really curious about it and writing this applet was really painfun and it taught me a lot about QML.
The big advantage of the DataEngine is that it’s not constantly polling libvirt for changes, but it rather utilizes it’s events API.
Wanna try? :-) There’s a tarball here and git repo here: git://anongit.kde.org/scratch/dvratil/plasma-virt-monitor
It was fun to hack and I plan to give it some more love, possibly after Akademy.
PS: Akademy - anyone flying on Friday at 08:10 from Vienna :-) ?
