The good thing about transatlantic flights is that it gives me an opportunity to watch movies on a tiny screen that I otherwise wouldn’t watch at all. On my outbound flight to the US last week I managed to watch Shrek and most, but not all of Toy Story 3. I needed closure though. Will Woody unite the toys and save the day? Will Buzz ever be the same again? The return flight yesterday(today?) brought the closure, but also gave me some time to work on something I’ve been putting off for a while.
I originally wrote KIdentityProxyModel with the intent of putting it into Qt on request. Once it gets into Qt I’m no longer the maintainer, so someone else in Nokia gets to decide whether to apply patches I submit to it. I needed to make sure it was as correct as possible before submitting it so it went into kdelibs for an incubation period.
There are many style and structural differences between kdelibs classes and Qt classes. Documentation in kdelibs is usually in the header file, whereas in Qt it is always in the implementation file. In kdelibs, we use a _k_ prefix for Q_PRIVATE_SLOTS, whereas Qt uses a _q_ prefix. Easily updated with some perl dash pie. Another difference is that the protected constructor takes an instance of the private class as a reference instead of as a pointer. I only recently realized the reasons for doing it that way. Finally, In the case of proxy models, the source model is usually referred to as d->model instead of q->sourceModel(). That’s possible in Qt, but not in kdelibs because of the inheritance of QAbstractProxyModelPrivate.
With all of those changes made I submitted the MR for the patch that mostly I wrote around the time of Akademy in July. It’s an interesting time to be submitting classes to Qt, not least because of the column inches it is getting these days. Contributors are eager to find out the extent that the Qt Open Governance model will facilitate these kinds of contributions and make them easier and sustainable.
In a KDE context it is even more interesting. There has been lots of discussion since the end of last week about the role of the kde libraries in the greater Qt ecosystem. Do Qt developers know useful libraries are in kdelibs? How can we make those libraries easier to find, access, and use? One proposal is to attempt to submit as much as possilble of kde libraries into Qt itself. That would require dramatic changes to the current maintenance and contribution model, so it will be interesting to see where that goes.