Back from Qt Dev Days, first Qt projects

Posted onLeave a comment

I’ve actually been back close to a week now, but never mind that…

In the per-conference day with training sessions I attended the Qt Essentials track, which was more or less as expected. Glad I read a full Qt book beforehand, it would have been challenging to keep up with the shear amount of information without it.
The keynotes I attended on the second day were not particularly exciting: no major announcements nor insights were given. The technical talks on the other hand were filled with goodies. The talks by Jens Bache-Wiig and Roberto Raggi on Qt Quick were especially good.*

The talks definitely made me want to try Qt Quick for doing user interfaces for small-form factor devices, especially because it allows for very rapid prototyping and iterations when developing. The current lack of widgets and traditional layouts probably limits its usefulness for typical desktop application with more complex user interfaces though. There is nothing that helps you achieve a native look and feel either, but the Qt Components project is aiming to bridge those gaps.
I also suspect that the declarative and dynamic nature of QML poses several new challenges for developers, especially for those that are mostly used to traditional Qt programming with C++. I’m especially concerned that there was no way to visualize or do static checking on the property-bindings that are so central in QML. Very curious as to how that plays out in practice.

*I’m told the talks will be online after the Qt Developer Days event in San Fransisco is over.

Qt projects you said?

Going forward I’ll be doing some projects with Qt, in the same way I have done with GTK. My first project has already started: implementing viewer-class OpenRaster support for Qt. This means that applications using Qt and QImage will soon be able to display fully-rendered OpenRaster images!
Development of the Qt integration happens in the repository on gitorious, and the libora modifications currently lives in my personal clone. It will be pushed to mainline as soon as I have more-or-less settled on the API, and done a basic implementation. Using libora for all the OpenRaster specific stuff is being a bit more painful than expected, but it is the right thing to do as it means that other consumers benefits as well. Like a potential GdkPixbuf plugin or applications not using Qt or GTK. I’ll write more once it reaches a useful state.

After that is done I will probably do something with more UI, like a proper application. Hopefully I will get to toss Qt Quick into the mix as well. I’ve got an idea that I think would be a nice fit, so we’ll see.

Proprietary platforms, free software and contributors

Posted on1 Comment

While I do not believe that killer applications exist, I do like to think that free and open source software applications adds value to the platform it supports, and its users. For small applications it might not be much, but still non-zero.
Personally, I do not particularly want to add value to proprietary platforms. I do not use them, nor want to “endorse” them. This is especially so if it means giving less to free platforms or software: I would rather spend my time on developing new features and fixing bugs in my favorite free software applications than to spend it on packaging and support for Windows, for example.

But at the same time I want to add value to free software as a whole and I recognize that getting the  software out to the user is fundamental. And that proprietary platforms like Microsoft Windows and Mac OS X have a ten to hundred times bigger user-base than free platforms like GNU/Linux. So time spent there would potentially be worth a lot, right? Yet I do not really want to do it, and I think that many existing free software contributors feel the same…

It is paradoxical that Windows and OSX represents the largest user-bases, often also for free and open source software, yet one of the smallest contributor-bases. How can this be fixed? How can we get more of the people that seemingly care about free and open source software on proprietary platforms to actually contribute?

Qt Developer Days 2010 and more

Posted onLeave a comment

Next week I’m going to Qt Developer Days in Munich where I will be attending Qt training and technical talks. And almost just as importantly, meet and talk to people who do related things to what we do at Openismus.  I suspect the overall style and feel of this conference will be quite different from past free and open source software events I’ve been to (like GUADEC and Libre Graphics Meeting). More business-y, perhaps even enterprise-y? None the less,  looking forward to it.

In related news, I’m also involved as part of the local team for Desktop Summit 2011, along with several of my co-workers. The initial announcements have just been made public; the conference will be held in Berlin August 6th-12th, at Humboldt University. Mark your calendars 😉 See for instance the story by the GNOME Foundation, the official website or the original announcement for more information.

Hopefully I will also be going to the Meego conference in Dublin in November. Fingers crossed!

MassifG 0.2.2

Posted on2 Comments

Another day, another release. This release fixes:

  • Missing axis labels – now it is explicit what each axis represents
  • Inconsistencies with GNOME HIG: Button ordering in save/open dialog and missing ellipsis for menu actions which require further user input
  • A error message on canceling in the save dialog which should not have been there

