Tag Archives: Openismus

Glom: Choice drop-downs can show related fields

General, ,

I have spent the past month or so implementing a new Glom feature. It took much longer than expected, involving several large code refactors, and this feature was itself shown to be necessary by previously implementing another difficult feature. But I kept going because the feature seems genuinely and generically useful, if only to a few people. And I knew I was improving that code, reducing code duplication and simplifying it by making code generic and separate.

Anyway, the feature: Glom can show a drop-down (combo box) of choices when the user should enter a field value. This can be a hard-coded list, like “Mr, Mrs, Ms”, or it can be a list of values from a related record. For instance, it can be a list of person names from a contacts field, so you can choose a contact ID. Previously it could only show a value from the immediately-related table.

But you can now do more, because choices now uses the same item layout system as the regular list layout. So, for instance, if you are choosing an Actor’s Agent’s ID, as in this screenshot, you show not only the Agent’s name (as before) -  You can also show the Agent’s company name (Actors->Agents->Companies), from the doubly-related table. And you can even show the Company’s CEO’s name (Actors->Agents->Companies->CEO) from the triply-related table, if you need that for some non-contrived example. (In this example, I’m ignoring the fact that Actors and Agents and CEOs are in the same Contacts table, though reached via different relationships.)

This is without the Glom user writing any SQL, or having to understand the ugly SQL that’s necessary to do all that. I think that’s nice.

Also, because this uses the regular Glom layout system, you can now specify additional item formatting, such as different font styles (bold in this example), colors, or numeric formatting (such as numbers of decimal points or currencies). You’ll probably be happy with the default formatting that you’ve chosen for those fields though.

While implementing this feature, I also found that GtkComboBox needs:

  • To allow the menu to be wider than the GtkCombobox. For the screenshot, I’m using Tristan’s patch for that.
  • To allow “columns” to be aligned vertically. This isn’t really possible in GtkComboBox now because you can only add GtkCellRenderers to a single column instead of having multiple GtkTreeViewColumns as in a GtkTreeView. Tristan might make that possible, though it requires some other work first.

gtkmm 2.91.0

General, ,

On Sunday I released gtkmm 2.91.0, following the recent GTK+ 2.91.0 release. This follows the removal of GtkObject, GdkPixmap, and GdkBitmap from GTK+. You’ll need to make some small, slightly-annoying, but generally good changes. For instance, the change from on_expose_event to on_draw() is awkward but obviously a far nicer way to do custom widget drawing, as if someone had actually thought about that API. Thanks Benjamin Otte.

Surprisingly, gtkmm applications, such as Glom, seem to work OK after porting.

Note that, despite the .0 version number, these aren’t the first unstable GTK+ and gtkmm 3 releases. The previous ones were called 2.90.x, but that looked too much like a stable release.

gtkmm 2.22

General,

Yesterday I released gtkmm 2.22.0, the first API/ABI-stable version of gtkmm 2.22, wrapping GTK+ 2.22. It adds some new API and deprecates some old API. There’s nothing particularly useful, but this will help people prepare for gtkmm 3. As ever, gtkmm coders don’t need to wait for us to update gtkmm when there is new GTK+ API.

Nevertheless, maintaining two active gtkmm branches has been a huge and thankless drain on my time for the last few months. It’s still really hard to keep gtkmm 3 in sync with GTK+ 3, but I’m glad that I don’t need to keep my head divided between two versions of the API. More about gtkmm 3 later.

cluttermm releases and cluttermm_tutorial fixes

General,

I have neglected cluttermm recently (a C++ API for Clutter). But Chris Kühl has recently fixed several cluttermm problems shown by example code in the cluttermm version of our tutorial and updated the tutorial itself. I’ve also added new API to wrap the new ClutterAction, ClutterActorMeta and ClutterEffects stuff in clutter 1.3/1.4. I’ve done new tarball releases to get the fixes out into the world. So I think it’s looking fairly healthy again, though I hesitate to call it stable before more people are using it.

The cluttermm API documentation is another good starting point.

Massifg Prints Valgrind Massif Graphs

General,

Jon Nordby’s massifg is now usable and packaged for Ubuntu (in the Openismus PPA) and Fedora. The only slightly awkward dependency is libgoffice (for graph drawing), but that is widely packaged on distros.

