Re: [Qt-jambi-interest] potential build environment issues (was: cant get qtjambi 4.6+ working on linux, UnsatisfiedLinkError)
Hi! This is a puzzling issue related to the GCC version used to build the Qt libraries. For each version of GCC there is a corresponding version of the C++ runtime library that must be present on the target system. Specifically, on the system that produced the log you provided, libc.so.6 is either missing (very unlikely) or too old (mildly surprising) for the binaries shipped with Qt Jambi. That this problem occurred with Qt Jambi 4.6.x and newer is related to the fact that the build environment had to be rebuilt from scratch after Qt Jambi was discontinued by Trolltech. Everything up to Qt Jambi 4.5.x was built by Trolltech on an archaic kubuntu system (I think it was 4.04 or 5.04 or so) for compatibility reasons. What distribution is used to build the current binary releases? It might be wise to choose an older one for that purpose in the future. Regards, Gregor Original-Nachricht Datum: Tue, 12 Oct 2010 14:17:49 +0200 Von: Thomas Amland thomas.aml...@gmail.com An: qt-jambi-interest@trolltech.com Betreff: [Qt-jambi-interest] cant get qtjambi 4.6+ working on linux, UnsatisfiedLinkError I got this odd thing going on i cant figure out why is happening. This is my system: Linux user-desktop 2.6.31-22-generic #65-Ubuntu SMP Thu Sep 16 16:21:34 UTC 2010 x86_64 GNU/Linux java version 1.6.0_20 Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) which is clearly 64-bit. But for some reason the qtjambi 64-bit doesnt work (stacktrace below) and the 32-bit version does! This applies to 4.7.0beta2, 4.6.x, but NOT 4.5 and 4.4 Just to be sure i tried it on a different machine: Linux 2.6.32.21-168.fc12.x86_64 #1 SMP Wed Sep 15 16:12:07 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux java version 1.6.0_20 Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) ..and here its opposite. Only 64-bit works, as expected. Any ideas whats going on? $ ./qtjambi.sh Exception in thread main java.lang.ExceptionInInitializerError at com.trolltech.qt.gui.QWidget.clinit(QWidget.java:18) Caused by: java.lang.RuntimeException: Loading library failed, progress so far: Unpacking .jar file: 'qtjambi-linux64-gcc-4.6.3.jar' Checking Archive 'qtjambi-linux64-gcc-4.6.3.jar' - cache key='gcc-20100620-2121' - adding 'libstdc++.so.6' to library map - library: name='lib/libstdc++.so.6', - adding 'libQtCore.so.4' to library map - library: name='lib/libQtCore.so.4', - adding 'libQtGui.so.4' to library map - library: name='lib/libQtGui.so.4', - adding 'libQtXml.so.4' to library map - library: name='lib/libQtXml.so.4', - adding 'libQtSql.so.4' to library map - library: name='lib/libQtSql.so.4', - adding 'libQtSvg.so.4' to library map - library: name='lib/libQtSvg.so.4', - adding 'libQtHelp.so.4' to library map - library: name='lib/libQtHelp.so.4', - adding 'libQtScript.so.4' to library map - library: name='lib/libQtScript.so.4', - adding 'libQtScriptTools.so.4' to library map - library: name='lib/libQtScriptTools.so.4', - adding 'libQtMultimedia.so.4' to library map - library: name='lib/libQtMultimedia.so.4', - adding 'libQtNetwork.so.4' to library map - library: name='lib/libQtNetwork.so.4', - adding 'libQtOpenGL.so.4' to library map - library: name='lib/libQtOpenGL.so.4', - adding 'libQtWebKit.so.4' to library map - library: name='lib/libQtWebKit.so.4', - adding 'libQtXmlPatterns.so.4' to library map - library: name='lib/libQtXmlPatterns.so.4', - adding 'libphonon.so.4' to library map - library: name='lib/libphonon.so.4', - adding 'libQtDBus.so.4' to library map - library: name='lib/libQtDBus.so.4', - library: name='plugins/phonon_backend/libphonon_gstreamer.so', never load - library: name='plugins/imageformats/libqjpeg.so', never load - library: name='plugins/imageformats/libqgif.so', never load - library: name='plugins/imageformats/libqmng.so', never load - library: name='plugins/imageformats/libqtiff.so', never load - library: name='plugins/imageformats/libqsvg.so', never load - library: name='plugins/iconengines/libqsvgicon.so', never load - library: name='plugins/codecs/libqcncodecs.so', never load - library: name='plugins/codecs/libqjpcodecs.so', never load - library: name='plugins/codecs/libqkrcodecs.so', never load - library: name='plugins/codecs/libqtwcodecs.so', never load - library: name='plugins/accessible/libqtaccessiblewidgets.so', never load - library: name='plugins/sqldrivers/libqsqlite.so', never load - adding 'libqtjambi.so' to library map - library: name='lib/libqtjambi.so', - adding 'libcom_trolltech_qt_core.so' to library map - library: name='lib/libcom_trolltech_qt_core.so', - adding 'libcom_trolltech_qt_gui.so' to library map - library: name='lib/libcom_trolltech_qt_gui.so', - adding 'libcom_trolltech_qt_xml.so'
Re: [Qt-jambi-interest] getting a gl3 context
Hi! Qt Jambi really requires JOGL as an interface to OpenGL itself, as this is out of the scope of Qt. There exists another set of bindings called LWJGL that can probably used instead of JOGL, but there is no way to do OpenGL rendering with Qt Jambi alone. I just printed the GL version string returned by a QGLWidget-created OpenGL context and it is reported as 4.0.0 NVIDIA 256.40 (on Linux). So at least in that combination, no dedicated setup code is required for OpenGL 3.x or higher. However, I cannot test on ATI hardware/drivers. From experience I know that if such a high version number is reported, the functionality is also truly there, so the nVidia driver isn't flat-out lying. But you only get backward-compatible contexts that way, not forward-compatible ones. I'm curious whether you can confirm that behavior. Regards, Gregor Original-Nachricht Datum: Fri, 8 Oct 2010 07:57:20 -0700 Von: Josh Stratton strattonbra...@gmail.com An: Samu Voutilainen s...@smar.fi CC: qt-jambi-interest@trolltech.com Betreff: Re: [Qt-jambi-interest] getting a gl3 context It was my understanding that QtJambi required JOGL to use OpenGL rendering. If this is not the case, I would absolutely be thrilled, but I've only seen examples where JOGL is used alongside QtJambi (like the link below). http://hoheinzollern.wordpress.com/2009/03/21/off-screen-rendering-with-qtjambi-jogl/ Without including the JOGL libraries, I was hitting import errors saying things like GLProfile weren't found (which is indeed a JOGL class). Also using the code I provided and using a GL2 context, QtJambi seems to work fine. If there are any QtJambi/OpenGL examples out there that don't require JOGL, I would be very happy to not have to include the JOGL libraries anymore. Thanks, Josh On Fri, Oct 8, 2010 at 1:03 AM, Samu Voutilainen s...@smar.fi wrote: On torstai 07 lokakuu 2010 20:40:02 Josh Stratton wrote: I'm having some difficulty getting a GL3 context now that I've switched to QtJambi. When casting my gl object to GL using getGL3, it throws the error javax.media.opengl.GLException: Not a GL3 implementation. This is my original code when I was using swing... GLProfile profile = GLProfile.get(GLProfile.GL3) GLCapabilities glCaps = new GLCapabilities(profile) glCaps.setPBuffer(true) GLPBuffer pbuffer = GLDrawableFactory.getFactory(profile).createGLPbuffer(glCaps, new DefaultGLCapabilitiesChooser(), 1, 1, null) canvas = new GLCanvas(glCaps, new DefaultGLCapabilitiesChooser(), PanelGL.pbuffer.getContext(), null) Switch to QtJambi, I have the following code: GLProfile profile = GLProfile.get(GLProfile::GL3) GLCapabilities glCaps = GLCapabilities.new(profile) glCaps.setPBuffer(true) factory = GLDrawableFactory.getFactory(profile) ctx = factory.createExternalGLContext gl = ctx.getGL.getGL3 This last line throws an error. I've seen this page (http://www.javagaming.org/index.php?action=printpage;topic=21064.0), which solves the issue, but it's passing something to a GLCanvas constructor, which is swing. Is there an equivalent setup in QtJambi to get me a GL3 object? ___ Qt-jambi-interest mailing list Qt-jambi-interest@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest Do I misinterpret this, but are you trying to mix up pure Java objects with Qt Jambi objects? Qt has its own OpenGL module, QtOpenGL, can’t you use it? There is a bridge which should allow bridging AWT widgets and Jambi widgets, butI don’t know if it can cope with Swing types. Most likely no. http://qt.gitorious.org/qt-jambi/community-qtjambi-awtbridge ___ 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 -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome -- GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl ___ Qt-jambi-interest mailing list Qt-jambi-interest@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
Re: [Qt-jambi-interest] how to add a '+' or 'x' to the Tab bar ?
Original-Nachricht Datum: Tue, 28 Sep 2010 03:02:06 -0700 (PDT) Von: go canal goca...@yahoo.com An: qt-jambi-interest@trolltech.com Betreff: [Qt-jambi-interest] how to add a \'+\' or \'x\' to the Tab bar ? Hi, Would like to know how to add a '+' or 'x' to the tab bar. Ideally I want to add image button at the right most position of the tab bar together with a title. If I click '+', then a new tab is created; 'x' to close the current tab. thanks, canal Hi! Have looked at QTabWidget#setCornerWidget? That seems to do exactly what you want. If you don't use a complete QTabWidget, but only a QTabBar, I'd suggest you put that tab bar and your widgets inside a common parent layout or widget to place them side by side. Regards, Gregor -- GMX DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail ___ Qt-jambi-interest mailing list Qt-jambi-interest@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
[Qt-jambi-interest] Availability of new official builds?
Hi! I am asking this because I am unsure about the status in which Qt Jambi support is now within Nokia. Are you going to provide any new builds or is 4.5.2_01 the last official build that we are going to see from Nokia? The reason is that I don't have the resources to build Qt Jambi for all platforms that Moonlight|3D runs on (or could run on, for that matter). My guess is that others on this list have similar problems. The build systems for all of these platforms will have to be recreated, too. So could you give us some information on what you use for that (what operating system/distribution/compiler/special modifications)? Especially on Linux it seems to me that you can easily create C++ binaries that are not compatible across distributions. Regards, Gregor PS: I haven't been able to keep track of all the discussions on this list lately. If some of these questions have been answered already, I'm sorry. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Qt-jambi-interest mailing list Qt-jambi-interest@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
Re: [Qt-jambi-interest] [RFC - community-port-to-4.6] Add a build dependency on ant-contrib (was Re: Status report on the build system)
Hi, I am not a lawyer, but I'll give it a try. The catch is in the definition of Source Code in the LGPL. Quote: Source code for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Build scripts are part of the source code by this definition. Including ant-contrib.jar would make this file part of the build scripts and therefore part of the Qt Jambi source. Weird, but it says so. A Qt Jambi that is licensed as GPL (again! Nokia relaxed this just a while ago, remember?) is a major step backwards for me and my project(s). Now the much more interesting question is: if ant-contrib is only a build time dependency that is not included in the source code of Qt Jambi, is (a) the distributed source code in violation of the requirement of being the full Source Code according to the LGPL and (b) would this need to change the license of Qt Jambi also? Francis, the FSF gives quite good (and reasonable) advice on the interpretation of their licenses in matters like this. Maybe you could ask them for clarification? A simple email is enough. Regards, Gregor Original-Nachricht Datum: Fri, 16 Oct 2009 14:22:30 +0200 Von: Tom Schindl lis...@bestsolution.at An: Eskil Abrahamsen Blomfeldt eblom...@trolltech.com CC: qt-jambi-interest@trolltech.com Betreff: Re: [Qt-jambi-interest] [RFC - community-port-to-4.6] Add a build dependency on ant-contrib (was Re: Status report on the build system) Hi, How could a build *dependency* affect the license of the resulting binary? Tom Eskil Abrahamsen Blomfeldt schrieb: Francis Galiegue skrev: As I understand it, the community-port-to-4.6 branch is dedicated to the community. I therefore propose that the next-to-come qt-jambi-4.6.x depend on ant-contrib for the build process. Should the consensus turn out to be in favor of integrating it, I stress out the fact that I'll start integrating ant-contrib ONLY when I'm done with the build branch. If you are actually considering physically integrating the ant-contrib.jar-file like before, please bear in mind the consequences for the licensing of Qt Jambi. Ant-contrib is licensed under the Apache license, which I believe is a GPL3-compatible license, but incompatible with LGPL and GPL2. I may be wrong about this, but as far as I could see, this is the case. Any user of Qt Jambi who currently depends on either LGPL or GPL2 will thus not be able to use this branch of Qt Jambi, as the new branch would have to be licensed under GPL version 3. The bottom line is that commercial users of Qt Jambi will not be able to upgrade to the community version and therefore not to Qt 4.6, which I would consider a significant downside. As long as ant-contrib is available on all supported platforms, I don't mind adding a dependency on it for the community version, but I would vote against adding the actual .jar-file to the repository. -- Eskil ___ 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 -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Qt-jambi-interest mailing list Qt-jambi-interest@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
Re: [Qt-jambi-interest] Using non-standard classloader
On Wednesday 26 August 2009, Helge Fredriksen wrote: Hello! Is it possible to use a proprietary class loader with QtJambi? Regards, Helge F. ___ Qt-jambi-interest mailing list Qt-jambi-interest@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest Hi! As far as I understand the issues that I had, it would be possible to use Qt Jambi with proprietary classloaders if Qt Jambi could actually resolve all classes that are derived from QObject. So the trick is to make Qt jambi use a ClassLoader with a classpath that contains all QObject derived classes. The code to obtain a reference to a ClassLoader inside Qt Jambi is quite complex and I am not completely sure if I traced it correctly. But it seems to me that Qt Jambi goes straight to a new instance of java.lang.ClassLoader for its queries, which actually acts as a simple forwarder to the system-wide classloader that is used at application startup. Now, if you look at the documentation for ClassLoader#getSystemClassLoader() in the JDK reference, you will find that you can make the runtime use a non- standard classloader if you set the property java.system.class.loader right at startup. So this is a mechanism that would allow you slip in your custom ClassLoader, but at a cost: virtually every other ClassLoader ends up forwarding its requests to this one, if it can't resolve them itself. I'm not sure if I overlooked something in the Qt Jambi code, though. Still, I hope that this helps. 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
Re: [Qt-jambi-interest] Exceptions and crash after update to Qt Jambi 4.5.x
On Monday 24 August 2009, Eskil Abrahamsen Blomfeldt wrote:
Gregor Mückl wrote:
Caused by: java.lang.ClassNotFoundException:
eu.moonlight3d.ml3d.ui.mainwindow.view.Viewport$ProjectionType
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
... 16 more
After that I get a VM crash. I find it strange that the
NoClassDefFoundError is thrown, although the class is definitely there
and must have been loaded. It must be noted, however, that the class in
question is loaded through a classloader that is created at runtime,
after Qt Jambi has been loaded and initialised through the default system
classloader.
A further indication that this would be the case is that everything works
fine when I start the program from Eclipse, where the contents of the
plugins is (improperly) added to the system classpath at VM startup.
So, could it be that the Jambi internals fail to query the correct class
definition because they are looking for it in the wrong classloader? If
so, is there a workaround for this? I need my own classloader to be able
to load plugins.
The method in your stack trace is attempting to build a meta object for
your class so that its functions and properties can be accessed from C++
applications (e.g. in Qt Jambi Designer.) It will look in the class path
for any class used in the signature of one of the methods. It should of
course not crash if the classes cannot be resolved, this is a bug. I
have made a task to fix this for the next patch release of Qt Jambi.
Meanwhile, could you try annotating the methods that cause trouble with
the QtBlockedSlot annotation, like this:
@QtBlockedSlot
void fooBar(ClassNotOnClassPath cnocp) {
}
I don't know if this is an acceptable work-around to you, but it might
avoid the function call which causes the exception, so it might be worth
a try until the bug has been fixed.
-- Eskil
Hi Eskil!
Thank you for this workaround. However, It only makes the other exceptions
disappear, but not the one on Viewport$ProjectionType which causes the crash.
I added the @QtBlockedSlot annotation to all methods in Viewport (the affected
class) which contains the enum in its signature, but this does not seem to
have any effect on this particular exception, I'm afraid.
ProjectionType is actually an enum that only appears in the signature of a
getter and a setter, following the conventions for Java properties. Could it
be that (a) the runtime tries to map the getter and setter to a Qt property
and because the type cannot be discoverd and (b) this is not prevented by the
annotation because the issue is not about the discovery of slots in the class
at all?
Seeing how Qt Jambi throws exceptions when there are undiscoverable classes
and enums used in subclasses of QWidget (which happens a *lot* in my code), I
would have to add that annotation in hundreds of places in the source code,
which are tedious to find and debug. So I do not think that this workaround
would be actually feasible as a short or medium term solution, even if we
figure out a way to make it work.
Maybe you should simply add an interface to Qt Jambi which allows registration
of custom classloaders for use by the runtime for all of its reflection magic.
This would nicely side-step the issues that we are discussing here. Custom
classloaders are used quite commonly in complex Java projects (like OSGi based
software).
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
[Qt-jambi-interest] Exceptions and crash after update to Qt Jambi 4.5.x
Hi! I tried to update the version of Qt Jambi that I use to 4.5.x, but it looks like some internal changes since 4.4.3_01 give me serious trouble. During startup of my application I get a sequence of exceptions and then a hard crash, probably as a result of the exceptions. This happens with both 4.5.0_01 and 4.5.2_01, but with the latter I get more verbose output. The stack traces that get logged are the following: QtJambi: Exception pending in native code Exception in thread main java.lang.NoClassDefFoundError: eu/moonlight3d/ml3d/ui/mainwindow/view/Viewport at com.trolltech.qt.internal.MetaObjectTools.internalTypeName(Native Method) at com.trolltech.qt.internal.MetaObjectTools.buildMetaData(MetaObjectTools.java:434) at com.trolltech.qt.gui.QWidget.__qt_QWidget_QWidget_WindowFlags(Native Method) at com.trolltech.qt.gui.QWidget.init(QWidget.java:77) at com.trolltech.qt.gui.QWidget.init(QWidget.java:69) at eu.moonlight3d.ml3d.ui.mainwindow.view.ViewWindowSpace.init(Unknown Source) at eu.moonlight3d.ml3d.ui.mainwindow.MainWindow.init(Unknown Source) at eu.moonlight3d.ml3d.ui.mainwindow.MainWindowFactory.createNew(Unknown Source) at eu.moonlight3d.framework.ui.UIManager.getMainWidget(UIManager.java:344) at eu.moonlight3d.framework.ui.ApplicationWindow.init(ApplicationWindow.java:80) at eu.moonlight3d.framework.State.createMainWindow(State.java:367) at eu.moonlight3d.framework.State.runInteractive(State.java:241) at eu.moonlight3d.ml3d.ML3D.main(Unknown Source) Caused by: java.lang.ClassNotFoundException: eu.moonlight3d.ml3d.ui.mainwindow.view.Viewport at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) ... 13 more QtJambi: Exception pending in native code in file 'qtdynamicmetaobject.cpp':116 Exception in thread main java.lang.NoClassDefFoundError: eu/moonlight3d/ml3d/ui/mainwindow/view/Viewport at com.trolltech.qt.internal.MetaObjectTools.internalTypeName(Native Method) at com.trolltech.qt.internal.MetaObjectTools.buildMetaData(MetaObjectTools.java:434) at com.trolltech.qt.gui.QWidget.__qt_QWidget_QWidget_WindowFlags(Native Method) at com.trolltech.qt.gui.QWidget.init(QWidget.java:77) at com.trolltech.qt.gui.QWidget.init(QWidget.java:69) at eu.moonlight3d.ml3d.ui.mainwindow.view.ViewWindowSpace.init(Unknown Source) at eu.moonlight3d.ml3d.ui.mainwindow.MainWindow.init(Unknown Source) at eu.moonlight3d.ml3d.ui.mainwindow.MainWindowFactory.createNew(Unknown Source) at eu.moonlight3d.framework.ui.UIManager.getMainWidget(UIManager.java:344) at eu.moonlight3d.framework.ui.ApplicationWindow.init(ApplicationWindow.java:80) at eu.moonlight3d.framework.State.createMainWindow(State.java:367) at eu.moonlight3d.framework.State.runInteractive(State.java:241) at eu.moonlight3d.ml3d.ML3D.main(Unknown Source) Caused by: java.lang.ClassNotFoundException: eu.moonlight3d.ml3d.ui.mainwindow.view.Viewport at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
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
Re: [Qt-jambi-interest] The Jambi Problem
On Monday 09 March 2009, Mathias wrote: Gentlemen, having followed the recent discussions on the prospects of Qt Jambi in this list pretty closely I cannot help but share my point of view on this. IMHO Trolltech Qt Jambi has had and does have one serious problem. However, this problem is not of a technical kind. Technically Jambi is an extremely valueable addition to the Java world, it's simply the best desktop UI framework available for Java. Swing is a nice try but has never really been used by it's creators/maintainers for anything but small demo apps, and it shows. SWT can match Qt for performance but falls behind in every other dimension (elegance, extensiveness, extensibility...). Trolltech has been developing Qt for many years, lots of software has been written on top of it, it has matured and is well maintained. Using the existing Qt C++ codebase to fill the Java desktop UI framework void was an excellent idea and I think (even though there might still be some bugs here and there) Gunnar, Eskil and the others have done a really good job making it work. Qt Jambi is excellent. The Qt Software people also. These words say it all. The reason that Qt Jambi is facing problems is not a technical one. IMHO Trolltech has done a truly terrible job with Jambi MARKETING. Being a software development company it seems Trolltech has not put enough focus on selecting the right people for its marketing/PR functions. Let me give you three points to support my case: [...] 2. Creating visibility, fostering adoption, seeding a community Three crucial marketing tasks. Three complete fails. Jambi has been released more than 1.5 years ago and I bet more than 98% of Java developers have never heard of it. If you look at java forums, blogs and the ever recurring SWT vs. Swing discussions you will not see people pointing to Qt for rescue. Not because they think Qt is not up for the task. Simply because they don't know about it. What has Trolltech done to create visibility for Jambi? Apart from good old advertising (both on- and off the web) I could think of visiting and speaking at big java events, organize contests, give out prizes for the best Jambi app, recruiting and supporting lamp post projects, embracing the java centric academia, ... whatever. Jambi doesn't even have its own proper website. It has a reference documentation pages. If it does have a reference projects list somewhere I haven't found it. There is no community. As some of you have pointed out, traffic on this list is extremely low for a project with the punch potential of Qt for Java. This is not the fault of Gunnar or Eskil who I think do an excellent job on their end. It's a MARKETING job to reach out to the target group, get them excited and bring them on. Well, I strongly disagree here. Qt Jambi is definitely known to the majority of Java developers whom I talked to in the last year. And these people told me they were interested in taking a closer look, but never found the time. Therefore, my impression is that the markert for Java GUI toolkits is saturated with solutions that are good enough for most applications. Especially SWT is of that kind. And with Eclipse RCP and the huge variety of products already built on top of this platform a lot of professional work is done with the Eclipse RCP (and therefore SWT) as a target. Qt Jambi simply arrived late. This was an uphill battle from the start. 3. Communication. The prime example for the serious lack of professionalism in Trolltech marketing/PR is the press release issued on Feb. 19th (and now featured prominently on second place in the google results for a search for Qt Jambi). The content consists of three main points: - Trolltech will reduce resources dedicated to Jambi. - Jambi will be put under LGPL. - Trolltech will host and help maintain a community-driven Qt Jambi implementation To me this sound like two good news and one bad one. The second point is excellent news! Now, if you had to choose a title for that press release, what would it be? I would think something like Qt Jambi opened up to community or Qt Jambi community to receive more focus or anything else highlighting the positive points. Instead Trolltech decided to go for Qt Software to discontinue Qt Jambi after 4.5 release. To me this reads like bad news. Really bad news. A tomb stone. Over and out. That's it. Done. Whoever in their right mind and interest in seeing Jambi prosper would issue a press release with that title? This is a stab in the back of all the Trolltech developers who have spent many months building the great Qt Java bridge available today. And it's the most effective countermeasure to any effort put into the third content point. It will take an enormous amount of work reverting the damage done by that PR title. The title is directed at the people who have the money, not devs. And it gives them the right message: Qt Jambi as a
Re: [Qt-jambi-interest] Should I start a new project with Qt Jambi?
Hi! On Friday 06 March 2009, Arthur Pemberton wrote: Previous to the discontinuation announcement, i was just starting to work with Java, and so I have become interested in using Qt from Java as I like the toolkit. But given the following, should I really start a new project with Qt Jambi? Let me rephrase this question: Who on this list would be willing to step forward and help maintain Qt Jambi? Well, I don't think that I would be able to find enough time to help out. I have invested considerable effort in porting Moonlight|3D over to Qt Jambi and still think that this UI toolkit is a perfect match. It would be a crying shame to see it rot. Just my 2 cents. 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
Re: [Qt-jambi-interest] Should I start a new project with Qt Jambi?
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 3 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
[Qt-jambi-interest] Making sections of text in a QTextEdit uneditable
Hi! As far as crazy ideas go, this one is probably shooting for the top 10: I want to show the user a text edit control with a fragment of source code. Parts of that fragment are shown only as a convenience to provide context information and should not be altered by the user. So this means that there are about 1 or 2 lines at the start and at the end of the fragment which should not be editable by the user (while the middle section is fully editable). I have thought about separate text labels above and below the editable fragment, but I consider this to be a less elegant solution than having it all in one widget, in which the content would scroll consistently if the fragment gets longer. Is something like this possible at all (without totally reimplementing QTextEdtir, of course)? What trickery would be required to make this work? 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