Ubuntu 10.04 packages are now in the Openismus PPA. Due to scheduled downtime for Launchpad it might take an hour or two before they are built. The tarball is here, Fedora 13 packages here (i686, x86_64). Arch packages are still in AUR, and Gentoo packages in Dave’s overlay.

I’ve updated the README to include information about the roadmap and tasks to be done. Check it out if you’re interested in improving this small tool.
Hopefully there will be a massifg product in GNOME bugzilla soon (I’ve made a request), but in the meantime just report problems to me by email.

Here is yet another screenshot:
2010-09-09-122757_1680x1050_scrot

MassifG 0.2.1; now packaged for your favorite distro*

Posted onLeave a comment

*if your favorite distro is Fedora, Ubuntu, Arch or Gentoo.

This is a bugfixes-only release, and fixes regressions in print/save functionality (which rendered 0.2 kinda useless, thus the quick point release) and a parsing bug on 32-bit platforms. Behavior of the open/save dialog has also been improved. Tarball is here.

Packages:

I’ve pushed the package files for Fedora and Ubuntu to a branch in case anyone wants them. The packages should require little to no adaption to work on earlier distro versions than the tested ones. The Ubuntu package should also work fine on Debian. With time I might work to get the packages into the official repositories, but that is not a priority at the moment.

Berlin concerts awesomeness

Posted on2 Comments

A few weeks back I saw Gojira (warning: horrible flash based site, even the myspace page is better) at Knaack here in Berlin. While I hadn’t listened to Gojira much before going, it was a great show. Nice venue, sound was good, kick-ass music and performance, and the crowd loved it. What more can you ask for?
The event was promoted by a company called Trinity Concerts, and apparently they do a whole bunch of good stuff this autumn. Here are the ones I plan to go to between now and Christmas:

  • 22.09.2010 – This Will Destroy You
  • 02.10.2010 – Anathema
  • 06.10.2010 – Porcupine Tree + Oceansize
  • 05.11.2010 – Alter Bridge
  • 02.12.2010 – Irepress & Constants
  • 08.12.2010 – Caspian

I might squeeze in Dark Tranquillity or Tarot or Apocalyptica on the 24th of October, and Ludovico Einaudi on the 16th of November too. Maybe even Sabaton, depending on how good their new album is. I was also hoping to be able to see Epica while they are on tour, but they are not playing in Berlin (!), and the Oslo date does not fit with when I want to go back to Norway. I guess Poznan is only 3 hours away…
In any case, I think I know one or two people that are mighty jealous of me right now. And they ought to be.

MassifG 0.2

Posted on1 Comment

MassifG is an application for visualizing the output of valgrinds massif tool. See the first release announcement for more info. Here is the high level list of changes since version 0.1:

  • Graphing component ported to use GOffice – graphs are much nicer now
  • A detailed view has been implemented
  • Parses the heap trees found in massif snapshots
  • Menu entry for directly exporting graph to a PNG file
  • gtk-doc based API documentation

Of course there were also many minor changes, fixes and improvements. Here is how it looks now (simple and detailed view, respectively):

massifg-0.2-simplemassifg-0.2-detailed

The tarball can be found here. Packages for Arch are in AUR. I’m also hoping to make packages for Ubuntu and Fedora in the next couple of days.

Roadmap

I will probably move my focus over to C++ and other tasks now, so MassifG progress will be slower, but here is what I’d like to see going forward.

  • Show name of the function when hovering over the graph.
    Minor thing, but it will increase usability a lot as it can be very hard to see which legend entry the data corresponds to in the detailed view. Requires support in GOffice
  • Add axis labels and title with information from the massif file.
  • Improve usability on small screen/window size.
  • The detailed view currently needs a lot of space, and does not work nicely when this is not available. Need to ask the GOffice people for some hints and tips here.
  • Make an API and UI for running massif.
    This so that users don’t have to invoke massif manually, and then open the file in MassifG to visualize the results. Would additionally be nice if the graph was updated interactively while massif runs, but that is secondary.
  • Make a UI widget for visualizing the heap tree.
    Possibly a GtkTreeView. I’m open for suggestions here.
  • Expose a public library with the relevant parts of the API.
    This way, others applications can use it – if anyone is interested I’d love to have some feedback on the API. I am of course open to changing it if necessary. Support for GObject introspection would be nice too.

If anyone would like to work on any of this, give me a hint so we don’t duplicate effort. Let me know if you have any other good ideas too.

Determining physical topology of hotplugged USB devices with udev

