AUG
10
2010

QtRuby forked on github

Ryan Melton announced on the kde-bindings mailing list that he had set up a project on github called 'qtbindings' with the aim of doing cross-platform gems for QtRuby. This is great news, and congratulations to Ryan for making it happen

Ryan announced:

"..I put together a new cross-platform gem for the Ruby bindings to Qt and put it out on rubygems.org as "qtbindings". This should make it a lot easier for people to install the ruby bindings on non-KDE systems. I've tested it out on Windows XP, Ubuntu Linux, and Mac OSX Snow Leopard so far and it seems to work great. It is mainly the code straight from KDE bindings, but it also includes the patches for building on Windows I submitted to this list back in February, the fix for ExtraSelection, and some new fixes I've put in for the HWND__* classes on Windows. I will be submitting the new patches back to this list soon. Some other changes include minor modifications to the CMakelists.txt files, and reorganizing the folders into a standard ruby gem structure that I doubt you would want to incorporate back into the kdebindings repository. Enjoy and I hope this increases the adoption of the great bindings you guys put together! :).."

So although it is a fork, it isn't a hostile fork and so I think the benefits of making QtRuby easy to install on Windows and Mac OS X outweigh the disadvantages.

Over on the RubyForge site there is a new version of QtRuby, qt4-qtruby-2.1.0, which I didn't produce either (Jan Pilz? not sure, need to find out), and that is great news too. A new release there was long overdue.

Meanwhile the Maemo/MeeGo widget testing guys are really keen to have a version of QtRuby that wrapped the MeeGo Touch (ie libdui) libs, and Qt Mobility. They use Gitorious and so a version of QtRuby that you could be with qmake instead of cmake would be really good, and ideally hosted on Gitorious so they would be able to make enhancements and fixes using their Gitorious accounts.

I worked on a major refactoring of QtRuby which is long overdue. But that work has stalled because I have been waiting for KDE to migrate to git. I was expecting it to have happened a month or two ago as we were negotiating with the Gitorious guys for a long time, and it seemed as though we were going to get the migration done about June 2010 time when I was thinking about it last Christmas. That wasn't to be as the Gitorious negotiations fell through, and instead on his recent blog Tom Albers reports that the schedule for git conversion won't start converting the main kde modules like kdebindings until November 17th:

November 17th: "..
After the initial flow of individual projects that have moved to git, we are open to assist in moving the KDE modules. How this part will happen is unknown and will probably not happen directly at this point in time.."

I have other projects like the JSmoke JavaScript bindings on Gitorious, or the Wt::Ruby bindings on github that I would like to be able to coordinate with QtRuby and the smokegen bindings generation tool. All the other projects are in git, and it is becoming increasingly difficult to know how to cope if I just leave QtRuby in the KDE svn where it has been since the project started seven years ago. But clearly if I don't do something, things will just get into even more of an unmanageable mess than they are at the moment.

As far as I know it will be possible to move to the KDE git repo in advance of sometime next year, otherwise that would be after the KDE 4.6 release, and I'm just not keen on waiting that long. If the move isn't a lot sooner than that, I feel I will just have to give up, and probably treat the 'qtbindings' github repo as the main center of development for QtRuby.

On an unrelated note my employer, Codethink, are looking to qt/qml guys, Alberto Ruiz sent me this:

Codethink Ltd. is looking at the possibility of hiring a
few people with Qt/QML experience, people that have contributed stuff to
Qt upstream is a plus. Please send your CVs to [email protected]
Codethink is an exciting place to work at, and they allow people to work
from home which is great, the head offices are in Manchester so if you
don't like working from home you can always join us from our offices.

I can confirm that Codethink is an interesting place to work, and their tee-shirts aren't bad either. So get in contact if it appeals.

I was actually going to investigate QML and language bindings and do a blog about that to make it more relevant to what Alberto is asking for. But I found it a really hard problem and I haven't decided what the best thing to do is yet. Should we try and do a Ruby version of QML and compile it to the same form as if it had been JavaScript, or do we keep all the JavaScript stuff and attempt to mix it up with Ruby code? I don't know yet.

Comments

As far as I know it will be possible to move to the KDE git repo in advance of sometime next year, otherwise that would be after the KDE 4.6 release, and I'm just not keen on waiting that long. If the move isn't a lot sooner than that, I feel I will just have to give up, and probably treat the 'qtbindings' github repo as the main center of development for QtRuby.

I'm currently working on the svn2git rules for the kdebindings module (shouldn't be too difficult I think, we didn't have that many 'real' feature branches that were merged into kdebindings). I'd suggest to rip out every binding that is not KDE specific and put that into a seperate repository on gitorious. Smoke, Smokegen, QtRuby, Qyoto, PHPQt aren't really related to KDE, except for the fact that they're developed by KDE developers.
To make releases more flexible, I think we should have them separate from the rest of KDE. This will also help us in getting the remaining KDE bindings more organized; we could start transferring the bindings to the modules they actually bind.
Seeing that konversation and amarok have already moved to KDE git, we can maybe negotiate an earlier move of KDE bindings to git as well (more testers for the git infrastructure are certainly helpful).

But getting the Qt-only bindings into git repos ASAP would really be nice.


By arno rehn at Wed, 08/11/2010 - 13:55

"..I'm currently working on the svn2git rules for the kdebindings module (shouldn't be too difficult I think, we didn't have that many 'real' feature branches that were merged into kdebindings).."

Brilliant, that sounds perfect. I really don't want to wait until after late November this year before kdebindings gets moved to git, and possibly miss the KDE 4.6 release - that would be a bit of a disaster.

"..I'd suggest to rip out every binding that is not KDE specific and put that into a seperate repository on gitorious. Smoke, Smokegen, QtRuby, Qyoto, PHPQt aren't really related to KDE, except for the fact that they're developed by KDE developers.."

Yes, that sounds a good plan too. My understanding that with git we don't need to have a 'master' repo but can push changes between git repos. So we can coordinate developments on KDE git, Gitorious and Github by pushing the changes between those repos, but still allowing contributors to do their work wherever they feel most comfortable.

"..To make releases more flexible, I think we should have them separate from the rest of KDE. This will also help us in getting the remaining KDE bindings more organized; we could start transferring the bindings to the modules they actually bind.."

Yes I've wanted to get as much as possible out of the kdebindings module and into the modules they bind. I'm not sure we need releases seperate from the rest of KDE - maybe for tools like smokegen it is OK, but for the bindings themselves we should still try and coordinate with KDE releases.

"..Seeing that konversation and amarok have already moved to KDE git, we can maybe negotiate an earlier move of KDE bindings to git as well (more testers for the git infrastructure are certainly helpful).."

Yes, absolutely we need to do that. As it might be obvious from the blog, I am feeling more and more exasperated by the slow migration from SVN and it is already messing up KDE bindings development from my point of view.


By Richard Dale at Wed, 08/11/2010 - 15:25