On Saturday 07 March 2009, Derek Fountain wrote: > > Let me rephrase this question: Who on this list would be willing to step > > forward and help maintain Qt Jambi? > > You might need to start with "who on this list is *capable* of helping > to maintain Qt Jambi?" > > Judging by the activity on this list, there's hardly anyone involved > with Qt Jambi - a few dozen names maybe? Of those, almost all are users.
I do not know how many are subscribed to this list and I'll never find out. But is the number of subscribers a good measure for the number of users out there? I only subscribe to mailing lists such as this one when I use something extensively and I discover a problem that I need help with. I find Qt Jambi easy to use and the number of questions I had to ask has been relatively small. So maybe our view is just distored because Jambi is such an excellent product ;-). > I suppose the starting point might be for the Trolls to write some > in-depth white papers about how it all works so some other people can > pick it up and work with it. Is that happening? Even if it does, it > won't help with Qt 4.6 very much. Who is going to know the in depth > details of the 4.6 implementation updates, to the point they can say > "...this affects Qt Jambi in this way, so we'll need to reimplement this > part of Qt Jambi using this technique..."? Only the Trolls. Retaining > and updating that level of knowledge is a full time job. > [...] > > Wishing and hoping that my arguments are shot down in flames and I'm > comprehensively proved wrong... I'll give it a try. Let me start by giving a few numbers. I just looked at the qtjambi 4.4.3_01 source archive and see that it contains roughly the following: * about 6800 lines of Java code in org.trolltech.qt * about 8500 lines of C++ code in the qtjambi* directories * about 30000 lines of C++ code in the generator directory * about 13000 lines of genererator XML files The first two sets of directories contain the Jambi runtime core and other stuff that does not fit the standard pattern that the generator can deal with. The generator is the core of the whole thing. So, this tells me two things: 1. Qt Jambi is essentially about getting the Qt object model mapped to Java. This means mostly pointers, garbage collection and the signal/slot mechanism. And this has already been dealt with - by providing a single way of doing it for almost the whole of the Qt library. 2. The amount of exceptions from that pattern that require some coding tricks is quite small. This means that the amount of pitfalls that are left with the way the mapping works currently is also quite small. Bottom line: the key to maintaining Qt Jambi is to understand the generator. Granted, having to map objects between models that behave quite differently can be mind-boggling at times. But there is a working solution right here that shows how it can be done. My guess is that it could be done by a team of roughly 3 to 5 people in their spare time while maintaining the current quality. Unfortunately, I don't think that I could be among them. Regards, Gregor
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt-jambi-interest mailing list Qt-jambi-interest@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