It shows both the simple and detailed graphs of valgrind’s massif output, much like the old-style ms_print script. It can print the memory usage graph (also to PDF) and save it as a PNG file, so you can talk to other people about the results.

It’s far better than my previous attempts to modify the original ms_print perl script. There is still a bug (maybe needing a fix in libgoffice) that makes the detailed graph very narrow when showing the legend on small screens, but we are working on that.

Trainee Mini Projects

General, ,

We asked our 3 trainees to do some little projects to make sure that we ironed out any problems in their C knowledge before moving on to C++, to get them familiar with autotools, and generally to have code to talk to each other about.  I forced them to make actual tarball releases, so they can also complete features as if there were real users, instead of just hacking without focus. These are the modest results. Click on the links to see the descriptions and screenshots on their blogs.

Jon Nordby’s massifg: To show graphs from valgrind massif output. So far it only shows the simple graphs, though using the Cairo drawing API makes printing to PDF easy, so it’s already useful. I want Jon to do the detailed graphs too, but I’ve asked him to look for a proper Graph API first, because it’s tedious to do it all with just Cairo. Hopefully without acquiring awkward dependencies. He’d welcome advice.

Chris Kühl’s GMemory: One of those games that lets you turn over tiles for a moment and try to find matching tiles. It uses clutter and could probably be a candidate for the gnome-games package soon.

Patricia Santana Cruz’s GHangTux: A hangman word-guess game in which Tux the penguin loses his accessories rather than his life.

(The Gs in the names were their idea.)

I think they have all learned lots from the exercise and are ready for the next stage.

Openismus at GUADEC 2010

General

Tomorrow (Tuesday) I fly to Amsterdam and take the train to Den Haag for GUADEC 2010, joining 9 other Openismus employees: Karsten Bräckelman, Jens Georg, Ekaterina Gerasimova, Michael Hasselmann, David King, Andre Klapper, Chris Kühl, Jon Nordby and Patricia Santana Cruz. For Chris, Jon and Patricia, it’s their first GUADEC, so they are eager to soak up knowledge and will particularly enjoy meeting everyone.

This time Openismus is even sponsoring GUADEC to show our support, though at the lowest level because it’s already expensive enough to send 10 employees.

The T-Shirts are attractive and different again. Photos soon.

Qt’s Open Bug Tracker

General, ,

Qt has had an open bug-tracker for a few months now. I am very happy about that. It has made life far more pleasant for Qt developers compared to the past. However, there are some problems. In summary, bug reporters are often treated like the enemy instead of contributors, and this could be fixed easily.

My company, Openismus, provides bugmasters to corporate open source projects such as maemo.org. We know how to make the best use of outside contributions, so enthusiasts stay loyal, and we know how to manage bug databases for the long term. See the overwhelmingly positive feedback for Andre and Karsten, maemo.org’s bugmasters. They acquired these skills while establishing  GNOME’s bug squad, working on GNOME’s huge bug database.

I have linked to some Qt bugs as anecdotal examples of poor interaction with bug reporters. I am not interested in a discussion here of the technical aspects of these bugs. They are not meant to be technically critical. Also, half of them are for QtMobility, whose developers are generally very helpful, but even they haven’t learned the best bug-tracker habits. I don’t think I have seen enough Qt bug reports to have a fully representative sample, but my short experience does suggest that there are serious problems. I don’t mean to exaggerate or be unfair.

Awkward UI

Let’s look at a random bug. This view (not this particular bug) will be the first look at the bug-tracker for many people, as they follow a link to an existing bug. But it does not seem designed for humans. There are some particular problems:

How do I add a comment?

Typically, I’ll read the comments on a bug report to see what’s happening. But then there’s no obvious way to add my own comment. If I look around then I finally see a “Comment on this issue” link nestled among other less important action at the left hand side. I believe that many people won’t find that link, or will be discouraged by the awkwardness. I much prefer just writing a comment right into a bugzilla page.

Noise

The “all” page is too complicated, with lots of machine-generated noise. Instead of fixing that, there are tabs that show reduced views: All, Comments, Work Log, Change History, Transitions. This makes the whole page seem even more complicated.

The all page is so nasty that many people will switch to the comments page. But then comments lose their context. For instance, here (bug 7303) the Qt employee seems to be blaming the reporter though he is really just talking to someone that he has assigned the bug to. I’d rather just see a single page, as in bugzilla, without so much noise. The notification emails are similarly padded with irrelevant details.

