Recent blog entries for zeenix

Lessons on being a good maintainer

What makes for a good maintainer? Although I do not know of a definite answer to this important but vague and controversial  question, maintaining various free software projects over the last many years, I've been learning some lessons on how to strive to be a good maintainer; some self-taught through experience, some from my colleagues (especially our awesome GNOME designers) and some from my GSoC students.

I wanted to share these lessons with everyone so I arranged a small BoF at GUADEC and thought it would be nice to share it on planet GNOME as well. Some points only apply to UIs here, some only to libraries (or D-Bus service or anything with a public API really) and some to any kind of project. Here goes:

Only accept use cases

There are no valid feature requests without a proper use case behind them. What's a proper use case you ask? In my opinion, it's based on what the user needs, rather than what they desire or think they need. "I want a button X that does Y" is not a use case, let alone a proper one. "I need to accomplish X" is potentially one.

Even when given a proper use case, does not necessarily mean that you should implement it. You still need to consider the following points before deciding to accept the feature request:
  • How many users do you think this impacts?
  • What's the impact of having this feature to user?
  • What's the impact on users that do not need that feature?
  • How does the expected number of users who need this feature compare to ones that do not.
  • How much work do you think this will be and do you think you (or anyone else in the team) will have the time and motivation to implement it?

    Get a thicker skin

    Everyone wants software to be tailored for them so unless you have only a few users of your software, you can not possibly satisfy all users. Sometimes users even demand contradictory features so if you are going to be a slave of user demands, you'll not last very long and your software will soon look like my bedroom: random stuff in random places and hard to find what you are looking for.

    So don't be afraid of WONTFIX bug resolution. I do agree that this sounds harsh but I think the most important thing is to be honest with your users and not to give them false hopes.

    A good API maintainer is a slave of apps

    Your library or D-Bus service is as useful and important as the applications that use it. Never forget that while making decisions about public APIs.

    Furthermore, if possible, try your best to be involved in at least one of the applications that use your API. Even better if you'd be maintaining one such application. There has been a few occasions where I had to had long debates with library developers about how their API could do much better and I felt that the debate could have been avoided if they had more insights about the applications that use their API. Also, they'd likely care more if they'd experience the pain of the problematic part of their API first hand.

    History is important!

    VCS (which translates to git for most of us these days) history, that is. I think this is something most developers would readily agree on and some readers must be thinking why do I need to even mention this. However, I've seen that while many would agree in principle to this, in practice they don't care too much. I've seen so many projects out there, where it's very hard or even impossible to find out why a particular line of code was changed in a particular way. Not only it makes maintenance hard, but also discourages new contributors since they'd not feel confident about changing an LOC if they can't be sure why it's how it is and not already what they think it should be like.

    So kids, please try to follow some sane commit log rules. We have some here and Lasse has created an extensive version of that document with rationale for each point, for his project here.

    Quality of code

    This is a bit related to the previous point.  To be very honest, if you don't care about quality enough, you really should not be even working on software that effects others, let alone maintaining them.

    How successful you are at maintaining high quality is another thing, and sometimes even not in your hands entirely, but you should always strive for highest quality. The two most important sub-goals in that direction in my opinion, are:


    [Insert cliché Einstein quote about simple solutions here.] Each time you come up with a solution (or receive one in the form of patches), ask yourself how it can be done with fewer lines of code. The fewer lines of code you have, the fewer lines of code you'd need to maintain.


    Come up with a (or adopt an existing) coding style with specific set of rules to follow and try your very best to follow them. Many contributors would simply dive directly into your project's source code and not read any coding style manual you provide and there is nothing wrong with that. If you are consistent in your code, they'll figure out at least most of your coding style while hacking on your sources.  Also chances are that your coding style would even grow on them and that'll save you a lot of time during your reviews of their patches. That's unlikely to happen if you are not very consistent with your coding style.


    None, what so ever. Do what you think is right. This blog post is nothing more than my personal opinions so take it or leave it, it's all up to you!

    Syndicated 2015-10-19 11:00:00 (Updated 2015-10-19 11:00:04) from zeenix

    14 Oct 2015 (updated 15 Oct 2015 at 19:29 UTC) »

    Geoclue convenience library just got even simpler

    After writing the blog post about the new Geoclue convenience library, I felt that while the helper API was really simple for single-shot usage, it still wasn't as simple as it should be for most applications, that would need to monitor location updates. They'll still need to make async calls (they could do it synchronously too but that is hardly ever a good idea) to create proxy for location objects on location updates.

    So yesterday, I came up with even simpler API that should make interacting with Geoclue as simple as possible. I'll demonstrate through some gjs code that simply awaits for location updates forever and prints the location on console each time there is a location update:

    const Geoclue =;
    const MainLoop = imports.mainloop;

    let onLocationUpdated = function(simple) {
    let location = simple.get_location ();

    print("Location: " +
    location.latitude + "," +

    let onSimpleReady = function(object, result) {
    let simple = Geoclue.Simple.new_finish (result);
    simple.connect("notify::location", onLocationUpdated);

    onLocationUpdated (simple);
    }; ("geoclue-where-am-i", /* Let's cheat */

    Yup, that easy! If I had chosen to use the synchronous API, it would be even simpler. I have already provided a patch for Maps to take advantage of this and I'm planning to provide patches for other apps too.

    Syndicated 2015-10-14 17:30:00 (Updated 2015-10-15 16:45:46) from zeenix

    New in Geoclue: Location sharing & convenience library

    Apart from many fixes, Geoclue recently gained some new features as well.

    Sharing location from phones

    If you read planet GNOME, you must have seen my GSoC student, Ankit already posting about this. Basically his work enabled Geoclue to search for, and make use of any NMEA providers on the local network. The second part of this project, involved implementation of such a service for Android devices. I'm pleased that he managed to get the project working in time and even went the extra mile to fix issues with his code, after GSoC.

    This is useful since GPS-based location from android is almost always going to be more accurate than WiFi-based one (assuming neighbouring WiFi networks are covered by Mozilla Location Service). This is especially useful for desktop machines since they typically do not have even WiFi hardware on them and have until now been limited to GeoIP, which at best gives city-level accurate location.

    This feature was included in release 2.3.0 and you can download the Android app from here.

     Conveniece library

    Almost since the beginning of Geoclue2 project, many people complained that using the new API is far from easy and simple, as it should be. While we have good reasons to keep D-Bus API as it is now, the fact that a lot of time passed since I got around to doing anything about this, meant that it was best if D-Bus API was not changed, Geoclue being a system service.

    So this week, I took up the task of implementing a client-side library, that not only exposes gdbus-codegen generated API to communicate with the service but also added a convenience helper API to make things very simple. Basically, you just have to call a few functions now if you simply want to get a location fix quickly and don't care much about accuracy nor interested in subsequent location updates.

    I only pushed the changes today to git master so if you have any input, now would be the best time to speak up. I wouldn't want to change API after release.

    Syndicated 2015-10-09 19:45:00 (Updated 2015-10-09 19:45:19) from zeenix

    Life update

    Like many others on planet.gnome, it seems I also don't feel like posting much on my blog any more since I post almost all major events of my life on social media (or SOME, as its for some reason now known as in Finland). To be honest, the thought usually doesn't even occur to me anymore. :( Well, anyway! Here is a brief of what's been up for the last many months:
    • Got divorced. Yeah, not nice at all but life goes on! At least I got to keep my lovely cat.

    • Its been almost an year (14 days less) that I moved to London. In a way it was good that I was in a new city at the time of divorce as its an opportunity to start a new life. I made some cool new friends, mostly the GNOME gang in here.

      London has its quirks but over all I'm pretty happy to be living here. One big issue is that most of my friends are in Finland so I miss them very much. Hopefully, in time I'll also make a lot more friends in London and also my friends from Finland will visit me too.

      The best thing about London is the weather! No, I'm not joking at all. Not only its a big improvement when compared to Helsinki, the rumours about "Its always raining in London" are greatly (I can't stress on this word enough) exaggerated.
    • I got my eyes Z-LASIK'ed so no more glasses!

    • Started taking:

      • Driving lessons. Failed the first driving test today. Having known what I did wrong, I'm sure I wont repeat the same mistakes again next time and will pass.
      • Helicopter flying lessons. Yes! I'm not joking. I grew up watching Airwolf and ever since then I've been fascinated by helicopters and wanted to fly them but never got around to doing it. Its very expensive, as you'd imagine so I'm only taking two lessons a month. With this pace, I should be have my PPL(H) by end of 2015.

        Turns out that I'm very good at one thing that most people find very challenging to master: Hovering. The rest isn't hard either in practice. Theory is the biggest challenge for me. Here is the video recording of the 15 mins trial lesson I started with.

    Syndicated 2014-10-10 17:53:00 (Updated 2014-10-10 18:09:31) from zeenix


    So its that time of the year! GUADEC is always loads of fun and meeting all those the awesome GNOME contributors in person and listening to their exciting stories and ideas gives me a renewed sense of motivation.

    I have two regular talks this year:
    • Boxes: All packed & ready to go?
    • Geo-aware OS: Are we there yet?
    Apart from that I also intend to present a lightning talk titled "Examples to follow". This talk will present stories of few of our awesome GNOME contributors and what we all can learn from them.

    Syndicated 2014-07-21 23:12:00 (Updated 2014-07-21 23:12:07) from zeenix

    oFono? Its dead jim!

    Soon after I mentioned the need for an oFono-backend in Geoclue in my blog, Sri kindly helped me get in touch with oFono developers. What started as a nice friendly discussion soon was turned into a not so nice discussion. I won't get into details and blames but here is what I found out about the project:

    •  oFono developers claim that its is still a maintained project while rest of the world think its a dead project, even people who love the project. Last release being in 2012 and loads of missing essential features (see rest of the points below) and link to mailing-list broken (even though I pointed it out 3 weeks ago and its been broken for much longer) on the homepage all points to the fact that its essentially a dead project.

    • No proper D-Bus introspection nor any client libraries. This already makes it extremely difficult to work with oFono but wait there is more hurdles on the way.

    • No online cross-references documentation: The documentation link on the home-page leads you to an architecture diagram and gives you no information about the API. Searching through google doesn't yield any results either. The developers pointed out that all documentation lives in the source tree in the form of plain-text documents and hence not very appropriate for the web.

    • It does not implement the standard D-Bus Properties interface. This combined with the fact that their D-Bus API is heavily based on properties makes it yet even harder to work with OFono, not to mention very weird.

    • None of the modern 3G modems supported, at least out of the box. I tried both Option and Qualcomm Gobi that I have and they both didn't work.

    While rest of the issues can be overcome, the last makes it impossible for me to test any code written against oFono. So I'm giving up on this.

    With a nice alternative that is well-maintained, and with which most modems work out of the box, has a nice OO, well-documented and introspectable D-Bus API and also provides  a nice client library, I don't understand why phone vendors insist on supporting oFono interface. Could it be because the name makes it sound like its *the* solution for phones? Well, they do have the right to use whatever they like. I'm just curious.

    Having said all that, I did make it easy for anyone to add oFono support to Geoclue as promised in my last blog post. Patches to add that are more than welcome!

    Syndicated 2014-06-24 00:28:00 (Updated 2014-06-24 00:28:43) from zeenix

    Location hackfest 2014 report

    So the Location hackfest 2014 took place at the awesome Mozilla offices in London during last weekend. Even though some of the important participants didn't manage to be physically present, enough people did:
    • John Layt (KDE)
    • Hanno Schlichting (Mozilla)
    • Mattias Bengtsson (GNOME)
    • Jonas Danielsson (GNOME)
    and some participated remotely:
    • Bastien Nocera (GNOME)
    • Garvan Keeley (Mozilla)
    Unfortunately Aaron McCarthy of Jolla couldn't attend remotely either as he lives in a very incompatible timezone (AU) but we had a lot of productive discussion with him through email that still continues.

    Some very fruitful discussions we had:

    • Why Mozilla doesn't make wifi data it gathers for its location service, available for everyone to download? Hanno explained in great detail how making this data available would seriously compromise privacy and even safety of people. One good example given was someone getting out of an abusive relationship and not wanting to be traceable by their ex- but if they take their wifi router with them, their significant other has a possible way to easily track them using the wifi database. There is an easy (even though very ugly) way to avoid your AP being scanned by harvesters of such services but most people do not possess enough technical knowledge to know to enable that.

      Hence their reluctance to making it available for download, even though they'd want to. If you are interested in more details, you should read up all about that on Hanno's blog.
    • Had some discussion with Firefox and Firefox OS using Geoclue2. Hopefully we'll at least have Firefox using Geoclue2 soon. I might need to add support for totally unmaintained ofono in Geoclue2 unfortunately for making a very compelling case for Firefox OS to adapt geoclue2.
    • We had a discussion about GPS-A support in Geoclue. There are two possible ways to do that:
      1. Give URL of a SUPL service to the modem and let it do everything for you.
      2. Get the geospacial data that (SUPL service would provide) from a custom service and feed that to the modem.
      Hanno informed us that the only free SUPL implementation out there is that from Google but nobody knows what the ToS really are. He also informed us of how many modem chipsets just don't implement the API to feed it geospatial data and that makes SUPL our only hope to implement GPS-A.
    • There was a discussion about POI and check-in UI in Maps between me and Mattias. We had a bit of disagreement about it but seems now we are coming to come conclusions about how it should look like.
    It was a hackfest so we also did some hacking:

    • John spent most of his time getting familiar with Qt's location code and how to port to Geoclue2. He wrote a nice post about it so I wont get into details here.
    • Mattias worked tirelessly to finish off his routing branch to be finally merged. Its not a very easy task so its not surprising that he hasn't managed to finish it yet. I'm pretty hopeful it will be merged in the following few weeks.
    • Hanno added proper support for geoip-only queries in Mozilla location service, made it do better against queries w/ stale wifi data and improved accuracy of results from 300m to 100m among other things.
    • Jonas was doing live reviews of Mattias' patches (in Swedish!) and at the same time working on getting command-line options parsing to work in gjs so we can do so in Maps.
    • Garvan was working on adding Geoclue2 support to Firefox/Gecko.
    • I finished off my patches to port geoclue2 to directly use wpa_supplicant rather than NetworManager, which makes wifi-geolocation work on FreeBSD, Firefox OS and Jolla. The last two don't use Geoclue2 but I'm hoping that this is a step forward towards convincing them to use it. I provided a patch to wpa_supplicant to make its D-Bus policy a bit lenient, while at it.

      I also looked into ofono API but not only is the project unmaintained, it doesn't provide proper introspection on D-Bus and there is no API docs. :( To make things worse, both my modems don't seem to work at least out of the box. I'd really rather I didn't have to deal with it but if I can't convince Firefox OS folks to provide ModemManager API, adding ofono support is essential to get them to use Geoclue.

      I started refactoring of Modem sources in Geoclue so that:
      • all ModemManager code is isolated in its own module so that its easy to add a ofono handling code w/o changing anything in the sources themselves.
      • 3G source can more easily/cleanly share code with Wifi source, use Mozilla Location Service (rather than opencellid that it currently does) and also submit cell tower data to Mozilla.
    I can't thank Mozilla and specifically Chris Lord enough for hosting this event for hosting this event.

      Syndicated 2014-05-28 11:57:00 (Updated 2014-05-28 11:58:39) from zeenix

      Berlin, DX hackfest, Boxes, rain & sunshine

      I just flew back from Berlin where I spent the last week, mainly to participate in the GNOME Developer Experience hackfest. As you can see from blog posts from other awesome gnomies, the hackfest was a pretty big success.

      I focused on the use of virtual machines (as thats right up my alley) for making application development as easy as possible. I talked to Christian, who has been working on an IDE for GNOME about his idea of a simulator VM which allows the developer to quickly test their app in a pristine environment. We discussed if and how Boxes can be involved. After some discussion we decided that we probably don't want to use Boxes but rather create another binary that re-uses the existing virtualization infrastructure: libvirt, qemu, spice (and maybe libosinfo) etc.

      Another way to make GNOME development easy through VM would be what we already have on a very crude level: Distribution of ready-made VMs with all the development environment setup. Continuous already creates and distributes ready VM disk images of latest GNOME (almost everything from git) and Boxes can import these images. These images however are insufficient and unreliable since they do not contain any metadata, especially recommended/required system resources, about the VM. Christian recommended VMware's wmx format but that turned out to only contain metadata instead and you'd need a separate file (vmdk) for the disk image with that. What we really need here is a format that contains both metadata and all disk images in one file, in other words a virtual appliance. After doing some research on this, I once again came to the conclusion that OVF is our only hope here. Not only its one file that can contain all important aspects of a VM, its an open standard that is agreed and implemented by many different vendors. Boxes being able to import/export from/to this format and Continuous being able to provide these virtual appliances wouldn't just enable a more reliable producer-consumer relationship between Continuous and Boxes but also allow individual developers to be easily able to share their work with others: "Hey! I've been working on this project/feature X last few days and want to get some input. I'm sending you the VM, just import it in Boxes and let me know what you think..".

      We've actually been wanting to have this feature for a very long time and I've mentioned the need for OVF support quite a few times so I decided its about time I do something about it. So during the hackfest, I designed the minimum interface for a library to convert from/to libvirt domain (or configuration) to/from OVF files and started the implementation too. I hope to continue working on it to have something demoable by end of this month.

      Some other discussions/activities I had during/around the hackfest:

      * Talked with Aleksander about modem enabling/disabling. Currently geoclue has to enable the modem itself for using it but since it doesn't know if the modem is in use by another application, it doesn't disable it after using it. This results in waste of battery power. I suggested to Aleksander that the best thing would be for ModemManager to take care of that as it knows if modem is in use or not. The alternative would be some kind of explicit UI but throwing this decision on user would be a terrible thing to do. Aleksander liked the idea and he promised to look into implementing it.

      * I took part in Gtk+ roadmap discussion, mostly as a silent observer (Gtk+ hackers and designers covered it nicely so I didn't feel like saying anything) but during the meeting I learnt of a widget that was introduced in 3.12 that I had missed completely, GtkFlowBox. Since developers were unhappy that we introduced a widget that is not used by any GNOME app and I realized that use of this widget in Boxes will bring me very close to my aim of dropping libgd usage, I decided to make Boxes the first user of this widget soon.

      * I realized (very late) that both my SoC studends live in Germany so I asked both of them if they can join us for any of the days. While it was impossible for baedert to join us on such short notice, Lasse was still able to make it for the last day. It was really nice to meet this very bright young fellow. We had a lot of discussion about past, present and future of Boxes. Lasse has already written a very nice and detailed blog post about that so I'll leave you with a link to that if you are interested.

      * Talked with Cosimo about use of Geoclue by Endless mobile.

      * Tested gnome-clang against Geoclue to provide feedback to Philip and it resulted in him fixing some important bugs.

      * Talked briefly to Lennart about
        * How authorization of geoclue-using apps will/can work in the kdbus world.
        * The best way to allow Boxes to access USB devices with ISO9660 filesystems on them.

      Thats mostly it! I would like to thank Lennart for providing me with a nice accommodation, Endocode for providing us a great venue (+ endless supply of Club mate) and GNOME foundation for sponsoring my travel.

      Syndicated 2014-05-05 23:41:00 (Updated 2014-05-05 23:42:32) from zeenix

      What's coming in Maps 3.14 and beyond

      Jonas has written a very nice blog post about present and future of Maps project. I definitely recommending reading it if you are interested in this project. Since he is not on planet.gnome yet (some policy about having some posts before applying to be added), I thought I share it here.

      Syndicated 2014-04-22 11:30:00 (Updated 2014-04-22 11:30:31) from zeenix

      13 Apr 2014 (updated 13 Apr 2014 at 19:08 UTC) »

      Location hackfest

      I'm organising a hackfest in London from May 23 to 25 2014. The plan is to improve our location-related components and to get them useful to other OSs: KDE, Jolla and hopefully also Ubuntu phone. If you are (or want to) doing anything related to location and want to attend, please do add yourself to wikipage as soon as possible so I can notify our hosts if we'd need a bigger room.

      Oh and if you need a place to stay, do contact me!

      I'm thankful to awesome Mozilla folks for hosting this event and providing an awesome open geolocation service to everyone.

      New Advogato Features

      New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

      Keep up with the latest Advogato features by reading the Advogato status blog.

      If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!