Yesterday I've got GNU Classpath 0.20 with Qtopia Core 4.1.1 (that's the new
name for Qt/Embedded 4.1.x) snapshot 20060131 running on an industrial
PDA-like device.
Qt/Embedded Applications need a so called QWS-Server. AFAIK this server is
responsible for placing the windows, getting keyboard input etc. After all,
Qt/Embedded run's directly in the Framebuffer and so there is no X-Windows
Window Manager.
An application can either be called with -qws as command line option
or it can instantiate the QApplication() with a QApplication::GuiServer
argument.
The latter is done if the system property "qtoptions.qws" is set.
The patch would be less invasive if I wouldn't have followed the original
qt-peer programming pattern, e.g. I could directly get the system properties
in the native code. That way only one file would be needed to be patched, no
Java class would need a "private boolean qws" variable etc. But this patch
mimicks the code-path that qt-peer does with the doublebuffer variable.
Once applied and compiled, you can call Qt/Embedded apps like this:
jamvm \
-Dawt.toolkit=gnu.java.awt.peer.qt.QtToolkit \
-Dqtoptions.qws=true \
-classpath /opt/java/examples.zip \
gnu.classpath.examples.awt.Demo
If you have a separate QWS server running:
#include <QtGui/QApplication>
-----------------------------------------------
int main(int argc, char* argv[])
{
QApplication app(argc, argv, QApplication::GuiServer);
app.exec();
return 0;
}
-----------------------------------------------
then you can simply omit the "-Dqtoptions.qws=something".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qws.patch
Type: text/x-diff
Size: 3083 bytes
Desc: not available
Url : http://developer.classpath.org/pipermail/classpath/attachments/20060201/3573e031/qws-0001.bin
