Archive for December, 2013

Scripting KMix via DBUS : kmixremote

KMix has a long history of having a remote interface. But whether it was based on DCOP or DBUS, it has always been an expert tool. For some common tasks like muting the master or setting a volume, the hurdles have been too high for many users and script developers.
Starting with the next release KMix ships a small script kmixremote, that makes things very easy: You can mute, get and set volume levels, and list soundcards and controls. This bash script can also serve as a starting point for developers interested in creating scripts or 3rd party apps.
This was a two hour excursion back into bash scripting for me. I found it entertaining as I am not doing a lot of those anymore. I hope you find the result useful.

Local usage example:

Shown are (in this order) listing soundcards, listing controls of a specific soundcard. After that reading, modifying, and reading the (modified) volume level again:

chris@whitefall # kmixremote list
chris@whitefall # kmixremote list  ALSA__Creative_X_Fi_1
chris@whitefall # kmixremote get  ALSA__Creative_X_Fi_1 PCM_0 
chris@whitefall # kmixremote set  ALSA__Creative_X_Fi_1 PCM_0 70
chris@whitefall # kmixremote get  ALSA__Creative_X_Fi_1 PCM_0 

Remote usage example:

Remote usage does not differ from local usage. You only have to make sure you have a remote login, and permissions to access the X11 server where KMix is running. In the example, I am using “DISPLAY=:0”:

chris@remote-pc: ssh user@pc-with-kmix DISPLAY=:0 /usr/bin/kmixremote

SoundMenu additons. New KMix Configuration Dialog.

Responsive KMix

The new Configuration dialog (right). The Sound Menu (left) reflects the selected controls, and also shows the new “Pause” icon, as Clementine is currently playing and can be paused.

I took a small vacation from work to research relocation possibilities. While I was home I also spent time on completing the announced configuration dialog update and for updating the Sound Menu. KMix is more responsive,  playback changes being reflected by KMix. Thanks to the communication infrastructure established done during the Multimedia Sprint 2012 in Randa it was easy to keep KMix consistent. Additionally I refactored  the code for future additions like showing album picture.

  • Media Player playback status is reflected by Sound Menu. Shows media-playback-start or media-playback-pause.
  • Configuration dialog overhaul; Options are grouped in tabs and the apply button is responsive.
  • Configuration of the Sound Menu has been integrated in the configuration dialog as separate tab
  • Volume Overdrive up to 150% now officially supported for PulseAudio due to popular request.
  • Less CPU usage and latency for MPRIS2.
  • Sound Menu position optimized for all 4 panel positions (Bottom, Left, Top, Right)

The end of year 2013 is nearing. We will all see an exciting Year 2014 with Plasma 2 waiting in the wings.

See you all there,

Technical stuff

If you are interested in the source code changes, is the biggest commit, and it also contains references to features and bugs. For the technical interested: It is based on KConfigDialog and KConfigSkeleton [1], which is a very cool technology I discovered recently. If you do not know KConfigDialog and KConfigSkeleton, here is a short overview:

KConfigSkeleton + KConfigDialog

  • KConfigSkeleton links configuration entries from a property file with variables (e.g. a QString)
  • There are methods to copy from property file to configuration variables and vice versa
  • KConfigDialog can use a KConfigSkeleton, to prefill e.g. a related QCheckBox
  • KDE Techbase recommends KConfigXT. But KMix is a fine example without.

The OpenSource Eclipse Kepler C++ KMix productivity boost

Today I’d like to share a revelation with you:

Developing C++ can actually be fun.


How you work can define your productivity

In the next sections I will tell you a bit about how I develop KMix today, and why the newest toolchain gave me a productivity boost. As a peek ahead, this post is mainly about developing KDE applications with Eclipse.

If you just came across this post via searching for Eclipse,  C++ and cmake, then you might want to directly head to the practical example at the end of this post.

The core message is that the environment you work with can have a very high impact on productivity. As an example, see the picture to the right from my office: Isn’t this a more comfortable environment than – a cubicle? OK, I was talking about productivity, wasn’t I? So lets forget the image quickly. 😉

The C++ nuisance and rant

Honestly, most of the time  C++ development is a nuisance for me. For a better understanding, you should know that I am a 95% Java developer nowadays. And if you do a lot of Java, C++ is full of strangeness:

CMake and Eclipse as a rescue boat

If you get good tool support, C++ can still be a very good language. CMake helps a lot. For the source code editor it is more complicated: In the past I used every viable tool for KMix development, including misc versions of emacs, vi, aXe, kate, KDevelop and Eclipse CDT. All have their own strengths, but I could use none of them well for KMix development. Then recently I did a new shot at Eclipse CDT (Kepler based), and I am actually delighted.

  • The CMake integration now works flawless for me
  • The C++ indexer is super-fast and reliable (a massive weakness in former versions)
  • Navigation for header to source and back finally works and is very fast. Signals and Slots are parsed correctly and can be navigated.
  • Call hierarchies work great most of the time. In some C++ specific constructs they do not work, but using “references” is a good alternative.
  • Even the strangest #define and #include constructs work as expected.
  • Warnings, Errors, TODO’s and so forth are shown by default very appropriately in the editor and the other Eclipse Views. Very comfortable if one is accustomed to Eclipse.

KMix is a pretty small project, so mileage may vary for your project. Still I recommend to try “Eclipse Kepler CDT” if you have not done so recently. It brought back the fun in development for me.

Practical guideline for developing KDE applications with Eclipse

The basic step to build an Eclipse project is:

cd kmix-git-trunk.obj; cmake -G”Eclipse CDT4 – Unix Makefiles” ../kmix-git-trunk

As a reference, kmix-git-trunk.obj is where I build kmix, kmix-git-trunk is the GIT checkout. After that you can import the project into Eclipse. Run the above command again whenever required and refresh the whole source tree in Eclipse (F5) after that. Personally I am using Eclipse only to edit the source code, to navigate and browse quickly through sources, headers and includes. Everything else I am doing from a console window, like building, running, debugging and version control (GIT).
(Update 2013-12-16: Debugging works fantastic from within Eclipse, so I will use that from now on)

Thanks if you read until the end. If you have any input, experience or feedback, please leave a comment.