glom-postgresql-setup

Glom is an application that lets you design database systems, including user interface. It can be run as an ordinary application, and will set up and run a the database server for you automatically. But if you want to set up a shared instance, where several users connect with Glom to the same database, you typically want your database server on a dedicated server. And this can be a bit tricky to set up. So, glom-postgresql-setup was born; A dead-simple utility application to set up a PostgreSQL server for use with Glom. Like Glom, it is written in C++ using Gtkmm.

glom-postgresql-setup lets you to create a database user, and set up the PostgreSQL configuration to accept connections from external IPs. The UI is just a dialog with two fields and two buttons, dead-simple indeed. For now the application requires to be launched with superuser privileges, but before we encourage use of this tool we will of course implement proper privilege escalation using PolicyKit.
It would also be nice to be able to install and start the PostgreSQL server as well, but currently that is not so easy to do in a cross-distro way. Hopefully packagekit and systemd will help solve that, eventually.

Image preview support for OpenRaster in Qt working

While learning Qt here at Openismus I've written a basic, working plug-in for Qt that adds support for the OpenRaster file format*. Here is my Qt-based test application demoing this functionality by showing some awesome multi-layered abstract test art made by yours truly using Krita:

I asked for real art, but I did not get any

I asked for real art but as you can see, I did not get any.

The level of features supported is such that you will be able to preview OpenRaster documents created with applications like MyPaint, Drawpile, Nathive and GIMP, with the limitation that it will have a white background for transparent areas. The code can be found in qopenraster repository on gitorious (no tarballs), and the README file documents how to install as well as things that remain to be done.

The plug-in is basically a thin wrapper around libora, the OpenRaster reference library. libora takes care of parsing the OpenRaster document, reading out the layer data and rendering it into a single buffer. The rendering ability was added by me as part of this work, in addition to some other minor stuff. The Qt plug-in does RGBA to ARGB conversion and provides the QImageIOPlugin interface expected by Qt.

Doing this has also exposed several limitations and not-so-nice things in libora that should/needs to be improved. I've updated libora's README file to reflect this.

*Assuming the Qt application actually uses QImage in a straight-forward way. The KDE image viewer Gwenview does not seem to use QImage directly, so you will not automatically get support there by installing the plug-in :((. I fear that other KDE applications might be the same, though I was not able to test Digikam. If anyone has a suggestion for a Qt based image viewer that works sanely in this area, don't hesitate to leave a comment.

PS: I have an almost-working gdk-pixbuf module as well, will push that to gitorious soon.

Back from Qt Dev Days, first Qt projects

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.

Qt Developer Days 2010 and more

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

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*

*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.

MassifG 0.2

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.

Introducing MassifG 0.1

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.

Hello Openismus, Hello Berlin

Openismus

Looks like I will be joining Openismus in Berlin from July, as one of three trainees! There is much to learn, but that's gonna be half the fun. The other half will be working with something I really like, free and open source software, and with great people in a very good environment.

Going from living in my childhood home with my parents, studying at the local college, to my own place in a big city in a foreign country training/working as a software developer is going to be a big change. But I feel like a change, and I don't think it could have gotten much better than this.

But before that; Hello bachelors thesis completion and Hello exam preparations!