Re: [Qt-jambi-interest] The Jambi Problem
Raymond Martin wrote: Hi all, On 8 March 2009 19:28:14 Mathias wrote: 1. The name. Qt Jambi. A powerful, mature, reliable and solid piece of software cannot be called Jambi. Whoever made that decision must have been out of his mind. Something like QTJ or JQT or even just a simple Qt for Java would have been A LOT better. I agree. I was often wondering where this jambi suffix came from. The present name is really not something that makes it simply to figure out or remember what the product is about. A serious product is better with a matter-of-fact type of name, QtJ or JQt would have been much better choices. The name Jambi stems from a province in Sumatra, reciding next to the island of Java in Indonesia. Though I wasn't involvned in the original naming, in hindsight, I'm easy to convince that Qt for Java would perhaps have been a better name ;) 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] Jambi and MIGLayout
Hi, Well you need to create a port your own and possibily contribute it back to the MIG-Layout people. It's quite easy to write your custom layout - I've done that with the SWT-GridLayout [1] in the past and it was only a CP-Task and then fix the compiler-errors. I also planned to take a look at MIG-Layout but had no time so far. Tom [1]http://dev.eclipse.org/svnroot/eclipse/org.eclipse.ufacekit/bundles/incubation/org.eclipse.ufacekit.incubation/org.eclipse.ufacekit.ui.qt/org.eclipse.ufacekit.ui.qt.core/src/main/java/org/eclipse/ufacekit/ui/qt/core/layouts/ Frans Thamura schrieb: hi all anyone have idea how to use MIGLayout with Jambi? -- -- Frans Thamura Meruvian One Stop Java and Enterprise OSS Provider Mobile: +62 855 7888 699 Blog Profile: http://frans.thamura.info Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... URL: http://www.meruvian.com Promo: Beli Zmanda Backup di Meruvian, 10% discount dari pricelist.. Buruan sekarang!!! ___ Qt-jambi-interest mailing list Qt-jambi-interest@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest ___ Qt-jambi-interest mailing list Qt-jambi-interest@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
[Qt-jambi-interest] Maintaining Qt Jambi
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
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
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
Re: [Qt-jambi-interest] The Jambi Problem
Gunnar Sletta wrote: The name Jambi stems from a province in Sumatra, reciding next to the island of Java in Indonesia. LOL! At least we now know... Seems a rather good idea for a company-internal codename got stuck and became the commercial product name. ___ Qt-jambi-interest mailing list Qt-jambi-interest@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
Re: [Qt-jambi-interest] The Jambi Problem
I'm in, what about you? Although I have plenty of free time at the moment, I don't know enough about Java internals, I don't know enough about C++, I don't know enough about Qt and I don't know enough about JNI. This was my point from an earlier post: Qt Jambi requires a lot of skills and a lot of internal knowledge about some seriously complex technology. If someone were going to pay me to learn and maintain it all, I'd jump at the chance. Since that's unlikely to happen I'm genuinely sad to say that I'll have to decline. ___ Qt-jambi-interest mailing list Qt-jambi-interest@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
Re: [Qt-jambi-interest] The Jambi Problem
2009/3/9 Mathias listo.math...@googlemail.com: I'm in, what about you? We are currently working hard on an open source product built on top of Qt Jambi. Half a year ago we made the decision for Qt after a lot of analysis and comparison of alternatives. However, we did not expect Trolltech to drop Jambi in the way it is doing now. Still, after having considered our options we will stick with Jambi. I think every framework or toolkit needs at least a few active, real-world sample/lamp post/flagship projects with some visibility in order to get people excited, serve as real-world demonstrations of what's possible and build trust. This is why I am really missing a Who-is-using-Jambi-page with an (ideally long) list of diverse, real-world applications. Since we are planning to have our project stick around for some time to come I would be willing to work with other community members to drive Jambi development from the real-world perspective. Of course, no single project will be using even close to the full feature set Qt is offering. This is why we need more applications to step up and share their experiences, contribute solutions, report problems and drive development. Who else on this list is building or maintaining an application available to the open public (be it open or closed source) that has a dependency on Qt Jambi? Please come out and let us know! We need to compile a list and see where we stand... Hello I'm implementing some dynamic GUI interface programing where I get some XML file with meta info and using it I can get data from some place and then use XSLT transform to create a JUI file that I load dynamically and add events. Jambi was then answer to my prayers, since it completely separates the GUI from the code, is good looking and extremely easy to create the JUI XML and also it is in Java which is my company chosen programing language... The project is closed source, but if needed I can provide some small case study. I'm really apprehensive on how this will turn out... Cheers, Mathias Regards Brian ___ Qt-jambi-interest mailing list Qt-jambi-interest@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest ___ Qt-jambi-interest mailing list Qt-jambi-interest@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
Re: [Qt-jambi-interest] The Jambi Problem
On Monday 09 March 2009, Mathias wrote: Who else on this list is building or maintaining an application available to the open public (be it open or closed source) that has a dependency on Qt Jambi? Please come out and let us know! We need to compile a list and see where we stand... Cheers, Mathias I'm developing Moonlight|3D (see http://www.moonlight3d.eu ), an open source 3D modelling and animation tool. I have been working on it more or less continously since 2003. I practically rewrote the program's UI when the first Qt Jambi preview releases appeared. This took me several months. I don't even want to think about rewriting the program's UI based on yet another toolkit (there's a long and painful story hidden there that you most likely don't want to hear about - trust me). I'd rather stop working on that project for good. Moonlight|3D uses quite some things from Qt Jambi: QGLWidget, QDockWidget, and QGraphicsView come to my mind instantly. There's also a nice set of QWidget- derived widgets that are implemented in pure Java (for example the toolchest, the timeline and the colour dialog). If the UI were more polished and the program less buggy overall I'd say that this is a good candidate for a hypothetical Qt Jambi showcase ;). 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
