kdesrc-build is a very useful tool, here's why

I've been thinking for some time about writing a post about my favorite tool for building, rebuilding, testing, fixing random parts of kde software and how I use it (many times a day, depending on the situation).

For anyone that doesn't know, kdesrc-build is a script, written in perl, it lives in extragear/utils/kdesrc-build in the kde project heirarchy and can be cloned from kde:kdesrc-build if you've got your ~/.gitconfig as follows (if you don't you should add it, go add it now, I'll wait):

[url "git://anongit.kde.org/"]
       insteadOf = kde:
[url "git@git.kde.org:"]
       pushInsteadOf = kde:

kdesrc-build is very useful in that running it with no arguments it will build all of your kde stack. This includes all the frameworks (including Qt if you want it to), all library dependencies that come from git.kde.org and all applications. To start using it, just clone it, build it (mkdir build, cd build, cmake ../, make, make install, or sudo make install if you aren't the owner of /usr/local yet) and you can run kdesrc-build from any path your terminal happens to be in. The one thing needed is a .kdesrc-buildrc file to tell it what you want to build, where you want it installed to, which build options etc. you want. This is pretty straightforward though and most of the kde stack is in include files you can add from your .kdesrc-buildrc itself. Mine looks like this:

# Adjust all these settings at will

global


 qtdir /usr
 # qtdir /home/jeremy/devel/kde/src/qt5bulid/qtbase
 source-dir /home/jeremy/devel/kde/src
 build-dir /home/jeremy/devel/kde/build
 kdedir /usr/local

 git-repository-base kde-projects kde:

 cxxflags -pipe -DQT_STRICT_ITERATORS -DQURL_NO_CAST_FROM_STRING -DQT_NO_HTTP -DQT_NO_FTP -Wformat -Werror=return-type -Wno-variadic-macros -Wlogical-op
 # WARNING: opensuse users need -DLIB_SUFFIX=64 here, as long as FindKDE4Internal.cmake is used
 #          if you're using a distro without "lib64", remove the option.
 # cmake-options -DKDE4_BUILD_TESTS=TRUE -DLIB_SUFFIX=64
 cmake-options -DBUILD_TESTING=TRUE -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_LIBDIR=lib

 make-options -j8
 #install-session-driver true
 branch-group kf5-qt5

end global

include devel/kde/src/extragear/utils/kdesrc-build/kf5-qt5-build-include

I go back and forth sometimes between distro packaged qt (in /usr) and my own built qt from git (in the other path) so I uncomment the one I want to use in those first few lines.

It's pretty simple and short, set 9 variables, include the kf5-qt5-build-include file and we're good to go. So for me, kdesrc-build with no arguments builds and installs many different kde applications, with their sources nicely organized under ~/devel/kde/src and their build folders easy to delete if needed in ~/devel/kde/build and installs into /usr/local where I have my XDG_* variables set to find applications, libraries, data, default configurations, etc. Also if some part of the workspace becomes deprecated and I need to remove old libraries, .desktop files, and such I can safely (from a terminal, not within X) nuke /usr/local/* and rerun kdesrc-build to rebuild everything that's current.

kdesrc-build frameworks - builds all the parts of kf5 itself.

kdesrc-build kdeedu - builds all the libraries and applications that have been ported to qt5/kf5 from kdeedu.

kdesrc-build --no-src kanagram - builds kanagram with my local changes for testing before committing the next feature, also useful to test patches from reviewboard (download, patch, kdesrc-build --no-src foo to build/install, run to test).

kdesrc-build --no-src khangman - builds whatever I've got checked out in kde/kdeedu/khangman at the time (currently an almost complete gsoc student's qml ui of khangman from his branch).

kdesrc-build --refresh-build - rebuilds everything with clean build folders using the cmake options from your .kdesrc-buildrc file, this is useful if you change these options and want to test them

kdesrc-build --refresh-build --no-src foo - rebuilds everything with a clean build and doesn't do any git updates, only tries to build what's on your local clone, this is useful when porting applications to kf5/qt5 to make sure cmake is reran when trying a build of local changes.

A good thing to know is that errors are all logged, and you can check them simply by checking source-dir/log/latest/foo/error.log (which symlinks to cmake.log, build.log, or install.log, depending where the error was).

One more nice thing, since kdesrc-build uses kde-project-metadata it can guess some projects from their location on projects.kde.org. So even if I don't have skrooge or some other extragear application in my .kdesrc-buildrc file or it's not in the included kf5-qt5-build-include file or whatnot, kdesrc-build skrooge will guess where skrooge comes from and clone it to the proper place in the heirarchy and build it.

In summary, kdesrc-build is useful for what it was created for, building the kde stack of software with your preferences.

Gardening Recipes

You thought this would have something to do with working outside and/or cooking something. You were wrong.

As Albert blogged previously the KDE gardening team's love project this time is KRecipes.
The mailing list has been moved.
The website content has been added to userbase.
The 2.0 release is on upload.kde.org, soon to be moved into place (a new place since download.kde.org hasn't done a krecipes release before).

Anyone that would like a relatively small way to quickly help KRecipes out it could use some patches on reviewboard (group added, sending to the new mailing list already) to port away from Qt3support classes. Some other ideas off the top of my head also:

1. Make it use kunitconversion to convert metric units to imperial units for those of us stuck in countries that use imperial measuring systems.
2. Freshen up the ui a bit so it looks less like a database viewer and more like a recipe viewer/editor.

KDE Fundraiser 2014

In case you didn't hear, KDE is running a fundraiser which helps fund sprints and other expenses of your favorite desktop/applications/games brought to you by the KDE community. Plus there are cool konqi postcards!

Ok, back to your regularly scheduled blog reading, have a nice day.

Autostart in Plasma 5

In the past few days as I got more and more annoyed that git pushes and svn updates and commits were always asking for my ssh key password I looked at what the current status of plasma autostart is. When I set up my plasma 5 environment I copied all the scripts that were in ~/.kde/Autostart to ~/.config/autostart thinking they would "just work" there, but it turns out they don't. My needs are simple I only had two .sh bash scripts in there, one for running ksshaskpass to ssh-add my ssh key. The other to launch synergys on login. Both scripts showed up in the autostart kcm, but neither was getting launched at login time.

Digging a bit in the code of kinit and klauncher I found that when it looks at ~/.config/autostart it only looks for .desktop files. It turns out this comes from an xdg spec for autostart scripts. Ok, simple enough, so I removed my synergys.sh script and in the autostart kcm created a new autostart item that launches synergys for me at login time. Works like a charm.

Next I went to look at ssh-add using ksshaskpass (there's a kf5 port of ksshaskpass in kdereview now by the way, which works pretty well and has some small improvements from the kdelibs4 version). For one thing, files that aren't .desktop files in ~/.config/autostart aren't getting launched, because klauncher doesn't even look at them. To fix this the autostart kcm was modified to not show these anymore.

The other question then is where should plain bash scripts be put that users and sysadmins used to put into ~/.kde/Autostart ? One solution is to put them into ~/.config/plasma-workspace/env/ . This is what I did here with ssh-add.sh and that works fine. The only thing to note though is that these are sourced, not executed, and they are sourced before plasma has started, so they can set environment variables and such if needed. This may not be ideal for scripts that need to talk to running services, so we may need to add something to ksmserver to launch scripts from ~/.config/ksm-autostart or something like that. There's a bug about it here https://bugs.kde.org/show_bug.cgi?id=338242 already, so don't file new bugs about this issue.

Accessibility is alive (QtSpeech progress, Jovie's deprecation)

For some time I've been considering what to do about Jovie which was previously known as ktts (KDE Text To Speech). Since before the first KDE Frameworks release actually, since kdelibs used to host a dbus interface definition for the KSpeech dbus interface that ktts and then Jovie implemented. I have a qt5 frameworks branch of Jovie, but it didn't make much sense to port it, since a lot of it is or could become part of the upcoming QtSpeech module. So Jovie has no official qt5 port and wont be getting one either.

What will Okular, KNotify, and other applications that want to speak to users do instead? The answer is QtSpeech. QtSpeech is a project started by Frederik Gladhorn to bring speech api's to all the platforms that Qt supports. It is still in its infancy, but is quickly improving. A few weeks ago when I built my kf5 stack with kdesrc-build I noticed that kdepim(libs?) was depending on it and it hasn't been released yet, so I got motivated to send some improvements to qt-project. Frederik and Laurent Montel have been pushing fixes and improving it also. It is as easy if not easier to use than the KSpeech dbus api (and doesn't require dbus either) and can be used to speak text on linux/unix, osx, windows, and android platforms so far. If you are an expert on any of these platforms please send patches to implement api on these platforms in their backends, the more eyes on this project the faster we can get it solidified and released.

You may be asking but what about feature X in Jovie that I will miss desperately. Yes there are a few things that QtSpeech will not do that Jovie did. These will either need to be done in individual applications or we can create a small framework to add these features (or possibly add them to QtSpeech itself if they make sense there). The features I'm thinking of are:

1. Filtering - Changing ": Hey QtSpeech is really coming along now" to "jpwhiting says 'Hey QtSpeech is really coming along now'" for KNotifications and the like. This could likely be implemented easily in knotify itself and exposed in the notifications configuration dialog.
2. Voice switching - Changing which voice to use based on the text, or the application it is coming from or anything else. This might make sense in QtSpeech itself, but time will tell if it's a wanted/needed feature.
3. User configuration - Jovie had a decent (not ideal, but it was functional) ui to set some voice preferences, such as which voice you wanted to use, which pitch, volume, speed, gender, etc. This will become the only part of Jovie that will get ported, which is a KDE Control Module for speech-dispatcher settings. This may also change over time, as speech-dispatcher itself possibly grows a ui for it's settings.

All in all, progress is being made. I expect QtSpeech to be ready for release with Qt 5.5, but we'll see what happens.

Upcoming KDE Applications 14.12 release prep

Hello,

In preparing for the upcoming releases of KDE Applications 14.12 (2014 Month 12) I realized the other day that we have an interesting situation.  For Qt4 based applications there's libkdeedu which contains the kvtml parsing and manipulating code and also a handful of .kvtml files that KAnagram and KHangMan use to get their word lists. KAnagram has been ported to Qt5 and KDE Frameworks for some time now, and will have it's first Qt 5 based release at the end of this year. It uses libkeduvocdocument which was ported to Qt 5 also at about the same time this year. libkeduvocdocument uses Qt 5 and KDE Frameworks 5, and also ships the same handful of kvtml files that libkdeedu ships. (libkdeedu has been split for the Qt 5 based releases) KHangMan hasn't yet been ported to frameworks and Qt5 or at least the port isn't stable yet, so it will depend on libkdeedu still, as will KWordQuiz and Parley from what I understand. So we have two libraries that ship the same files, makes them not coinstallable. So we'll be moving the kvtml files out of the libraries and into kdeedu-data soonish to solve this problem. The moral of this story is to look around, see what will be released using Qt5 in the upcoming release, and what will be using Qt4 still. https://community.kde.org/Frameworks/Application-release-status-December-2014 may help also. If you maintain an application and haven't put your application on that page under the Qt4 or Qt5 tables yet, please do, the more we coordinate, the better this release will be.

Thanks, and keep up the good work all.

Simple Elegance

I just noticed a couple of features today and yesterday in plasma next and kwin that I appreciate and wanted to thank whoever thought of adding them. Both are simple but very handy to have. I'm talking about the little X buttons on both the wallpaper configuration dialog and the kwin present windows effect. I don't use either of these features very often, but yesterday when I was testing knewstuff with the wallpaper config it was very handy to be able to delete the installed wallpaper from the wallpaper selection dialog. Then just now it was very handy to be able to close extra windows I had open that I no longer need when I was in the present windows effect looking at what I need to be doing next. Makes it very simple to clean up a workspace.

Just throwing this out there, thanks whoever added these simple nice features.

Plasma Next Improvements and KApplication -> QApplication gotchas

tldr, if you port from KApplication to QApplication, remove the %i from the Exec lines of your .desktop files.

Hey all, so I've been running plasma-next on my main development machine for a month or two now and have definitely enjoyed the speed at which improvements come. Just in time for plasma 5.1 release timezone support was added to the digital clock, so you can choose which timezones you want to see, use your mouse scrollwheel to change which one is visible, and so on. Also because our translators are awesome we got a last minute change in after the string freeze with their permission to show all the configured timezones in the clock's tooltip (similar but not identical to how it worked in kdelibs4 based plasma times). I enjoy the new Breeze theme and icons, and the alternatives system for switching between different k-menus, different task managers (I'm currently enjoying the icons only one) etc. is so handy.

In other news something that has been bothering me for a while is that okular just didn't want to get launched from any visual launcher. Clicking on a pdf in dolphin acted like it was launching, but no Okular ui would appear. Clicking view book on pdf books in Calibre would do likewise. So I spent a couple of days adding debug messages to kinit and klauncher trying to figure out what was going on. Kate launches just fine, so I tried copying the kate.desktop to okularApplication_pdf.desktop and replaced kate with okular etc. and that worked fine also.

So today I asked Albert if he had any ideas and got thinking it had to be something in the .desktop files themselves. So I uncommented another qDebug line in klauncher that said exactly what it was asking kinit to start and found it using "/usr/local/bin/okular blah.pdf --icon okular. So I tried the same from a terminal and found that okular's binary failed to launch because it doesn't understand the --icon parameter. A bit of digging found that KApplication handled that argument, while QApplication doesn't and the frameworks port of okular like a good example ported from KApplication to QApplication already.
Klauncher puts --icon blah in when you have %i in the Exec line of the .desktop file. So if you port from KApplication to QApplication, be sure to remove the %i from the .desktop files of your application also.

Plasma Next is pretty darn stable

Today I wanted to share some of my experiences with using Plasma Next for the past couple of weeks. Since I had been working on some frameworks development (just a small bit here and there), I thought I'd try running Plasma Next a couple of weeks ago to see how things were coming along and to be able to work on and test some things I helped with back in KDE 4.0 days.

I have to say I'm very impressed with the stability.  I hit two issues since then, and one of the issues has been fixed. The issue I hit that has already been fixed was a crash in yakuake or konsole when closing a tab that caused the whole application to crash. I looked into the Konsole codebase with Eike Hein's guidance, but Argonel ultimately found the best patch to fix the problem.
The second issue I hit with Plasma Next has to do with disconnecting and reconnecting an external monitor. I don't do that very often at all, but when I tried last weekend I got a variety of issues. For example sometimes when disconnecting Plasma (or maybe KSmServer?) crashes and I am taken back to the sddm login screen. Other times when connecting my external screen my panel ends up floating on the external monitor but nothing on it is clickable.

I just realized this post probably sounds like a rant or complaining about Plasma Next, but that's not what I intended at all. The main point I wanted to get across is that I haven't used Plasma more than once in the past 2 weeks since Plasma Next is stable enough for my usage.

Now for the obligatory desktop screenshot:

So good job to all the people that have worked on this new iteration of the Plasma Desktop.

P.S. One other minor thing I miss from plasma is the ability to show multiple timezone's times in the clock's tooltip. I'll see if I can get that fixed though. :)

Qt5/KDE Frameworks porting steps

As I said in my last post I would elaborate about how porting of libkeduvocdocument (name pending currently) from Qt4 and kdelibs4 to Qt5 and KDE Frameworks happened.

Commits can be seen here but it went like this:
1. Change CMakeLists.txt to look for frameworks and Qt5 packages.
2. Try to build, fix any errors. All while checking the Porting Notes.
3. Port away from deprecated methods.
4. Port away from kdelibs4support.

I forget which part of the above involved each of these, but this is what was changed:
Ported from KUrl to QUrl.
Ported from KStandardDirs to QStandardPaths
Ported from KGlobal::locale() to QLocale
Ported away from other deprecated methods and classes.

So rinse and repeat until it's in a state where you are happy with it.
Note that step 4 above isn't strictly necessary, and is similar to porting Qt4 applications away from Qt3Support (Some kde4 applicationss never were ported away from Qt3Support sadly...) Yes KMouth, I'm looking at you.

Libkeduvocdocument Qt5/KDE Frameworks port

Hello all. Yes I'm still alive. Yes I'm still doing KDE stuff as I find time or make time. I'll report in the next few posts about what is happening and where we are going.

One of the things that happened recently was the port of libkeduvocdocument to Qt5 and frameworks. Vishesh started the effort, and I completed it with some review by Aleix Pol. It was decided as documented here that since libkdeedu only contains libkeduvocdocument it should be split up. Upon further investigation we realized that the other parts of libkdeedu are not used anymore. Besides the icons subfolder that are still looking for a home, the rest of the git repo is only libkeduvocdocument related, so we decided to just rename the git repository for the frameworks and going forward release. So the libkdeedu git repository holds the kde sc 4 codebase, while the libkeduvocdocument git repo holds the qt5 and frameworks based code. Both contain the history so all history is preserved. 

I'll write next time about the steps taken to port the library to Qt5 and KDE Frameworks.