Posted on1 Comment

As part of a bigger project of mine, I wanted to answer the following questions: How can one tell which physical port a hotplugged usb-device is plugged into on Linux? Can one do this when the device is plugged into an usb-hub (i.e: non-root hub) too? Since this is potentially useful to others out there, I share my findings here.

The usual “lsusb” or “lsusb -v” gives no indication that the kernel knows about the physical topology of the devices connected to an USB bus. However “lsusb -t” does indeed show the topology, so the kernel does know about it and make this info available to user-space. So, how to use this in udev? Prodding some USB storage class devices with udevinfo, shows that there is no attribute that gives this information directly. But, the DEVPATH attribute for USB devices actually contains this information.

For instance, an USB mass storage device connected to port 2 of the root-hub with bus number 2 has the following devpath: “/devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2:1.0/host12/target12:0:0/12:0:0:0/block/sdb” and a USB mass storage device connected to port 5 of the root-hub with bus number 1 has the devpath “/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0/host5/target5:0:0/5:0:0:0/block/sdb”. It becomes a bit confusing when there are USB hubs involved: “/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1:1.0/host16/target16:0:0/16:0:0:0/block/sdb” refers to a device plugged into port 1 of an USB hub plugged into port 1 of a second hub which is plugged into port 1 of the root-hub with bus number 2.

We see that in all cases the information about the physical topology is in the substring just before “:1.0”; “2-2”, “1-5” and “2-1.1.1”, respectively for the given examples. And that the format is “$busnumber-$port” for the simple case of connecting the device directly to the root-hub, and $busnumber-$port1.$port2  ->   .$portN for the general case, with N-1 usb-hubs between the device and the root-hub.

Just to show that this works, here is a quick and dirty udev rule and helper python script which parses the devpath and creates a symlink to the first partition of a USB mass storage device under /dev/usb based on the bus and port the device is connected to. Results might look like this:

tree /dev/usb/                                                                    Thu Jul 29 17:34:38 2010

/dev/usb/
`-- 2
    `-- 2
        |-- 2 -> ../../../sdc1
        `-- 4
            `-- 4 -> ../../../../sdb1

A more useful thing to do might for instance be passing through all devices connected to a certain physical usb-port to a certain virtual machine. Or maybe letting an embedded system responding differently to USB devices plugged into a physically secured root-hub than to one that is available to the user.

Introducing MassifG 0.1

Posted on4 Comments

MassifG is an application for visualizing the output of valgrinds massif tool. I am writing it as part of my trainee program here at Openismus. MassifG is free software, available under GPLv3. You will find the git repository at gitorious, and the tarball release for 0.1 here. Packages for Arch are available in AUR.

Used together with massif MassifG gives you a nice, simple graph of allocated heap memory over time which you can use to help evaluate if your program is leaking memory or not:

Current status

With release 0.1 MassifG can:MassifG 0.1

  • Parse and display a simple graph from massif output.
  • Open files selected on the command line or from the UI.
  • Print out the graph to a printer or file. This code was contributed by Murray Cumming – thanks!

I was hoping that I could make version 0.1 the “minimally useful” release, but I have to admit that it is not quite there yet. Instead I nickname release 0.1 “getting it out there”. The main issue is that there is massif output that breaks the graph, see under tests/ for an example.

Implementation

MassifG is written in C, and uses GTK+ for its graphical user interface. Once the ability to export the graph is implemented, it should be easy to allow the application to build and run without GTK, if anyone wants to do that.

The parser is a simple state-machine. It might have been wiser to use bison+flex, and I’ll reevaluate that when I need to implement parsing of the detailed output.

The graph functionality is implemented using Cairo and Pango. While Cairo and Pango are excellent technologies with nice APIs, they are quite low-level and that means having to care about all the details. As that brings no benefit to this application I might rewrite the graphing functionality to use the goffice library instead. Sadly there seems to be little high-level or introductionary documentation to goffice APIs, so I might have to fix that along the way.

Roadmap

In the short term I will:

  • Implement parsing and graphing of the detailed massif output
  • Fix the graphing bug(s)
  • Add the ability to export/save a graph as PNG,PDF et.c. without having to go by the printing dialog

In the longer term I’m considering:

  • Adding the ability to run massif on a program directly from MassifG
  • An interactive mode which updates the graph while the program to be analyzed is still running
  • Making a custom widget which other applications can embed

In the meantime, please do give the current version some testing, and report bugs and other issues.