Gitorious - more aspirations than action

A few of my more astute followers have probably noticed that I've migrated a lot of my personal projects like FaceBrick off of Gitorious onto Github, and a few people have asked me why I don't really like Gitorious, so I thought I'd sit down and put some words out on exactly why I've decided to migrate - in the (admittedly probably unlikely) hope that someone at Gitorious might actually hear this, sit up, and start taking notice.

First up, for those of you who don't know what these two services are, they're quite similar. They both serve to provide infrastructure for projects (such as an interface for Git repositories, Git being a version control system).


Firstly, some reasons why I consider Gitorious good:

• Gitorious is free software
• Gitorious is well established, providing hosting to some large projects I already do a lot of work with.

.. the problem is, that's about all it has over Github.

Github has:

• A (cool) issue tracker, being able to create arbitrary pretty labels is nice
• A better, more obvious UI exposing features like the wiki in a clear way
• A downloads section
• Graphs
• A much better UI for integrating third party changes (Merge Requests are positively clunky by comparison)

And then, the real reasons I started looking for alternatives to Gitorious in the first place:

• The fact that support@gitorious.org (email and otherwise) seems to be an alias to /dev/null
  
• An associate of mine sent a mail to support@ regarding a problem. No response.
• I myself have sent two mails to support@gitorious.org, one CCing someone who worked at Gitorious. No response.
• #gitorious on freenode seems full of people asking questions about Gitorious (both the code and the service) and totally devoid of people getting answers
This lack of feedback also exacerbates other issues mentioned below.
• The fact that bugs or strange lack of features exist and don't seem to really be addressed
  
• Spam in comments on commits is possible, yet deleting those spam comments or at least reporting them is not
• Deleting repositories (such as facebrick's which has now moved to Github) causes an error page without actually deleting the repository, happened multiple times on multiple repositories
• Useless mails from Gitorious when a merge request is updated:
  
  One of your favorites has a new activity:
  ------------------------------------------------------------------------
  dboddie updated merge request for aep-qt-upstream with qt
  
  http://gitorious.org/qt
  
  Don't get me wrong - this mail is great. But which favourite, which merge request? I have over 50 on follow. Linking me to the repository is not helpful when it has over 100 merge requests open, a large number of which I am following.

Hopefully someone can take this as a starting point to help Gitorious shine. And if the Gitorious people themselves should actually stumble across this, I hope you take the criticism to heart as a way to improve.

And yes, I know it's open source so I can do this myself. But frankly, I have enough projects sucking at my free time. I don't need more. So I'll use the best tool for the job and let other people go about developing it.

MeeGo Developer Engagement

Some of the more observant people may have already seen my mail to meego-dev proposing a program for developer engagement, or one of the forum threads about it within the relevant communities I'm targeting with it. (and for those of you who haven't, you have now!).

I made the unfortunate mistake of advertising this proposal just before heading off to Oslo, so I wasn't able to do it justice on the mailing list or write about it here, so, it's probably time to stop, pause, and reflect a bit.

In the days after writing that, I have been approached by a few people pointing out various other good work in a similar vein to this, such as the MeeGo application developer site being spearheaded by Ronan, all of which is great news - it's nice to know that I'm not alone in thinking that we need comprehensive developer help networks set up sooner, rather than later. So the tutorials side of my proposal can probably largely be shifted under the application developer site.

Where does that leave me? I still think that my proposal has value to add - primarily: a human touch. I think that the majority of we hackers are at heart a social bunch (of antisocial individuals, ironically). We don't like answering machines, or being fobbed off with boilerplate answers, and when we have problems, we want to talk to someone about it, and that's where developer engagement can really help go the last mile. We have technical solutions to this (blogs, and whatnot) - but at heart, it's a social issue, and we need to make sure we're fostering and encouraging the right attitude of collaboration and community to help carry the load.

I still don't have the answers to how this is going to fit together, despite a lot of soul searching over my brief time in Oslo, but I hope to schedule an IRC meeting sometime within the next week or two with the energetic bunch of volunteers that I have already picked up to discuss priorities, options, and where we go from here.

Change for the sake of change

Blogspot offered new templates and more customisation, I opted to use them. Not much more to say here. ;)