Rush to close

We notice a strong tendency for the Qt employees to close bugs at any cost for any arbitrary reason as quickly as possible. Presumably they are under pressure to reduce the simple number of open bugs. But a bug-tracker exists to collect information that can gradually be used to improve software. If you think of everything as short-term and rush to ignore that information then you will not make the improvements and customers will assume that you don’t care.

Hard to check the fix

When I close bugs, I mention at least the commit message that I used. Sometimes I link to the commit’s web page on our gitweb or gitorious. But Qt bugs are often closed with a mention of the git commit ID (such as d65d3becc292523f0962aac9d2bf7b96d9c47c04), with no link. For instance, bug 8865 and bug 5729. I am thankful for the fixes but, particularly for documentation fixes, it’s best if I can verify it and reply quickly.

Viewing the change for a particular commit ID is awkward, requiring lengthy use of the command line outside of the browser. Even the gitorious web site doesn’t let me search for a commit ID, so I have to browse through pages of recent commits using the browsers find-on-page feature.

Actually, the person fixing the bug often cannot provide a gitorious web link at that time because that commit isn’t even public yet, because Qt’s gitorious repository is just a mirror, updated approximately daily from a secret repository. Things would be easier if they just worked in an open repository. In the meantime, Qt’s bug tracker should be hacked to recognize and link commit IDs, showing a “try tomorrow” page if the commit is not yet public.

Not supported. Not public

If the Qt developers decide (after the fact) that something in Qt is not supported then the bug may be closed, instead of leaving it open for someone to fix. But if something is not supported then it shouldn’t be in the release. For instance, bug 7334.

There’s also lots of Qt API that is used widely but not documented. Bug reports about the lack of documentation may be closed instead of leaving it open for someone to fix. But all API should be documented for the sake of implementation quality, regardless of whether it is public. And if API shouldn’t be used then its documentation should say that it shouldn’t be used.

Closing bugs because they require work

Bugs are sometimes closed because they would require effort to fix them. This makes no sense to me. Even if no Qt employee plans to fix them, they should stay open so others can fix them, and so that the information is kept in one bug report, with repeated reports being marked as duplicates. For instance, bug 5915.

Sometimes the idea of necessary work seems to be invented just as a way to close a bug. For instance, in bug 5729, a simple patch is not enough. The reporter is told that he must test it on multiple platforms, ignoring the possibility to test the harmless change widely during regular unstable releases.

For non-employees, the page even has some probably-unintentional machine-generated “You don’t have permission to work on this issue” at the left, just in case the reader didn’t feel unwanted enough already.

Out Of Scope

Likewise, if the Qt developers don’t personally see a problem as their priority then they will sometimes close it as “Out Of Scope”, regardless of whether the reporter cares about it or whether he might provide a patch.

Sometimes (bug 5729 again) this happens without the Qt employee even writing a comment explaining why. This is the bug-tracker equivalent of “Go away. We don’t want you to use our software”. Stopping this should be a top priority.

I’ve also seen one case (bug 6074) where this was used when the Qt developer meant “already fixed”. Until I asked for clarification (most people don’t) I assumed that they just didn’t care.

Can’t reopen bugs.

If a fix is not good enough, or the Qt employee has misunderstood the problem, I can’t reopen the bug. That is very frustrating. Most people will not beg for the bug to be reopened or even bother continuing to comment on the closed bug. Luckily we do have the option to submit gitorious merge requests when our bug has been incorrectly closed. For instance, bug 11496.

Can’t close bugs

There’s also no way for external contributors to close bugs. So Qt gets no outside help with bug triaging. This arbitrary separation between employees and external contributors is an obstacle to open development.

Tristan Van Berkom joined Openismus

General,

Tristan has been doing some challenging work for us recently, working on Glade, the GtkToolPallette, and finally finishing off the extended-layout improvements to GTK+ that Mathias Hasselmann started for Google’s Summer of Code in the days when he had free time. The extended layout fixes several user-noticeable problems in applications, making it easier for UIs to adjust properly to different screen sizes without hacks. It’s hard detailed work in lots of code, requiring Tristan’s methodical approach.

I hope that this will also allow some new types of container widgets. He might work on that when he’s back from Holiday in August.

Anyway, this post is just to say that Tristan has agreed to work with us for the foreseeable future so we always have someone with time to work on things like this.