Tag Archives: Programmieren

dLeyna updates and general project things

I have too many projects. That’s why I also picked up dLeyna which was laying around looking a bit unloved, smacked fixes, GUPnP 1.2 and meson support on top and made new releases. They are available at

  • https://github.com/phako/dleyna-core/archive/refs/tags/v0.7.0.tar.gz
  • https://github.com/phako/dleyna-connector-dbus/archive/refs/tags/v0.4.0.tar.gz
  • https://github.com/phako/dleyna-server/archive/refs/tags/v0.7.0.tar.gz
  • https://github.com/phako/dleyna-renderer/archive/refs/tags/v0.7.0.tar.gz

Furthermore I have filed an issue on upstream’s dLeyna-core component asking for the project to be transferred to GNOME infrastructure officially (https://github.com/intel/dleyna-core/issues/55).

As for all the other things I do. I was trying to write many versions of this blog post and each one sounded like an apology, which sounded wrong. Ever since I changed jobs in 2018 I’m much more involved in coding during my work-time again and that seems to suck my “mental code reservoir” dry, meaning I have very little motivation to spend much time on designing and adding features, limiting most of the work on Rygel, GUPnP and Shotwell to the bare minimum. And I don’t know how and when this might change.

A tale of three build systems

TL;DR

While we’re still 30s behind hand-written make, I totally would use any of the two over hand-written Makefiles.
As you might have noticed, meson is the new kid on the block. Step by step I am currently converting some projects to it, spearheading Shotwell. Since Shotwell only “recently” became an autotools project, you may ask why. Shotwell had a hand-written makefile system. This made some tasks that would have been incredibly easy with autotools, such as mallard documentation handling, more complicated than it should be. Since autotools provides all the nice features that you want for your GNOME environment, it made sense to leverage that.

Number games

Here are some numbers from the various transition phases. All taken on my i5 X201 laptop.
Conditions:

  • We build from a fresh git checkout (or git clean -dxf)
  • All builds are generated on the same machine with make -j $(($(nproc) + 2))
  • In the case of Meson, the ccache cache was emptied before

Shotwell 0.22

Configure:
real	0m0,011s
user	0m0,004s
sys	0m0,004s
Compile:
real	5m15,892s
user	17m30,392s
sys	1m10,984s

Shotwell 0.23.0

Shotwell’s makefile had a subtle rule issue that caused the plugins to be compiled several times over with valac. Also it was calling pkg-config with each compiler call, so after fixing that, we get these numbers for the compile step:

real	2m1,760s
user	6m31,788s
sys	0m26,788s

Shotwell master

Autotools

autogen.sh (including configure run):

real	0m32,315s
user	0m26,900s
sys	0m0,984s

Compiling:

real	2m25,164s
user	7m47,380s
sys	0m29,028s

Meson

mkdir build && meson build

real	0m1,529s
user	0m1,056s
sys	0m0,304s

ninja -C build

real	2m9,369s
user	7m17,276s
sys	0m33,660s

 

N9 media pushing

 

Ever since the announcement of the N9’s DLNA support people were looking for a feature called DLNA +PU+ which allows you to send media files to e.g. DLNA-capable TVs without enabling content sharing on your device, giving you a really fine-grained control about what and where to share to.
PushUp is a small utility that hooks into the N9’s sharing framework and allows to you push an image or a video to your TV just like you would with Bluetooth or NFC. Get it on this site (or later through the Nokia Store).

It is an offspring of my Korva project, a D-Bus specification and its implementation for media pushing. While still work-in-progress, it’s already fully functional.
Edit: I had to update the package because the icon was missing and cancelling the device selector was broken.
Edit2: Updated again since it was broken on PR < 1.2.

Modifying your GNOME keymap programmatically

For some reason I’ve a notebook with a Swedish keyboard but when docked I use my ergonomic keyboard with a German layout. To automatically switch the layout when the external keyboard is connected, I cooked up this script and added a .desktop file to $HOME/.config/autostart:

#!/usr/bin/env python
from gi.repository import Gtk, GLib, Gkbd
import usb
import sys
# Holtek Semiconductor, Inc. PS/2 keyboard + mouse controller
vendor=0x04d9
product=0x1400
c = Gkbd.Configuration.get();
try:
    # find index for german
    de = c.get_short_group_names().index('de')
    for bus in usb.busses():
        for dev in bus.devices:
            if dev.idVendor == vendor and dev.idProduct == product:
                c.lock_group (de)
                sys.exit(0)
except Exception, e:
    print e
    pass

This is using pyusb 0.4, it gets a bit easier with 1.0.

GStreamer 0.11 + JHbuild

If you try to test GStreamer 0.11 there’s this nice gst-uninstalled script; somehow that didn’t work for me as soon as I tried to use more non-gst interdependent libraries so I opted to use jhbuild. Luckily that’s quite easy with the stock gnome jhbuild moduleset.
To do that, I created a new .jhbuildrc-gst-0.11 with the following modifications. skip and modules can of course be adjusted to own needs.

moduleset = 'gnome-world-3.4'
modules = [ 'vala', 'libgee', 'gstreamer', 'gst-plugins-good', 'gst-plugins-bad', 'gst-plugins-ugly', 'gst-ffmpeg', 'gssdp', 'gupnp', 'gupnp-av' ]
skip = ['gtk+', 'atk', 'gcr', 'gtk+-2', 'rarian', 'NetworkManager', 'gnutls', 'polkit', 'p11-kit', 'gnutls', 'cantarell-fonts', 'gtk-engines', 'librsvg', 'gnome-themes-standard', 'libgnome-keyring', 'pango', 'expat', 'libgpg-error', 'libgcrypt', 'glib-networking']
os.environ['JHBUILDPS1'] = '[gst-0.11] '
branches = {
    'gstreamer' : '0.11',
    'gst-plugins-base' : '0.11',
    'gst-plugins-good' : '0.11',
    'gst-plugins-bad' : '0.11',
    'gst-plugins-ugly' : '0.11',
    'gst-ffmpeg' : '0.11'
}

Properties and Probabilities

I just tagged version 0.2 of my tracker browser tool

What’s new?

  • It has a location bar with backward and forward navigation buttons
  • It is also possible to use prefixed names instead of IRIs
  • You can use your keyboard to navigate backward and forward
  • It has a in-page search bar which can be reached by familiar keystrokes like “/” or “Ctrl-f”
  • If you browse a rdf:Property, you will now be shown all resources with the value the property has

Where to get it?

https://github.com/phako/tracker-zilla/tree/0.2

Mandatory screenshots

Tracker and me

While working with tracker I find myself rather often calling “tracker-info” on resources, looking for linked resources, running tracker-info on those, then needing to get back etc. A bit ugly and time-consuming.

Wouldn’t it be cool to just browse through all that info, being able to go back and forth through the links? Yes, it would. That’s why I wrote tracker-zilla:

You can navigate through the resources just like on the interwebs, using the back and forward feature of the context menu. It shows you not only the resources and properties of the object but also resources that link to the one you’re currently browsing:

It’s not that feature-rich and probably never will be. You can either pass a urn to it via command-line or nothing, then it will show you all rdfs:Classes available in the current ontology where you can just click on e.g. nco:PersonContact. What I’m planning to add is a simple in-page search and a breadcrumb navigation.
That said. it’s a pleasure to work with libtracker-sparql (especially from Vala). You need Vala 0.11.6, gtk+-3 and webkitgtk-3.0 to build it. ?The code is available at github.
Update: Due to popular demand, there’s now a –with-gtk=2 option to enable Gtk+-2 UI.

UPnP & C++

I’m currently trying to provide Qt4 bindings for the GUPnP stack. I’m a bit impeded by the issues that I already encountered with the “mm” C++ bindings and other people also experienced. Some classes are not that binding friendly. Additionally GUPnP is – as the name implies – closely tied to GObject and the GType system, imposing some more problems for the Qt 4 port.
I already got a test-browser like example running in Qt 4 running, stay tuned for more updates.

The QThread anti-pattern

Sometimes with QThread you see something like this:

void run()
{
    while (true) {
        {
            QMutexLocker lock(&mMutexData);
            if (mQuit)
                break;
        }
        msleep (200);
    }
    mWaitExit.wakeAll();
}
void stop()
{
    mMutexData.lock();
    mQuit = true;
    mMutexData.unlock();
    mWaitExit.wait(&mMutexExit);
}

This is potentially problematic. Why? Consider the extreme case of a function shutdown() which does something like this:

void shutdown()
{
    thread->stop();
    delete thread;
}

Congratulations, you’ve just introduced a race condition. Why, you will ask? You’re waiting for the thread to end before deleting it, right?
No. And this has to do with the way Qt implements QThread::wait() which you should have probably used in the first place, if you really need this sort of functionality.
Qt hooks a pthread cleanup handler in the native thread which will call wakeAll() on a QWaitCondition stored inside the pimpl of QThread. And this pimpl – you might have guessed – is gone when you call delete.