I really do wish they weren't all fixed-width though. I have screen space. I want to use it.

Sigh.

A visual approach to Qt's model/view framework

If you're reading this, you probably use Qt for some reason or other. And if you use Qt, it's only a matter of time before you run into one of the 'pillars' of Qt 4: the Interview Framework, also known as model/view. If you need a little background, read on, otherwise, feel free to skim the next few paragraphs.

Interview is an approach to the problem where you have your data, and you keep it in two places: in your objects, and in your user interface. In more traditional techniques, you have your widgets, and you have your data, and you spend time keeping the two in sync, and it grows kind of organic and messy.

With model/view, you keep everything nicely separated, which is great. That having been said, Qt's implementation isn't really the easiest to use in the world, in some ways. One of my least favourite bits about it is on the view end: delegates. You see, if your UI is anything but plain, everyday, displays of a single string in a list, you'll have to write a delegate.

When writing a delegate, you're pretty much left to your own devices in how you present your data, which is great flexibility - you can paint the 'mona lisa' as the background of all your items or whatever else your heart desires - but at the same time, it is very low level, meaning it is hard for new programmers to wrap their heads around, very easy to make mistakes, both in terms of rendering incorrectly, and really bad performance.

I've mused about this problem in my head for a long time, but more recently, I've had to approach it a few more times, in both FaceBrick and some things I'm working on at Collabora, which proved to be the final straw.

There has to be a better way than telling Qt how to paint everything and where and in what order, like FaceBrick currently does, which also involves a fair chunk of work to attain good performance. It's a daunting task.

QML (so I am informed) has similar principles to what I've applied here, but unfortunately, QML isn't quite ready for the prime time, both in that it requires Qt 4.7, and that it doesn't have a set of established platform widgets - which IMO it needs to prevent every application having to reinvent the wheel.

After some hacking last week, and a little more this week - (with partial thanks again to my employers, Collabora) - I've come up with my initial solution to this problem: QtWidgetListView.

Here's the test I wrote using it, in action on Maemo. The text above the line edits is retrieved from a model, and the line edits + button can be used to update the text, also using the model.

To use QtWidgetListView, here's a rough workflow:

• Create your own widget subclass
  You can do this using Qt Designer, or write the C++ by hand if you feel like it.
  
  
  • Inherit from the QtModelWidget class.
  • Your constructor must be like the following:
    
    

    Q_INVOKABLE

        explicit TestWidget(QAbstractItemModel *model, QModelIndex index)
    
    (In particular, the Q_INVOKABLE and data types are very important)

  • Implement 'virtual void dataChanged()' from QtModelWidget
    
    This method is called when data in the model relating to your widget changed.
    
    You should set text on labels, hide/show components, etc here, fetching the data similarly to a delegate:
    
    m_ui->setText(model()->data(index(), Qt::DisplayRole));
• Write your model (inheriting QAbstractListModel is the easiest way), making sure you emit the right signals (dataChanged(), etc).
• Then, do something this:
  
  MyModel model;
  QtWidgetListView wlv;
  wlv.setMetaObject(&MyWidget::staticMetaObject());
  wlv.setModel(model);
  wlv.show();

And that's it. You should now see widgets created for each of the rows in your model.

Before I forget, I should note that this won't perform as well as delegates - generally speaking. In particular, it will require more RAM, especially if you have a lot of rows.

Now, if you stuck with me for the whole post (or if you skimmed to the bottom because the post was too long and boring..) - the source code for QtWidgetListView is available at http://github.com/rburchell/qt-interview-widgets - patches and feedback are welcome, and I hope you find it useful. My aim is to flesh things out a bit more and then consider talking to the Qxt folks to get this integrated.

Maemo? Portrait keyboard? Yes, we can!

The topic pretty much sums it up.

I got sick of applications reinventing portrait keyboards, and so dug around to find something that would work a bit more generically. I found that hildon-input-method had some example plugins, one of which provided a portrait-usable keyboard (pictured left). So, after the help of frals (and Stskeeps and yerga), we're on the road - now it's your turn to help us get a bit further.

