[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ercp-dev] Linux x86 SWT Qt port...

On Wed, Sep 30, 2009 at 10:39 AM, Gorkem Ercan <gercan@xxxxxxx> wrote:
> That is something we will do in the future but for now we
> are updating the native libraries when we refresh the download package. Next
> one is due next week actually.

Thanks for the information, Gorkem. I will look out for it next week. :)

> We use qmake so basically if you call qmake & make on the library folder it
> should compile the native parts the .pro file has the build magic in it.
> Alternatively you can checkout the org.eclipse.ercp.swt.qt.linux.x86 the
> build.xml inside that project has a target called build.lib which will take
> care of it. Note that we depend on Qt 4.5 so it probably won't compile for
> earlier Qt versions. I have also quickly put a wiki page compiled from the
> Nokia internal instructions
> http://wiki.eclipse.org/ERCP/build/HowToBuildeSWTforQt . I still need to
> test the instructions though.

I'll see if I can try these methods when I get home tonight. I have both desktop SWT and eRCP Qt SWT checked out in one workspace so my renaming probably caused the build.xml file method to fail. I'll retry on a fresh workspace and see how that goes.

>But Qt widgets (those
> deriving from QWidget) actually override sizeHint so if you test the
> sizeHint for a widget such as Label with a text you should get a value
> different from 0. QWidget by itself does not have a size.

I guess a QMainWindow doesn't have a size? That's what I was trying it for, on an SWT Shell. Thanks for the tip though, I'll take a look see later and maybe try my code on a QLabel.

> This is progress actually. Is SWT JNI generator configurable so that we can
> mix manual parts and generated code together? We already know that, we will
> have some code (like the event filter) that needs to be coded.

In SWT there is the OS.java file which defines the native methods (it can be named something else, for example, there's also XPCOM.java and Gdip.java) and a corresponding os.c file (or os.cpp in the Qt case I've been hacking on, or xpcom.cpp and gdip.cpp in the other examples above). For handwritten parts, those are typically written in an os_custom.c file though this naming scheme is not actually enforced from what I know.

So yes, you can mix and match. Then at compile time you can just link your os.o and os_custom.o (and whatever else) into a single libswt-pi-qt-XXXX.so file. Does that help clarify things?

Disclaimer: I am not an SWT committer, I've just been in contact with one and am only speaking from experience based on what I've started last Thursday/Friday. :P

>> I would be interested in helping generalize the Qt port for usage on x86
>> Linux systems in addition to swapping out some/most of the handwritten JNI
>> code to generated code by the SWT generator.
> That is something we are interested in as well. I can try to help as much as
> I can. Would you like open a bug report to follow the progress.

Great. I will open a bug when I get a chance maybe today or tomorrow. Once that's done I will also email the list to let other people know.


Remy Suen
Rational Team Concert Developer, Eclipse Platform/UI Committer
IBM Ottawa