Re: [Qt-jambi-interest] Request for contributors

2010-01-12 Thread Adam Batkin
 Is there any willing to contribute? We should try to compile a list of
 what has to be done to get the first community release on Qt 4.6 going.

 On the top of my head:

1. Get the development packages up and running on the main Linux
   distros in addition to a tar.gz archive.
2. Get a Windows 7 release packaged.
3. Hopefully get someone on with a Mac to contribute with a release here.
4. Get the javadoc working again (I've managed to compile it, but
   it's lot of stuff missing which is found in the Qt doc).
5. Get the examples working and bundle them in the various packages.
6. Get in control of the Qt Jambi generator.

Hi!

I would like to join in the fun.

I can help contribute to a Mac release. My particular interest is in 
making the Generator work better, so it can be run independently. Though 
it sounds like Francis may have already started working on that, which 
is great.

I'm on vacation at the moment, so things are a little crazy but as a 
start, I'll try to take a look at what is involved in getting a Mac 
release going.

-Adam Batkin

___
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 JNI Integration

2008-07-08 Thread Adam Batkin
Initializing my QApplication first does in fact solve the problem. I'm not sure 
how I 
missed that (*smacks forehead*). Mostly because I was doing this in a 4-line 
test harness 
and not an actual program (which would of course have initialized QT since 
using QT Jambi 
is the whole point of this exercise!)

You mentioned being able to move some code around to fix this particular issue 
but that 
wouldn't be a general fix; I would say that even better (if possible) would be 
to warn 
that you have to initialize QT first. I mention this because some classes do in 
fact print 
warnings if you try to use them without initializing QT first (for example when 
I was 
testing and I created an empty QPixmap, it yelled at me). In other words, what 
I did was 
wrong, but it would have been helpful to get a warning or something (since JVM 
crashes 
aren't the easiest things to debug)

Anyway, thanks for the help!

-Adam Batkin

Eskil Abrahamsen Blomfeldt wrote:
 Adam Batkin wrote:
 Anyway, I've now set out to write my own JNI code to do what I want, 
 instead of using the Jambi Generator. Everything was working nicely 
 until trying to transfer a QImage from C++ to a Java/Jambi QImage. 
 Back in February, Gunnar suggested stealing some logic from the 
 generated Jambi code, in particular QPixmap::toImage():
  jobject jimg =
  qtjambi_from_object(env,
  image,
  QImage,
  com/trolltech/qt/gui/,
  true);

 This works -- almost. I get back a valid Java QImage object 
 (System.err.println(image) prints something like 
 [EMAIL PROTECTED]) but when I try to do anything with 
 it (like call image.width()), the JVM crashes.
   
 
 Hi, Adam.
 
 Has Qt Jambi been properly initialized at this point? I.e. you need to 
 initialize each of the libraries you use before they can be used, 
 otherwise Qt Jambi won't know e.g. that it has to copy the QImage into a 
 new object before linking it into a Java object, and you will get a Java 
 object with a pointer into the stack. The initialization of Qt Jambi 
 libraries is done the first time a class from the library is loaded by 
 the virtual machine. In your case, I think you are calling the 
 conversion code before loading any Jambi GUI classes. The conversion 
 code itself will resolve and load the QImage class, thus initializing 
 the GUI library, but unfortunately this is too late for the first 
 conversion, and the first Java object you retrieve will contain a 
 pointer to the object you allocated on stack. This is why you can fix 
 the problem by manually loading the class using the resolveClass() call, 
 or by calling another method which causes the library to be initialized.
 
 We can easily fix this particular problem by moving some code around, 
 and I'll make a suggestion to do so. However, I'm not convinced that 
 we'll be able to fix all related issues, so I recommend you initialize 
 the library prior to using Qt Jambi. For instance, we don't support 
 having Qt Jambi application that have not called 
 QApplication.initialize() or QCoreApplication.initialize() (the former 
 in your case.) If you call QApplication.initialize() in the beginning of 
 your application, this should cause the GUI library to be initialized.
 
 -- Eskil
 
 

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


[Qt-jambi-interest] Jambi and JNI Integration

2008-07-07 Thread Adam Batkin
Hi,

I had posted a while back about wrapping the Poppler PDF library using QT 
Jambi, so that 
it could be used from Java. Although Poppler uses C++ Namespaces, I wrapped the 
3 or 4 
functions that I wanted in my own class, used the Jambi Generator and 
everything was 
great. At the time, it was mentioned that better Namespace support was coming 
with 4.4 so 
I figured I would wait until then to properly wrap the entire library 
(without having to 
also write my own C++ classes to wrap ever Poppler class that I wanted).

Anyway, I've now set out to write my own JNI code to do what I want, instead of 
using the 
Jambi Generator. Everything was working nicely until trying to transfer a 
QImage from C++ 
to a Java/Jambi QImage. Back in February, Gunnar suggested stealing some logic 
from the 
generated Jambi code, in particular QPixmap::toImage():
 jobject jimg =
 qtjambi_from_object(env,
 image,
 QImage,
 com/trolltech/qt/gui/,
 true);

This works -- almost. I get back a valid Java QImage object 
(System.err.println(image) 
prints something like [EMAIL PROTECTED]) but when I try to do anything 
with it (like call image.width()), the JVM crashes.

Now, the image object (QImage) that I'm getting back is on the stack (hence the 
address-of 
). If I make a copy of it on the heap (QImage *copy = new QImage(image)) and 
then pass 
that copy pointer directly to the qtjambi_from_object function (i.e. no 
address-of 
operator  since it is naturally a pointer) then it doesn't crash -- so long as 
I don't 
delete the copy pointer (which makes that a big memory leak). (creating a copy, 
not 
deleting it, but using the original image in qtjambi_from_object DOES crash 
the JVM (weird)).

Something else that is weird (though this may be a red-herring, i.e. luck) if I 
construct 
more than 1 QImage (in Java, i.e. QImage i1 = page.renderToImage(); QImage i2 = 
page.renderToImage();) calling i1.width() crashes the JVM but i2.width() does 
not! (i1 
being the first QImage created this way) In fact, just the line new 
QPixmap().toImage() 
seems to prevent a crash. Through some trial and error, I tried inlining a 
bunch of the 
code from qtjambi_from_object and it seems that just calling the following one 
line before 
calling qtjambi_from_object prevents a crash:
resolveClass(env, className, packageName);

Thoughts?

Thanks,

-Adam Batkin

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