It's still in a very early stage, and the stuff we're dealing with (hildon-input-method) is pretty scary ..not to mention that I'm not really the most experienced person in the world when it comes to raw Hildon/Gtk+, but I'm sure we can get there, with some help.

If you want to help out, come join us in the talk.maemo.org thread and wander over to Gitorious.

Good news comes in bundles

Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth;

For those of you that hadn't heard already, I just wanted to share a piece of good news: Qt have officially announced plans to start moving to an open governance model.

Then took the other, as just as fair,
And having perhaps the better claim,
Because it was grassy and wanted wear;
Though as for that the passing there
Had worn them really about the same,

And both that morning equally lay
In leaves no step had trodden black.
Oh, I kept the first for another day!
Yet knowing how way leads on to way,
I doubted if I should ever come back.

This is by no means going to be a short, or an easy journey, but I have high hopes that it will be productive, fulfilling, and rewarding in the long term.

I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I--
I took the one less traveled by,
And that has made all the difference.

-- Robert Frost

---

Down to business, it's important to realise that this is not going to happen overnight.

But: in the longer term, we should see infrastructure start to open up, as I wrote about previously. For example, I've already had some chatter with some people from Qt about the work I've done on open testing infrastructure on #qt-labs, as they have similar goals.

With open mailing lists, quality assurance, and other infrastructure, we will have the beginning blocks for a true meritocracy, a more level playing field for independent contributors to Qt.

With that, we will have the capability for anyone to scratch their itches easily, without being bogged down in process, while at the same time, maintaining the high quality and feature set Qt already has today, as a result of keeping the same talented, quality people around.

We're not there yet, and we won't be for a while, but the mould has been made, and now: it's time to get to work.

Qt: open testing infrastructure

I recently wrote a post about how Qt could become a more open project, but after writing it, I was left asking myself what more I could do to help further the process.

As a result, I'd like to introduce you to a project I lovingly title the Qt Community Integration System. Its aim: to automatically build, test, and publish community merge requests.

This is an important step in order to help streamline the process of community contribution and get feedback to individual developers quicker. Qt  internally use a similar system, but theirs is not (yet?) public.

How does it work? There are a number of components:

• A community Qt repository (why not the 'official' one? read on - this is not a fork)
  
• This repository is updated by an integration script, which pulls pristine Qt, applies designated merge requests over the top of it, and then pushes it to the master-proposed branch, if they all merge cleanly.
  
  These lists of merge requests are currently maintained by ..me.
  
  However, the intention is to give other trusted people, such as those in #qt-labs or who submit frequent merge requests, access to edit these lists and push to this community repository too, so it becomes possible to request integration of a change if you're experienced and trusted.
  
• A BuildBot which pulls Qt from the master-proposed branch of this repository, and then proceeds to try to configure, compile, build, and run Qt's extensive test suite, with the help of a custom tool I have purpose-written for this task, unimaginatively called qtestrunner.
  
  The results of these tests are then published on a website, where they may be viewed by others.
• This last bit of this puzzle isn't quite finished, but, assuming all of the above steps succeed with no regressions from the previous test run, the master-community branch is updated with the latest contents of the master-proposed branch, as a working snapshot of Qt+community patches.

(Of course, 'master' will eventually be 'all current Qt branches'. I just wanted to pick one to start with.)

So, after I've described all of the above utopia, what's the current status? Well, I've got a lot of the pieces in place, and now I'm fighting problems with Xvfb causing some of the Qt GUI tests to fail *sometimes*, (even though they don't when I run them manually). Once that is solved, I hope to start adding people's access to integration, and start test-integrating merge requests. :)

Hopefully, all this work will help to accelerate the time it takes to send merge requests back for review if they break something, and ease the burden on getting requests merged in (due to requiring a little less testing). Time will tell. But at least I'm doing my bit. Patches welcome. :)

(thanks to John Brooks for copy-editing my appalling English as usual)

FaceBrick - GSOC

FaceBrick reached a bit of a mini-milestone today, as it recieved its first external contribution. Kamilla Bremeraunet, FaceBrick's GSOC student, submitted her first merge request adding changing of font sizes based on volume keys.

I made a number of notes where it could be improved, but all in all, it is a fairly solid piece of work.

Here's hoping it continues to move onto bigger and better things.