[Qt-jambi-interest] Maintaining Qt Jambi

2009-03-09 Thread Gunnar Sletta
Several threads have started asking questions around this and we've been 
rather quiet on our part, so I'll try to formulate some answers.

Up until the 4.4 release, Qt Jambi was a full time job for two 
developers. This was for a number of reasons:

  - The project was still pretty new and the bug load was steady, and 
some of the bugs that came in were down-right tricky ;) Since the 4.4 
release, we've noticed a significant decrease in bugs, so we seem to be 
over the worst infancy. We've managed to fix most issues related to 
library resolving, memory management, garbage collection and signal/slot 
connectins by now, so the things that remain are simpler.

  - Qt 4.4 added TONS of features. Each new feature needs to be ported 
to Qt Jambi and even though this is ideally a matter of putting the 
classname into an .xml file, there tends to be a bit more. With 4.4, we 
had the problem that the generator didn't support namespaces, but phonon 
required those. The Qt Concurrent API was heavily template based which 
the generator didn't support so a lot of work was spend on the generator 
to make it capable of supporting the features we needed for 4.4. 4.5 
added very few features and I expect 4.6 to also be less extreeme, and 
even if there comes a release with loads of features we're still in 
better shape because the generator is more capable and the rest of the 
issues are fewer.

  - We do spend a significant amount of time in packaging, testing and 
fixing the small things here and there prior to each of our releases.

Currently Eskil and I spend maybe one day a week on the project. Its far 
from a full time job. Of course, we know all the details very well so 
one coming from the outside and contributing his/hers first patch would 
naturally spend some more time until they are up to speed.

When we're closing a Qt release, we tend to spend around from a week to 
a month or two of time were we port all the new functionality to Jambi.

---

The codeline-illustration by Gregor is pretty correct. Qt Jambi is 
primarily a C++ project and its all about understanding two individual 
parts.

  1. The Generator. Its the key to it all... It reads C++ header files 
and uses the XML files to understand the API. In an ideal world, a 
maintainer would never have to touch the generator C++ code, but just 
add things to the XML files.

  2. The runtime, the qtjambi directory. This is where the memory 
managmenent is handled, GC'ing, GUI objects vs non-GUI objects being 
deleted on main thread etc, but it goes hand in hand with the decisions 
we made in the generator.

There is some Java code in the com.trolltec.qt package but its mostly 
utility for stuff that got to nasty to write in JNI ;)

---

As for documentation, the innermosts parts of the generator and the 
decicions we made during the porting, aka how do we solve multiple 
inheritance is somewhat documented in the original whitepaper.

http://dist.trolltech.com/pdf/QtJambi_4.3.0_Whitepaper_A4.pdf

Eskil also wrote an article in the latest Qt Quarterly that I'll post a 
link to once I figure out where it is ;)

---

As for help... We hope to get the hosting of the project up and running 
and we'll probably do the patch-releases on the 4.5 series in the hosted 
repository. We'll also be here for another year, answering questions, so 
if there are people who are interested, they have a source for answers.

---

best regards,
Gunnar
___
Qt-jambi-interest mailing list
Qt-jambi-interest@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest


Re: [Qt-jambi-interest] Maintaining Qt Jambi

2009-03-09 Thread Arthur Pemberton
On Mon, Mar 9, 2009 at 3:03 AM, Gunnar Sletta gun...@trolltech.com wrote:

 As for help... We hope to get the hosting of the project up and running
 and we'll probably do the patch-releases on the 4.5 series in the hosted
 repository. We'll also be here for another year, answering questions, so
 if there are people who are interested, they have a source for answers.


Forgive me if this seems a bit 'hard headed', or more of a business
question but I do not see how this fits into the Qt Everywhere
mantra.

I was expecting to see greater language binding support instead of
purely community based support. Things like tigter IDE
(Eclipse/Netbeans) support, quicker release times, etc. Something that
suggests that Jambi is here to stay and growing.

Maybe I'm just being overly pessimistic about this as the situation
seems similarly bleak in the PyQt area.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
___
Qt-jambi-interest mailing list
Qt-jambi-interest@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest


Re: [Qt-jambi-interest] Maintaining Qt Jambi

2009-03-09 Thread Gunnar Sletta
Arthur Pemberton wrote:
 On Mon, Mar 9, 2009 at 3:03 AM, Gunnar Sletta gun...@trolltech.com wrote:
 
 As for help... We hope to get the hosting of the project up and running
 and we'll probably do the patch-releases on the 4.5 series in the hosted
 repository. We'll also be here for another year, answering questions, so
 if there are people who are interested, they have a source for answers.
 
 
 Forgive me if this seems a bit 'hard headed', or more of a business
 question but I do not see how this fits into the Qt Everywhere
 mantra.

I can only answer this from a personal perspective, but Qt Everywhere to 
me means a widened use of Qt C++.

 I was expecting to see greater language binding support instead of
 purely community based support. Things like tigter IDE
 (Eclipse/Netbeans) support, quicker release times, etc. Something that
 suggests that Jambi is here to stay and growing.

With the release of Qt Creator, we will probably increase the focus on 
our own IDE, rather than integrating with existing ones.


___
Qt-jambi-interest mailing list
Qt-jambi-interest@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest