Community
Participate
Working Groups
Hi, I am opening this bug to discuss and track the steps for adding a new platform to SWT which is Qt. I will CC all people that I previously spoke to about his donation. If you feel that you are on this bug as CC as an error, feel free to remove yourself. SWT/Qt is like the platform Win32/GTK/Cocoa/Carbon etc. a new Toolkit that the SWT API is implemented against. Unlike the existing platforms which usually only exist on one OS, Qt is available on multiple operating systems namely Win32 / Mac OS X / Linux. Compeople AG has developed a close to feature complete implementation of SWT/Qt and is willing to give that to the SWT team. At the same time (we/compeople) are willing to continue to maintain this code in the SWT project. Qt is originally from trolltech now owned by Nokia. There is an existing eSWT implementation for embedded devices against Qt which exists in parallel to this effort. Qt is licensed under a commercial license / GPL and LGPL and is written in C++. Since Java cannot link easily against C++ directly we choose to use QtJambi also from Nokia which is a Java layer that links against the Qt library and offers a very sophisticated Java API. QtJambi is also licensed under LGPL and was discontinued and released into the community about one year ago. SWT/Qt is based on Qt 4.5 and QtJambi 4.5. Qt is also now available as 4.6. (QtJambi is under development by the community) SWT in eclipse.org is structured into several components and each of them contain the various platform implementations, all under EPL. SWT/Qt adds one implementation for all the various components that works on all platforms supported by Qt. ------ So the project structure of SWT looks like this: org.eclipse.swt Eclipse SWT cairo carbon ... qt win32 Eclipse SWT Browser carbon cocoa ... qt etc. All this is EPL code. ----- additional there is an extra project for each OS that Qt supports *swt.qt.win32 *swt.qt.osx.x86 *swt.qt.linux.x86_64 Each contains the QtJambi lib (which is the same for all Operation systems) and the Operation System specific Qt lib. The code in the last 3 projects is LGPL code. QtJambi contains a Loader that loads the Qt libs and we had to modify it to make it work under OSGi. We can sure can open source that little change under LGPL. A special use case is Operating System like Kubuntu where Qt already exists. If it is exactly the Qt 4.5 version you can remove technically remove the Qt pieces for the linux project and SWT/Qt will link against the lib in the Operation System. ------- The goal of compeople is to provide and supply a SWT/Qt platform that runs on all three platform (Windows, Mac, Linux) (with a focus on Windows). We talked to the SWT team (Bogdan, Silenio) and they are very open to take the code (the EPL part), host it in the Eclipse SWT project and make us committers for that part of SWT. The SWT team also expressed their idea of removing QtJambi and replacing it with some kind of generated or written layer. While we are not against this, we dont have the ressources and the knowhow to do this ourselves. (And we believe for several technical reasons that it is far from simply in this specific case) The tricky part of putting this at eclipse.org is the LGPL piece. I want an easy to use experience for users to use SWT/Qt (kind of out-of-the-box). I DONT want a wiki page like: download this, compile that, stuff it together here and then maybe....... ------- So this is where we are now. Bogdan offered to open a CQ for submitting the code base and I guess was only hold up by Helios release stress and now e4 1.0 stress. But in any event, parally to any code being checked, I believe we can start a discussion on what is possible, what is not possible and how to proceed. Any thoughts and ideas are welcome. christian campo (now adding a million people in CC :-) )
Hi, I want to point out, as this work should be pretty interesting for this project, that I have been working on removing dependency to Qt Git repository layout, hence enabling an user to build against system Qt her copy of Qt Jambi. This should be mature by the time Qt Jambi 4.7 is out. If you need something special to Jambi, please contact to me(or use qt jambi mailing list) and I’ll arrange it somehow. We are struggling to get Jambi up to date and stable, but there is always something we don’t spot.
(In reply to comment #1) > Hi, > > I want to point out, as this work should be pretty interesting for this > project, that I have been working on removing dependency to Qt Git repository > layout, hence enabling an user to build against system Qt her copy of Qt Jambi. > This should be mature by the time Qt Jambi 4.7 is out. > > If you need something special to Jambi, please contact to me(or use qt jambi > mailing list) and I’ll arrange it somehow. We are struggling to get Jambi up to > date and stable, but there is always something we don’t spot. Actually we tried to run SWT/Qt against Qt Jambi 4.6 about 2 weeks ago and it didnt work out of the box. We had a JVM crash. But we didnt spend the time to dig deeper. That might as well be something in our code. But we are interested to hear when the time is right to try 4.6. QtJambi since 4.6. for Qt is becoming more and more popular i.e. in Kubuntu....
Hello, I really like the idea as I am a heavy kde user and I very dislike the gtk apps running within KDE, not to mention wine! Do you have any timeline in mind when we can expect a working SWT at least for KDE if not for other platforms. On the other side, I appreciate that your top priority to get it running on windows/qt, however I do believe that the biggest added value will be ability to run on KDE which has no SWT binding to the native windowing toolkit, hence true OS L&F. Regards, Hasan Ceylan
(In reply to comment #3) > Hello, > > I really like the idea as I am a heavy kde user and I very dislike the gtk apps > running within KDE, not to mention wine! > > Do you have any timeline in mind when we can expect a working SWT at least for > KDE if not for other platforms. > > On the other side, I appreciate that your top priority to get it running on > windows/qt, however I do believe that the biggest added value will be ability > to run on KDE which has no SWT binding to the native windowing toolkit, hence > true OS L&F. > > Regards, > Hasan Ceylan I agree that it is a big advantage to have a native look on KDE :-). However Qt also means CSS styling support on all platforms well beyond any CSS styling of other implementations. - christian
How about the timeline? Can we expect anything for the 3.6.1 / 3.6.2 or 3.7 / 4.0 (oh no!) milestones..? :)
(In reply to comment #4) > (In reply to comment #3) > > Hello, > > > > I really like the idea as I am a heavy kde user and I very dislike the gtk apps > > running within KDE, not to mention wine! > > > > Do you have any timeline in mind when we can expect a working SWT at least for > > KDE if not for other platforms. > > > > On the other side, I appreciate that your top priority to get it running on > > windows/qt, however I do believe that the biggest added value will be ability > > to run on KDE which has no SWT binding to the native windowing toolkit, hence > > true OS L&F. > > > > Regards, > > Hasan Ceylan > > I agree that it is a big advantage to have a native look on KDE :-). However Qt > also means CSS styling support on all platforms well beyond any CSS styling of > other implementations. > > - christian Please do remember that Qt can use KDE styling, so Qt support for linux would get KDE styles for applications and with certain Qt plugin GTK styles to Qt.
Dear all, This is indeed a great initiative. Though I don't know SWT very well, I welcome any attempt to try to merge the two worlds, hopefully bringing the open source java communities closer. Don't have much more to say right now about this, but it will be interesting to see more of this. The FOSS world really needs a high-level language challenger to the microsoft .net framework. Helge Fredriksen
One thought: Any ideas around Qt Quick support in SWT/Qt Java? This could bring us to a really new level! Regards, Helge Fredriksen
(In reply to comment #8) > One thought: Any ideas around Qt Quick support in SWT/Qt Java? This could bring > us to a really new level! > > Regards, > Helge Fredriksen One way to address declarative UIs would be something that is SWT based like XWT. Qt Quick requires Qt 4.7 and as you saw in my description SWT/Qt is currently only 4.5. So we have to wait until Qt Jambi 4.7 comes around. The other thing is that its not impossible but certainly a challenge to create SWT Objects on the fly based on Qt Objects. The normal process is that you create an SWT Button, that triggers the creating of the Qt equivalent and the SWT Button holds a reference to the Qt Object. With Qt Quick you would create a series of Qt Object and only then can you figure out what SWT Objects you would need to create. That sounds tricky at least if you like to address the individual objects from the SWT API. If you like to treat an QML Object just as a container, that be much easier.
A CQ was added for the SWT/Qt contribution by the SWT team. We are going to add the code in the next days. Its CQ 4301 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=4301
I am worried about the Jambi dependency of the implementation. Jambi is not readily available on any platform (not even KDE) and it is licensed under LGPL. AFAIK it is not possible to distribute LGPL licensed material from Eclipse, if that is still the case, would not this just lead to a very bad user experience?
(In reply to comment #11) > I am worried about the Jambi dependency of the implementation. Jambi is not > readily available on any platform (not even KDE) and it is licensed under LGPL. > AFAIK it is not possible to distribute LGPL licensed material from Eclipse, if > that is still the case, would not this just lead to a very bad user experience? I agree that we dont want a bad user experience. I already lay that out in the description. The implementation is intended not only for Linux but also for Mac OS X and Windows. So what is true for Jambi (that it is not there and that it is LGPL) is also true for Qt itself. How about Nokia licensing Qt and Jambi under EPL :-) And thats the reason I copied people like Mike, Janet and Wayne etc. on this bug. I talked to them before and ultimatly Mike has to make a decision if there is an exception to this rule for distributing LGPL code OR somebody has to show us a way how this bug can lead to a GOOD user experience. (that we all want) If you are saying we should remove the dependency to Jambi then that we would mean (as pointed out in the description) that this bug becomes more or less pointless and somebody has to try to redo all the stuff without using Jambi.
Of course there are legal issues that will need to be dealt with. However, unless I am missing something, I don't see any committers from SWT racing to embrace this contribution. Does SWT want to support Qt or not?
I think we've *always* wanted to embrace Qt, but it just never made it high enough up our platform requirement list for us to be able to invest in it. The fact that there are others in the community who are willing to do this now is ABSOLUTELY F'ING GREAT(!), we're all for it, and we think it will be awesome for both the SWT and Qt communities. For us, the end result will be a new platform and new SWT committers, how could we *not* want this?
For all people who dont monitor the CQ, it has been approved by IP. So the code is approved to be checked into CVS. Next steps: - bring the code actually into CVS - commit rights so we can work on it - talks about builds and downloads of a SWT version that contains QtJambi and Qt. We actually now have built in the meantime 3 jar files that contain a full SWT .jar with QtJambi and Qt for Windows, Mac, Linux. So it contains EPL and LGPL code obviously (in two bundles). Could we host such a download at eclipse.org ? Where would we put it ? Any advice or guidance or steps forward are appreciated..... - christian
Can you send us (or post here) a list of the people who have worked on the code that you are contributing and we will nominate them as committers on the SWT project. This process will take approx. 10 days or so. Once you have commit rights, we can decide on what new fragments are needed (ex. org.eclipse.swt.qt.win32.x86 etc) and get the code in. We will then figure out how to add the Qt port to our nightly build process.
People that worked on this code contribution that should be acknowledged here are: - juergen.becker@compeople.de (major contributor) - stefan.liebig@compeople.de - christian.campo@compeople.de - stephan.mann@compeople.de - maddalena.borschberg@compeople.de Stephan and Maddalena are currently working on other projects, so I'd like to propose to have Juergen, Stefan and myself as SWT committer for the Qt platform. Stefan is already committer for p2, equinox, Riena and eclipse.incubator. I am committer for Riena (project lead), e4 and the technology.example project. Juergen Becker is currently no committer in any Eclipse project. He is working for compeople so it takes a few extra steps for him to become committer but since we have done that a number of times (adding new committers) that should be an easy task once he is voted.
Since having a proper build available at eclipse.org as download will take some more time, we decided to host an alpha version on our own website and post a blog post describing how to run it. http://www.compeople.eu/blog/?p=307 It does not include source code since that will be hosted at eclipse.org but allows you to run Eclipse 3.5. on all three platforms (Windows, Mac, Linux) based on Qt and play around with CSS styling (using an included editor "Advanced Styler" with some pre-setup CSS stylesheets. Just to give everyone a first impression what we are going for....Still the thing has bugs and performance issues :-) and not implemented functionality.
So we are making progress on this contribution. The download associated with the blogpost saw roughly 140 direct downloads for the SWT/Qt components. Interestingly quite equally split between all three platforms Windows, Mac and Linux. Also interestingly I found that most people would just go for one specific platform. (as far I could tell) Juergen, Stefan and me are listed as SWT committers now. There is still a userid and password missing for Juergen but that will probably come very soon. So first of all @Gheorghe, @Silenio, I hope we agree that we (Juergen, Stefan, myself) will checkin the code from the CQ 4301 NOW into the CVS at eclipse.org under the platform "qt" ??? I'd like to hear a big YES on this before we actually do it. Second we need to move forward on the LGPL thing. There are QtJambi and Qt (that are both LGPL) that needs to be somewhere at eclipse.org so we can compile our code against them and we need to have them to build downloads so people get complete platforms to testdrive them. Pretty much what we did in the blogpost (offer complete platforms as download now from eclipse.org) is I believe the next goal. Have a build process, build it as part of SWT and make it available from eclipse.org. @Mike M., @Mike W, @Wayne, @Janet or anyone else: What do we do ? What are next steps to get that in ? Should we open a CQ now for QtJambi and Qt ? Both togehter or individual CQs ? @Silenio, @Gheorghe any thoughts on this ?
1. Go ahead and release the SWT Qt code. (Big Yes!) 2. In order to host QtJambi/Qt at eclipse.org, it needs to be hosted as a third party bundle as part of Orbit. We should not host the QtJambi/Qt jars inside of the SWT bundles; rather the SWT Qt bundle should have a dependency on the Orbit bundles. For this we need more CQ's! We looked at the contents of the SWT Qt fragment and saw 2 Qt jars: 1) qtjambi-4.5.2_01_osgipatch.jar -> this seems to be common to all drops; one CQ should do it. 2) qtjambi-{arch}-4.5.2_01.jar -> this one contains platform specific files. We probably need a separate CQ for each one of these. Since you know which platforms you want to offer, it's best if you guys open these CQs. Once these CQs get cleared, we can add the jars to Orbit and then look at getting builds going.
For 1) I have just checked in the code from the CQ into CVS. We will continue to add stuff, like the changes we did since the CQ was submitted, we add the individual .classpath files and so on. For 2) Since QtJambi and Qt should now go into orbit, we will do some local changes to fit with that (naming etc.). So I will submit CQs hopefully in this week and we see how that goes. - christian
(In reply to comment #19) ... > > Second we need to move forward on the LGPL thing. There are QtJambi and Qt > (that are both LGPL) that needs to be somewhere at eclipse.org so we can > compile our code against them and we need to have them to build downloads so > people get complete platforms to testdrive them. Pretty much what we did in the > blogpost (offer complete platforms as download now from eclipse.org) is I > believe the next goal. Have a build process, build it as part of SWT and make > it available from eclipse.org. > > @Mike M., @Mike W, @Wayne, @Janet or anyone else: What do we do ? What are next > steps to get that in ? Should we open a CQ now for QtJambi and Qt ? Both > togehter or individual CQs ? @Silenio, @Gheorghe any thoughts on this ? If you need to distribute Qt and/or QtJambi, then you'll need CQs for them before they find their way into the repository or any build. I am concerned that both seem to be under the LGPL only; AFAIK, we cannot distribute anything under this license. The build server is a bit of a gray area. You can, in general, include libraries that cannot otherwise be distributed from eclipse.org on the build server for use during the build.
Good point which I believe I am trying to make clear for some time now. I'd like to distribute a SWT/Qt version for all three platforms Windows, Mac and Linux. Qt sometimes exists on some Linux platforms. QtJambi (the Java to Qt binding) is even less likely to exist on a Linux platform. On Windows and Mac its pretty obvious that it does not exist as part of the OS. So good that you made this comment, the bad thing is that I checked the EPL code in to the CVS this morning and now you saying that I am entering a "No-Go" zone..... :-( I think its time for @Mike M. to make a decision or tell me whether we can move forward here and get an allowance to distribute downloadable bundles from eclipse.org that contain LGPL code or not ? If not what can are you suggesting ??? Github ? I am a little frustrated but maybe thats the part of the journey. Now that the CQ is checked, I am committer of SWT, the SWT part of Qt is in CVS, now half way through this process you tell that I can not get what I layout out in my first description of this bug report ? Thats a bummer. What do we do ? (In reply to comment #22) > (In reply to comment #19) > ... > > > > Second we need to move forward on the LGPL thing. There are QtJambi and Qt > > (that are both LGPL) that needs to be somewhere at eclipse.org so we can > > compile our code against them and we need to have them to build downloads so > > people get complete platforms to testdrive them. Pretty much what we did in the > > blogpost (offer complete platforms as download now from eclipse.org) is I > > believe the next goal. Have a build process, build it as part of SWT and make > > it available from eclipse.org. > > > > @Mike M., @Mike W, @Wayne, @Janet or anyone else: What do we do ? What are next > > steps to get that in ? Should we open a CQ now for QtJambi and Qt ? Both > > togehter or individual CQs ? @Silenio, @Gheorghe any thoughts on this ? > > If you need to distribute Qt and/or QtJambi, then you'll need CQs for them > before they find their way into the repository or any build. I am concerned > that both seem to be under the LGPL only; AFAIK, we cannot distribute anything > under this license. > > The build server is a bit of a gray area. You can, in general, include > libraries that cannot otherwise be distributed from eclipse.org on the build > server for use during the build.
FWIW there are Linux platforms where both Qt and QtJambi exist as part of the OS (e.g. Ark Linux), so it would definitely be good to have the option to use system versions instead of having to use bundled copies (of course having the bundled copies option available is good too, for the majority of OSes).
We need to do a little change in the Loader of QtJambi to work in OSGi environments. - christian (In reply to comment #24) > FWIW there are Linux platforms where both Qt and QtJambi exist as part of the > OS (e.g. Ark Linux), so it would definitely be good to have the option to use > system versions instead of having to use bundled copies (of course having the > bundled copies option available is good too, for the majority of OSes).
(In reply to comment #23) > I am a little frustrated but maybe thats the part of the journey. Now that the > CQ is checked, I am committer of SWT, the SWT part of Qt is in CVS, now half > way through this process you tell that I can not get what I layout out in my > first description of this bug report ? In my defense, I cannot possibly monitor all bug traffic on all projects. We'll need some EMO(ED) input here. I'll make sure that Mike is informed of the issue.
(In reply to comment #22) > (In reply to comment #19) > ... > > > > Second we need to move forward on the LGPL thing. There are QtJambi and Qt > > (that are both LGPL) that needs to be somewhere at eclipse.org so we can > > compile our code against them and we need to have them to build downloads so > > people get complete platforms to testdrive them. Pretty much what we did in the > > blogpost (offer complete platforms as download now from eclipse.org) is I > > believe the next goal. Have a build process, build it as part of SWT and make > > it available from eclipse.org. > > > > @Mike M., @Mike W, @Wayne, @Janet or anyone else: What do we do ? What are next > > steps to get that in ? Should we open a CQ now for QtJambi and Qt ? Both > > togehter or individual CQs ? @Silenio, @Gheorghe any thoughts on this ? > > If you need to distribute Qt and/or QtJambi, then you'll need CQs for them > before they find their way into the repository or any build. I am concerned > that both seem to be under the LGPL only; AFAIK, we cannot distribute anything > under this license. > > The build server is a bit of a gray area. You can, in general, include > libraries that cannot otherwise be distributed from eclipse.org on the build > server for use during the build. Gheorghe seemed to think the LGPL stuff would be okay in Orbit, according to comment #20. Is that not the case?
First of all you are doing a great job !! So I am not finger pointing but just express my frustration. I CCed you and Mike on this bug with intention. Mike and McQ posted something here so (I hope) they read the description. I also talked to many people face 2 face (including Boris, Mike, Janet, Gheorghe).....So yes please bring this forward and let us know which way to follow and how this can work. We got 150 people around the world interested in download this just over one weekend. So its a niche, but its not an empty one. (In reply to comment #26) > (In reply to comment #23) > > I am a little frustrated but maybe thats the part of the journey. Now that the > > CQ is checked, I am committer of SWT, the SWT part of Qt is in CVS, now half > > way through this process you tell that I can not get what I layout out in my > > first description of this bug report ? > > In my defense, I cannot possibly monitor all bug traffic on all projects. > > We'll need some EMO(ED) input here. I'll make sure that Mike is informed of the > issue.
(In reply to comment #23) > On Windows and Mac its pretty obvious that it does not exist as part of the OS. > So good that you made this comment, the bad thing is that I checked the EPL > code in to the CVS this morning and now you saying that I am entering a "No-Go" > zone..... :-( We can reasonably assume that Qt is on a Linux distribution, right? At least we can reasonably assume that somebody who wants to use a Qt version of Eclipse can reasonably install the required Qt support, right? Can we make similar assumptions for Windows and Mac? Frankly, I'm not sure why I'd select an Eclipse-based product for Windows/Qt over a "native" version. We may be able to get away with an "exempt pre-req" label for Qt on the basis that it is expected to be on the user's workstation. Again, can we can make the argument that a user that explicitly selects a Windows/Qt version probably knows what they're doing and has installed, or can install Qt? I currently see two options for QtJambi: first, we can pursue getting the project to dual-license the code; second, we can push for an exception to allow the LGPL code to be distributed through Orbit. Frankly, I think that the first option is our best hope. I guess the third option is to generate the bindings as suggested by Bogdan and Silenio.
(In reply to comment #27) > Gheorghe seemed to think the LGPL stuff would be okay in Orbit, according to > comment #20. Is that not the case? Unfortunately, our IP policy currently restricts us from distributing LGPL code.
> I currently see two options for QtJambi: first, we can pursue getting the > project to dual-license the code; second, we can push for an exception to allow > the LGPL code to be distributed through Orbit. Frankly, I think that the first > option is our best hope. > > I guess the third option is to generate the bindings as suggested by Bogdan and > Silenio. As Jambi developer, I don't think that the community can do anything about dual licencing of the Jambi, I doubt that Nokia has given ownership the code of Jambi to the community, just relicensed it and stopped contributing to it. So pledges about this needs to go through Nokia too. Myself, I don't really like about this idea, having two licences when you don't have any lawyer you can concult when something ugly happens isn't going to help. I won't oppose if we're allowed and others don't oppose it, though.
(In reply to comment #31) > > I currently see two options for QtJambi: first, we can pursue getting the > > project to dual-license the code; second, we can push for an exception to allow > > the LGPL code to be distributed through Orbit. Frankly, I think that the first > > option is our best hope. > > > > I guess the third option is to generate the bindings as suggested by Bogdan and > > Silenio. > > As Jambi developer, I don't think that the community can do anything about dual > licencing of the Jambi, I doubt that Nokia has given ownership the code of > Jambi to the community, just relicensed it and stopped contributing to it. > > So pledges about this needs to go through Nokia too. Myself, I don't really > like about this idea, having two licences when you don't have any lawyer you > can concult when something ugly happens isn't going to help. I won't oppose if > we're allowed and others don't oppose it, though. No sure what you are saying. Qt has three licenses (GPL, LGPL and a commercial license). Do you think that is a legal problem when something ugly happens ? (Something ugly is always a problem BTW) I dont think LGPL is any better or less a problem than EPL. But thats just my opinion.
> > No sure what you are saying. Qt has three licenses (GPL, LGPL and a commercial > license). Do you think that is a legal problem when something ugly happens ? > (Something ugly is always a problem BTW) > > I dont think LGPL is any better or less a problem than EPL. But thats just my > opinion. I meant that I don't really know, whether it'd cause problems, and when. I'm totally clueless when it comes to multi-licencing. With current model I'm pretty much putting everything to Nokia/trolls, they have same combo and they are the library Jambi is using... And it is their code originally. So: You need to contact to Nokia if you want to see this licencing happening, community doesn't seem to be able to do this kind of change.
It might be interesting to observe what they are doing with Symbian which EPLed and uses Qt in the up coming releases if I'm not completely mistaken so they somehow have to solve the LGPL/EPL issue themselves.
(In reply to comment #34) > It might be interesting to observe what they are doing with Symbian which EPLed > and uses Qt in the up coming releases if I'm not completely mistaken so they > somehow have to solve the LGPL/EPL issue themselves. That's an interesting observation, Tom. Christian, please open separate CQs for Qt and QtJambi. I'll work with the IP Team to see if we can get the QtJambi stuff dual-licensed. I'm a little surprised by the size of QtJambi. It looks huge for a "binding". Further inspection leads me to believe that the download of QtJambi contains all of Qt as well. Does that imply that the coupling between the two is super-tight? i.e. very version-specific coupling? Does a particular version of QtJambi require a very specific version of Qt to function?
Wayne, Ok so we move on with opening CQs for QtJambi and for the Qt versions for the various platforms assuming that they are hosted maybe in Orbit (not in SWT). QtJambi contains handwritten code but to some extend it is also generated from and for a specific Qt version. So QtJambi contains a shadow object for every Qt object. Its pretty sophisticated, so that you can subclass QtJambi classes (ie QButton) and actually overwriting methods that are actually implemented in the C++ part of the code. Thats why it is 2.6 MB. That the qtjambi-4.5.2_01_osgipatch.jar. There is also the qtjambi-win32-msvc2005-4.5.2_01.jar which mostly contains the Dlls wrapped in a .jar file. They are unpacked at runtime and this file is like 15.8 MB (zipped) or 31 MB (unzipped) because it contains also the Webkit Browser (9.5 MB unzipped) but also the GUI has some large DLLs. (In reply to comment #35) > (In reply to comment #34) > > It might be interesting to observe what they are doing with Symbian which EPLed > > and uses Qt in the up coming releases if I'm not completely mistaken so they > > somehow have to solve the LGPL/EPL issue themselves. > > That's an interesting observation, Tom. > > Christian, please open separate CQs for Qt and QtJambi. I'll work with the IP > Team to see if we can get the QtJambi stuff dual-licensed. > > I'm a little surprised by the size of QtJambi. It looks huge for a "binding". > Further inspection leads me to believe that the download of QtJambi contains > all of Qt as well. Does that imply that the coupling between the two is > super-tight? i.e. very version-specific coupling? Does a particular version of > QtJambi require a very specific version of Qt to function?
(In reply to comment #35) > I'm a little surprised by the size of QtJambi. It looks huge for a "binding". > Further inspection leads me to believe that the download of QtJambi contains > all of Qt as well. Does that imply that the coupling between the two is > super-tight? i.e. very version-specific coupling? Does a particular version of > QtJambi require a very specific version of Qt to function? Jambi needs Qt libraries compiled specifically for Jambi use. This is also explained on [1].Basically the QT_JAMBI_BUILD precompiler flag changes the behavior of Qt on several places(event handler, QObject) for Jambi. [1] http://doc.trolltech.com/qtjambi-4.5.2_01/com/trolltech/qt/qtjambi-installation.html#building-qt-jambi
(In reply to comment #37) > (In reply to comment #35) > > I'm a little surprised by the size of QtJambi. It looks huge for a "binding". > > Further inspection leads me to believe that the download of QtJambi contains > > all of Qt as well. Does that imply that the coupling between the two is > > super-tight? i.e. very version-specific coupling? Does a particular version of > > QtJambi require a very specific version of Qt to function? > > Jambi needs Qt libraries compiled specifically for Jambi use. This is also > explained on [1].Basically the QT_JAMBI_BUILD precompiler flag changes the > behavior of Qt on several places(event handler, QObject) for Jambi. > > [1] > http://doc.trolltech.com/qtjambi-4.5.2_01/com/trolltech/qt/qtjambi-installation.html#building-qt-jambi Atleast 4.6 version of Jambi does not need it, it works perfectly fine with system Qt. I'm sorry, but there is no proper documentation written, we are in need of documentation writers...
(In reply to comment #37) > Jambi needs Qt libraries compiled specifically for Jambi use. This is also > explained on [1].Basically the QT_JAMBI_BUILD precompiler flag changes the > behavior of Qt on several places(event handler, QObject) for Jambi. So... regardless of whether or not I already have Qt installed on my workstation, SWT/Qt will have to include its own version?
(In reply to comment #39) > (In reply to comment #37) > > Jambi needs Qt libraries compiled specifically for Jambi use. This is also > > explained on [1].Basically the QT_JAMBI_BUILD precompiler flag changes the > > behavior of Qt on several places(event handler, QObject) for Jambi. > > So... regardless of whether or not I already have Qt installed on my > workstation, SWT/Qt will have to include its own version? Gorkem has obviously more knowledge on this that I have. For an ultimate answer I have to ask my collegues who did this part. (so I can answer that maybe tomorrow or so) I am pretty sure though that I got it to run on a Kubuntu system. I removed the Qt libs from the QtJambi thing and then the Eclipse IDE through SWT -> QtJambi would then bind and find the already installed Qt libs from the OS. And that would work. It was only necessary that QtJambi and Qt had the same version number. But I can investigate that. On our blog post somebody noted that he (Carsten Pfeiffer July 30, 2010 at 14:11 http://www.compeople.eu/blog/?p=307) removed all .so files and could even run the QtJambi version (4.5.2) against Qt 4.6.3. Still the question remains whether we like to distribute a puzzle (get this here, this there, and that one here) or ONE piece of solid software that works. (I know what I want to deliver and I would expect to consume.) Maybe we can get away with a warning when downloading (as some downloads have warnings). "Attention dangerous LGPL software..." you cant relicense the runtime.
> So... regardless of whether or not I already have Qt installed on my > workstation, SWT/Qt will have to include its own version? Think of QtJambi as a port of Qt to Java, not a wrapper to call Qt code. QtJambi is Java, not C++ hidden in Java. There are no issues with the garbage collection, for example (which pester the Python version). That's why the integration between Qt and QtJambi is much tighter. I also second comment #40 that the SWT download should include everything necessary to make it work out of the box without any tricks and manual intervention. I fear that this means SWT/Qt can't be hosted by Eclipse and that people will have to download it elsewhere since LGPL and EPL simply are not compatible (= there will never be a version of the Java IDE which you can download from Eclipse that runs on Qt). Lawyers rule the world :-( I know only three solutions: Relicensing (with all the problems that brings) and what the Subversive guys did: They added a plugin to Eclipse which would bring up a UI to download and install the non-EPL-compatible parts of the plugin. Only in this case, that means we need a Swing-based mini-SWT that would allow us to bring up the dialog ... The third solution is to add a project page on eclipse.org and open the project on Sourceforge or similar, create an software package which can't be legally combined and wait for anyone to sue... ;-)
Thanks for backing me up (on comment #40). However I believe your post contain some incorrect statements. QtJambi IS a wrapper around Qt. Its a heavy weight wrapper but still its calling C++ code from Java. You can debug into C++ class (I did that) and all the way back. There is a different reason why you dont have to deal with garbage collection. QtJambi also contains Shared libs (DLLs on windows, SOs on Linux, Mac) and they are different for the various platforms. If it where only java there would be only ONE Jambi right ? The actually tasks of painting the UI are happening in C++ code. The other thing is the thing about LGPL and EPL dont work together. What you have in mind is probably GPL. You cannot build software that contains GPL and EPL. Not at eclipse.org and nowhere else. You can build packages that contain LGPL and EPL and ship them to your customer. The reason that eclipse does not allow that is that consumers whats to relicense binary runtime packages of eclipse software under a commercial license. You can do that with EPL and the other allowed licenses but not with LGPL. LGPL remains allways LGPL. (In reply to comment #41) > > So... regardless of whether or not I already have Qt installed on my > > workstation, SWT/Qt will have to include its own version? > > Think of QtJambi as a port of Qt to Java, not a wrapper to call Qt code. > QtJambi is Java, not C++ hidden in Java. There are no issues with the garbage > collection, for example (which pester the Python version). > > That's why the integration between Qt and QtJambi is much tighter. I also > second comment #40 that the SWT download should include everything necessary to > make it work out of the box without any tricks and manual intervention. > > I fear that this means SWT/Qt can't be hosted by Eclipse and that people will > have to download it elsewhere since LGPL and EPL simply are not compatible (= > there will never be a version of the Java IDE which you can download from > Eclipse that runs on Qt). Lawyers rule the world :-( > > I know only three solutions: Relicensing (with all the problems that brings) > and what the Subversive guys did: They added a plugin to Eclipse which would > bring up a UI to download and install the non-EPL-compatible parts of the > plugin. > > Only in this case, that means we need a Swing-based mini-SWT that would allow > us to bring up the dialog ... > > The third solution is to add a project page on eclipse.org and open the project > on Sourceforge or similar, create an software package which can't be legally > combined and wait for anyone to sue... ;-)
(In reply to comment #42) > QtJambi IS a wrapper around Qt. Its a heavy weight wrapper but still its > calling C++ code from Java. You can debug into C++ class (I did that) and all > the way back. There is a different reason why you dont have to deal with > garbage collection. My point is that QtJambi hides all the ugly details of the C++ implementation: Arguments passed by value (instead of by reference), keeping objects alive as long as someone still uses them (which you have to be very careful when using C++ directly or PyQt), etc. So it's much more than a thin, automatic wrapper created by running, say, SWIG on the header files. > The other thing is the thing about LGPL and EPL dont work together. What you > have in mind is probably GPL. You cannot build software that contains GPL and > EPL. Not at eclipse.org and nowhere else. You can build packages that contain > LGPL and EPL and ship them to your customer. > > The reason that eclipse does not allow that is that consumers whats to > relicense binary runtime packages of eclipse software under a commercial > license. You can do that with EPL and the other allowed licenses but not with > LGPL. LGPL remains allways LGPL. It seems that I'm a victim of the "LGPL vs. Java" rumor (http://www.gnu.org/licenses/lgpl-java.html). As stated in the linked document, you can distribute a LGPL library as long as "you [...] include source code for the library." Not sure whether that means it must be included in the binary download or it's enough to provide a download link.
My concern is that for any of this to work on any platform, it seems that both QtJambi and Qt itself must be distributed along with the corresponding SWT bundles. If this is the case, then both of these libraries would have to be considered "non exempt pre-reqs" and are therefore subject to the full rigors of the Eclipse IP process in addition to the license issue. I expect that a full review of Qt would be onerous. To this point, our IP Policy does not permit an Eclipse project to ship LGPL code; our IP Team cannot cite any examples of LGPL code being distributed by an Eclipse project (please let me know if you have different information). In contrast, we have "exempt pre-req" status on GTK, Windows, etc. These libraries are required, but are expected to be on the user's workstation. I'm not saying that this is over. I believe that these are our options: 1) Make a case that Qt/QtJambi are "exempt pre-reqs". I believe that our best hope is to use the "expected to be on the user's workstation" angle. Though this would only work if it is true. 2) Get Qt and QtJambi dual-licensed under EPL or some other license that we can distribute. 3) Change the Eclipse IP Policy to permit distribution of LGPL code. 4) Get the Eclipse board to make an exception. I'm not sure if there is any precedent for #4. This is just a (potentially) crazy idea that may be worth considering. I'm not all that hopeful about our chances with #3 either.
(In reply to comment #44) > In contrast, we have "exempt pre-req" status on GTK, Windows, etc. These > libraries are required, but are expected to be on the user's workstation. > > I'm not saying that this is over. I believe that these are our options: > > 1) Make a case that Qt/QtJambi are "exempt pre-reqs". I believe that our best > hope is to use the "expected to be on the user's workstation" angle. Though > this would only work if it is true. At least on Linux this is true for Qt, as Qt is part of LSB (just like gtk). See http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Desktop-generic/LSB-Desktop-generic/requirements.html#RLIBRARIES That is, any LSB-compliant Linux distribution is expected to provide Qt. See http://www.linuxfoundation.org/lsb-cert/productdir.php?by_lsb for certified distributions. Even though QtJambi is not in LSB (yet), one might still argue for the "exempt pre-reqs" because QtJambi is just a wrapper that makes Qt available to Java land. QtJambi can not exist without Qt, nor does it provide new functionality over Qt.
There is another option that I have pursued with my work on CDT and Wascana. Take the non-compliant bits and host them on Eclipse Labs (or somewhere). Create packages that use SWT/Qt and distribute them from there. Users who want to use and vendors looking for prebuilt binaries to redistribute a SWT/Qt based platform don't care much whether it comes from Eclipse itself or from and external server. The hardest problem is getting out the word on where to find them.
(In reply to comment #45) > At least on Linux this is true for Qt, as Qt is part of LSB (just like gtk). > See > http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Desktop-generic/LSB-Desktop-generic/requirements.html#RLIBRARIES > That is, any LSB-compliant Linux distribution is expected to provide Qt. See > http://www.linuxfoundation.org/lsb-cert/productdir.php?by_lsb for certified > distributions. But isn't it the case that Qt needs to be compiled with specific options to work with QtJambi? If this is the case, then the fact that Qt is available on some platforms is irrelevant. I'm assuming that the Qt that comes with an LSB-certified distribution wouldn't necessarily be compiled in this manner. Or is this an invalid assumption. > Even though QtJambi is not in LSB (yet), one might still argue for the "exempt > pre-reqs" because QtJambi is just a wrapper that makes Qt available to Java > land. QtJambi can not exist without Qt, nor does it provide new functionality > over Qt. Unless it is pervasive, and reasonably expected to be on the user's workstation, then "exempt pre-req" approach won't work. It doesn't have to be "all users", but we would have to reasonably expect that the sort of user who would use SWT/Qt would already have Qt/QtJambi installed to assert an "exempt pre-req".
As near as I can tell, QTJambi only depends on the stock QT package in my Linux distro (Arch). I'm not sure if QTJambi distributes its own flavor of QT as part of its package or not(?), but that seems to me to that it doesn't require a specially compiled separate QT package, based on that. I worry that QTJambi might not be pervasive enough on Linux distros, though since there is no official package in Arch for it -- it is only in the community-managed AUR.
(In reply to comment #48) > As near as I can tell, QTJambi only depends on the stock QT package in my Linux > distro (Arch). I'm not sure if QTJambi distributes its own flavor of QT as part > of its package or not(?), but that seems to me to that it doesn't require a > specially compiled separate QT package, based on that. Comment 37 suggests otherwise.
(In reply to comment #49) > (In reply to comment #48) > > As near as I can tell, QTJambi only depends on the stock QT package in my Linux > > distro (Arch). I'm not sure if QTJambi distributes its own flavor of QT as part > > of its package or not(?), but that seems to me to that it doesn't require a > > specially compiled separate QT package, based on that. > > Comment 37 suggests otherwise. Comment 38 seems to agree with me, though.
Of course, the Qt guys would have the answers. Being that they are Eclipse members, have we reached out to them?
(In reply to comment #50) > Comment 38 seems to agree with me, though. Missed that. This makes me happier.
(In reply to comment #46) > There is another option that I have pursued with my work on CDT and Wascana. > Take the non-compliant bits and host them on Eclipse Labs (or somewhere). > Create packages that use SWT/Qt and distribute them from there. > > Users who want to use and vendors looking for prebuilt binaries to redistribute > a SWT/Qt based platform don't care much whether it comes from Eclipse itself or > from and external server. The hardest problem is getting out the word on where > to find them. AFAIK Eclipse Labs does not host LGPL. I could go to Github of course but then what is the link to eclipse.org or in other words, why would I want to host the remaining pieces at eclipse.org if the other components (QtJambi, Qt), the download and maybe the build server (a gray area) has to happen somewhere else....
(In reply to comment #53) > AFAIK Eclipse Labs does not host LGPL. I could go to Github of course but then > what is the link to eclipse.org or in other words, why would I want to host the > remaining pieces at eclipse.org if the other components (QtJambi, Qt), the > download and maybe the build server (a gray area) has to happen somewhere > else.... Or SourceForge. And, yeah, it may not make much sense to involve eclipse.org at all. I was pretty excited about SWT/Qt until I learned you were using QtJambi. This outcome has been pretty predictable.
* About the special Qt build question: When one wants to run QtJambi (and nothing else) on Qt, then one may compile Qt with a special QT_JAMBI_BUILD define which disables some unnecessary modules and methods. e.g the Qt3 compatibility module is not used at all by QtJambi 4.x. So, to make things clear and easy for people not used to the Qt thing : a stock Qt 4.x lib with QtJambi 4.x is sufficient to make things work well. * QtJambi licensing issue: Nokia is (and will stay, IMHO) reluctant to change the license of Qt for they are at war for mobile platform hegemony currently. BUT (and this is where we can improve things) : if QtJambi was to be relicensed, then it would ease ACCESS to the Qt plaftorm without changing Qt's licensing model, thus without changing Nokia's IP power over it. My advice is to present things to Nokia this way. This is a clear win-win situation. * Humor time: Swt/Qt may be pronounced "Sweet on Cute" ;-)
Small question : when does precisely the Eclipse IP team forbids to ship LGPL code ? I mean: if we can't develop/contribute directly to the LGPL code but can DISTRIBUTE the QtJambi jar by simply mirroring the ones provided on Nokia's site, then we would be good, wouldn't we ? If the IP policy is designed to allow anybody to relicense the code downloaded on eclipse at his own will, then the QtJambi part shouldn't be quite limiting. Just look: nobody will indeed need to relicense nor change QtJambi as this is a connector with some other lib. In fact, code using it will be relicensed, which is SWT. Taking the latest version of QtJambi will be the most complicated change anybody would want to do upon it. The licensing rules are made, IMHO, to make eclipse developers at ease concerning the licensing nightmares for the eclipse component. This is where is the limit : QtJambi is not a component of Eclipse, it is a BRIDGE between eclipse and another, external, subsystem as would be Aero on Windows, Cocoa on MacOSX or X11 on *nix. Given all that, asking the Eclipse IP team wouldn't be such a bad idea...
(In reply to comment #56) > Small question : when does precisely the Eclipse IP team forbids to ship LGPL > code ? > > I mean: if we can't develop/contribute directly to the LGPL code but can > DISTRIBUTE the QtJambi jar by simply mirroring the ones provided on Nokia's > site, then we would be good, wouldn't we ? > > If the IP policy is designed to allow anybody to relicense the code downloaded > on eclipse at his own will, then the QtJambi part shouldn't be quite limiting. > Just look: nobody will indeed need to relicense nor change QtJambi as this is a > connector with some other lib. In fact, code using it will be relicensed, which > is SWT. Taking the latest version of QtJambi will be the most complicated > change anybody would want to do upon it. > > The licensing rules are made, IMHO, to make eclipse developers at ease > concerning the licensing nightmares for the eclipse component. This is where is > the limit : QtJambi is not a component of Eclipse, it is a BRIDGE between > eclipse and another, external, subsystem as would be Aero on Windows, Cocoa on > MacOSX or X11 on *nix. > > Given all that, asking the Eclipse IP team wouldn't be such a bad idea... Very good idea. There has been put quite some effort in forming a project at qtjambi.sf.net and you are sincerely very welcome to influence on it any way you would like. Code committing can be done in http://qt.gitorious.org/qt-jambi. We are currently two active persons on the project, me (Helge Fredriksen) and Smar (Samu Voutilainen). Personally, I'm not contributing that much to the development of QtJambi, I'm more interested in bundling packages and testing. Smar have current ongoing projects with support for MinGW and Qt 4.7. Please join in on the #qtjambi channel on freenode and the mailing list for discussions. It's a bit messed up on the gitorious side, currently the main repo is community-port-to-4_6, but Smar has a clone that we hope could be the main repo that also supports 4.7. However, it's a tough job (JNI bindings towards MinGW as an example) so any help would be MUCH appreciated.
(In reply to comment #56) > Small question : when does precisely the Eclipse IP team forbids to ship LGPL > code ? > > I mean: if we can't develop/contribute directly to the LGPL code but can > DISTRIBUTE the QtJambi jar by simply mirroring the ones provided on Nokia's > site, then we would be good, wouldn't we ? We had a quick talk about this at the last architecture council meeting. Even if you hosted the LGPL bits off site, the fact that you require users to go download them to make the features work, you are violating the policy. The dependency needs to be less than requires. If you can assume the user usually has the necessary bits already, as we do with GTK today, then you're OK. About the only thing that would satisfy that today is Qt on Linux. QtJambi, probably not. And that's the kicker. The proper Eclipse IP friendly solution would be to have written SWT/Qt directly to Qt, writing your own adaptation layer, unless Nokia relicenses QtJambi as EPL.
I heard you said that before that you think it should have been implemented without QtJambi in first place. Well I disagree but in any event, thats the way it is now and I personnaly wouldnt invest ressources to change it. What you didnt mention is that without QtJambi and if we just rely that Qt is already installed we also dont have a solution for Windows and Mac. Despite other people's preference, Linux is not our preferred platform or the platform of our customers. So someone else would have to spent cycles on a Linux only solution. And also that would really disappoint 2/3 of the people who downloaded the current version from our website (2/3 where Windows and Mac downloads). But I agree that this is an complicated topic. Lets see how it develops. christian (In reply to comment #58) > (In reply to comment #56) > > Small question : when does precisely the Eclipse IP team forbids to ship LGPL > > code ? > > > > I mean: if we can't develop/contribute directly to the LGPL code but can > > DISTRIBUTE the QtJambi jar by simply mirroring the ones provided on Nokia's > > site, then we would be good, wouldn't we ? > > We had a quick talk about this at the last architecture council meeting. Even > if you hosted the LGPL bits off site, the fact that you require users to go > download them to make the features work, you are violating the policy. > > The dependency needs to be less than requires. If you can assume the user > usually has the necessary bits already, as we do with GTK today, then you're > OK. About the only thing that would satisfy that today is Qt on Linux. QtJambi, > probably not. And that's the kicker. > > The proper Eclipse IP friendly solution would be to have written SWT/Qt > directly to Qt, writing your own adaptation layer, unless Nokia relicenses > QtJambi as EPL.
Sorry for not chiming in earlier (I am on vacation) but it seems important to explain what your options are for distributing LGPL code. At this point in time, the only way to distribute LGPL licensed code as an eclipse.org - hosted project is through the 'Policy to Consider the Limited Usage of LGPL APIs in Eclipse Projects' [1] as passed by the Eclipse Board of Directors in a recent meeting [2]. I don't think I can summarize the policy in less words without leaving out important details, but one thing it explicitly does not allow is distributing Qt itself, you would only be able to distribute something that interfaces to an already installed Qt. Assuming you would like to follow the policy, there are a number of conditions, let's look at each of them: i) The LGPL code in question can only be API, not functional code. Is this the case for Qt Jambi? If you called Qt directly as suggested by Silenio and Bogdan, the answer would very clearly be yes. For Qt Jambi I am not sure, but maybe the case can be made. ii) Sounds like it will be easy to fulfill - provide a binding to the API in your Eclipse project. iii) The software library that you access through the LGPL'ed API (in this case you are accessing Qt) must be 'prerequisite software' as defined by [3], but this seems to be the case, see comment 45 "on Linux this is true for Qt, as Qt is part of LSB (just like gtk)". iv) The APIs cannot be obtained under a more permissive license. Unless Nokia, together with potential contributors, relicenses Qt Jambi, this is true. v), vi) These are technicalities similar to ii) vii) This is another important one - the Board will have to approve each individual case where the policy is being used, with a supermajority vote (two thirds). The policy lists two criteria to be used by the Board for its decision. First, the library being accessed must provide functionality that cannot be obtained through another library with a more permissive license. This seems to be the case - alternatives like GTK are not more permissive licensed. Second, the functionality, usability, or consumability of an Eclipse project would be severely restricted or reduced without using the library. Could you perhaps argue that the usability of your Eclipse project (Riena?) would be severely reduced without the styling capabilities provided by Qt? The two precedents for this are in SWT: First, the use of the GTK APIs (since forever), and second, the use of the WebKit APIs (since 3.5, see the Board decision about this in [2]). [1] http://www.eclipse.org/org/foundation/boardminutes/2010_03_exhibits/ExhibitK.pdf [2] http://www.eclipse.org/org/foundation/boardminutes/2010_03_22_Minutes.php [3] http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
(In reply to comment #59) > What you didnt mention is that without QtJambi and if we just rely that Qt is > already installed we also dont have a solution for Windows and Mac. You refer to being able to distribute a "works out of the box" download. Realistially, I don't think this will be allowed at eclipse.org given the current policies, and I wouldn't hold much hope for a change of these policies by the board.
I should probably clarify: I'm not saying that you should give up, I just wanted to explain how this could work: Get approval for Qt as a pre-req based on the argument that it is installed on virtually every Linux machine. Then get approval for Qt Jambi as an API (it would have to be the case that it does not contain 'functional code'), ultimately by the Board voting for it. This would put you in a position where SWT can distribute something that would work out of the box on Linux. Then, distribute 'out of the box' downloads for Windows and Mac from somewhere else. Without making it work on Linux I could imagine that you would have a hard time getting approval for the pre-req Qt since it could not longer be considered 'exempt'.
I had contacted the original Jambi team to clarify if there is indeed a need for Qt native libraries compiled specifically for Jambi. In short, QT_JAMBI_BUILD flag allows a warning message to be printed on the console when the programmer has made the mistake of deleting an object from within its own event handler. So without this flag it is just difficult to notice such programming errors but applications will run OK on regular Qt native libraries fine..
On Qt and Symbian see (http://qt.nokia.com/about/licensing/frequently-asked-questions/) "The Symbian Foundation has chosen the Eclipse Public License for Symbian – is the LGPL compatible with this? While the LGPL and the EPL are not compatible and may not be combined on a file-by-file basis, they may be used in a common environment provided that the interaction between Qt and Symbian is limited to: dynamic linking, inter-process communication and data exchange." IANAL. I guess the question is whether bundling Qt DLLs in OSGi bundle can be considered a "dynamic linking" or not. I would hope that having Qt and JAMBI as LGPLed Orbit bundles would allow distributing them as a part of EPLed product.
(In reply to comment #64) > On Qt and Symbian see > (http://qt.nokia.com/about/licensing/frequently-asked-questions/) > > "The Symbian Foundation has chosen the Eclipse Public License for Symbian – is > the LGPL compatible with this? > > While the LGPL and the EPL are not compatible and may not be combined on a > file-by-file basis, they may be used in a common environment provided that the > interaction between Qt and Symbian is limited to: dynamic linking, > inter-process communication and data exchange." > > IANAL. I guess the question is whether bundling Qt DLLs in OSGi bundle can be > considered a "dynamic linking" or not. I would hope that having Qt and JAMBI as > LGPLed Orbit bundles would allow distributing them as a part of EPLed product. IANAL either, you can clearly write JNI code that links in the Qt DLLs and not violate EPL or LGPL. That happens already with GTK, libc, i.e. almost everything needed to run Eclipse on Linux. I still, and never will, agree with Eclipse's policy to disallow bundling of LGPL libraries (and GPL executables for that matter), especially when I and many others work commercially on products that do just that. But I'm tired of fighting that fight. I guess you'll just have to buy our products :). The JAMBI thing is different. I haven't seen a clear definition of how to do LGPL with OSGi bundles. You need to be able to allow the user to provide their own implementation of any LGPL code. Is that as easy to do with OSGi as it is with DLLs? Not sure. And that's the rub.
Here is my proposed resolution: * Host SWT/Qt and Qt Jambi and the downloads for all platforms (Windows, Mac, Linux) on Eclipse Labs. * The bundle names for your EclipseLabs project would be org.eclipselabs * However, we realize that to implement SWT you have no choice but to use org.eclipse as the name space for the packages which implement SWT APIs. Accordingly, we are granting this project a specific exemption to our trademark guidelines to allow you to use org.eclipse in this way. I hope that this meets with everyone's satisfaction. If anyone has a better idea, please let me know.
+1 on Mike's suggestion. I think it's important at this point to make the code public so we can give you technical advice on where to go from here. Like, for example, if an EPL Java binding for Qt happened to show up one day, how could we move SWT/Qt on top of it.
Is it possible to open QWidget parented to eclipse mdi area
I have code to embed QWidgets into SWT/win32 and SWT/Cocoa32. I will be opensourcing it in a few weeks.
Could someone here please resume how a Eclipse Hostable Qt-binding would look like. My current assumption is: a) Glue-Code: Java, JNI must be written (or generated) and licensed under EPL (and probably dual licensed under LGPL) b) Native Glue-Code Linking must be dynamic - this way we can define Qt-Dlls/.so /dylib to be a prerequisit on the target system
IANAL, but there is on the CC list... (In reply to comment #70) > Could someone here please resume how a Eclipse Hostable Qt-binding would look > like. > > My current assumption is: > > a) Glue-Code: Java, JNI must be written (or generated) and licensed under EPL > (and probably dual licensed under LGPL) As is the case with the GTK port of SWT, you would write Java/JNI to wrap the Qt API. I assume that could be done without dual licensing. JNI wrappers are trivial to write, so we could do an EPL implementation ourselves. > b) Native Glue-Code Linking must be dynamic - this way we can define > Qt-Dlls/.so > /dylib to be a prerequisit on the target system Yes, and I think that's a reasonable assumption - to assume it's already installed on the system. If SWT/Qt gives us an extra boost in usability or performance, I'd prefer it be a standard part of Eclipse. Qt going LGPL should have facilitated but only if we had created an EPL-licensed binding.
Take a look at the eRCP project. eSWT is ported to Qt using JNI wrappers. eRCP project is able to distribute them from Eclipse.org (we provide binaries for Linux and Symbian is in the works) eSWT has a workswith dependency to LGPL licensed Qt code.
I looked at the code from compeople and I think it should be (though some work) replace their QtJambi calls EPL-JNI code. My take on this looks like the following: * Provide an dynamically linked SWT-QT binding fragment => prereq => served from Eclipse.org * From RCP-Developers who want to make distribution (and can deal with shiping LGPL-Code) easy provide a statically linked SWT-Qt binding (correct me if I'm wrong but this is not more than compiler switch right?) from eclipselabs.org From a software design Pov I'd still like to make it possible for people to extend our code so that they can also use features not available from the SWT-API so the here's my take on it: org.eclipse.qt.binding * org.eclipse.qt.binding.gui.QPushButton * org.eclipse.qt.binding.gui.nci.NCI_QPushButton org.eclipse.swt.qt (depends on org.eclipse.qt.binding) * org.eclipse.swt.widgets.Button and in pseudo code: class NCI_QPushButton { public static native long _qt_new(); public static native void _qt_setText_string(long ptr, String text); } class QPushButton { private long ptr; public QPushButton(long ptr) { this.ptr = NCI_QPushButton._qt_new(); } public void setText(String text) { NCI_QPushButton._qt_setText_string(ptr,text); } } class Button { private long ptr; public Button(Composite parent, int style) { super(parent,style); this.ptr = NCI_QPushButton._qt_new(); } public void setText(String text) { NCI_QPushButton._qt_setText_string(ptr,text); } } So org.eclipse.swt.qt only calls NCI_*.* and people who'd like to use advanced features only available in Qt can use the QPushButton.
(In reply to comment #73) > I looked at the code from compeople and I think it should be (though some work) > replace their QtJambi calls EPL-JNI code. I think that's the best course of action. I can volunteer to help with the JNI part and setting up CDT to build it. > My take on this looks like the following: > * Provide an dynamically linked SWT-QT binding fragment => prereq > => served from Eclipse.org > * From RCP-Developers who want to make distribution (and can deal with shiping > LGPL-Code) easy provide a statically linked SWT-Qt binding (correct me if I'm > wrong but this is not more than compiler switch right?) from eclipselabs.org I'm not even sure you need/want to rebuild. There are different ways to deal with getting the DLLs into the eclipse tree and loading them from there when they can't be found on the system. > From a software design Pov I'd still like to make it possible for people to > extend our code so that they can also use features not available from the > SWT-API so the here's my take on it: +1. I'd hate SWT to constrain us from using the full Qt.
I'm sorry if someone already brought that up, but this keeps bothering me: How important is it that the project is Eclipse hosted? IAM (a Maven 2 plugin for Eclipse) is also hosted on Eclipse but the update site is on Google code. I understand that it would be great to have something as basic as the UI on eclipse.org itself but if the licenses don't allow it, then that's that. I also see that more and more projects have the same problem. Therefore, I wonder if it might be better to approach someone like Pulse (http://www.poweredbypulse.com/download_linux.php) to host the non-EPL components and build a working Eclipse distribution from that.
Well my problem is more with QtJambi ('s Design) because it e.g. relies on Java-GC and adds features I'm not really sure are needed (you can write subclasses of C++-Objects in Java) which makes it harder to understand/debug/maintain than a thin JNI-Layer but maybe that's just me
(In reply to comment #76) > Well my problem is more with QtJambi ('s Design) because it e.g. relies on > Java-GC and adds features I'm not really sure are needed (you can write > subclasses of C++-Objects in Java) which makes it harder to > understand/debug/maintain than a thin JNI-Layer but maybe that's just me True. Hopefully you are aware that you need to subclass the Qt C++ in order to implement Drag and Drop. Its also necessary for some Qt classes in order to access some events that are not accessible as signal. At least that is my understanding.
ok - this might be but then we should do it on a case by case base and not generally for all and everything - do you agree with me on this? I think you guys did a fantastic job of mapping the appropriate Qt-API to SWT "all" we need to do now is replace QtJambi :-)
It should be possible to capture all the events that occur on the QApplication or a QObject via event filters. Therefore it should be possible to capture all events without subclassing. For instance, eSWT installs a single event filter to QApplication and makes callbacks to corresponding Display instance so that the event can be processed further. The mechanism is actually nothing new to SWT implementations win32 & gtk ports work similarly with the events.
(In reply to comment #77) > True. Hopefully you are aware that you need to subclass the Qt C++ in order to > implement Drag and Drop. Its also necessary for some Qt classes in order to > access some events that are not accessible as signal. Don't be afraid to do this in C++ in the binding DLL. We don't need to have everything in Java. ;)
(In reply to comment #75) > I'm sorry if someone already brought that up, but this keeps bothering me: How > important is it that the project is Eclipse hosted? It's about getting SWT/Qt to the masses through the Eclipse EPP projects so we can get as much testing as we can and maybe improve the general usability of Eclipse. We can't do that if they are hosted externally.
(In reply to comment #70) > Could someone here please resume how a Eclipse Hostable Qt-binding would look > like. Sorry for commenting on this rather late. I would like to point everyone to a Board-approved policy that I believe would apply in this case: http://www.eclipse.org/org/documents/LGPL_API_Policy.pdf
(In reply to comment #82) > (In reply to comment #70) > > Could someone here please resume how a Eclipse Hostable Qt-binding would look > > like. > > Sorry for commenting on this rather late. I would like to point everyone to a > Board-approved policy that I believe would apply in this case: > > http://www.eclipse.org/org/documents/LGPL_API_Policy.pdf "The Eclipse Board must approve each and every usage of LGPL APIs in Eclipse projects by a supermajority vote (consisting of two thirds of voting members), and may do so only if it finds that the following conditions are satisfied: a) there is no alternative open source software that provides the same or similar function to the underlying software library invoked by the APIs that can be obtained under a more permissive license; and b) the functionality, usability or consumability of an Eclipse project would be severely restricted or reduced absent the use of such LGPL APIs. In determining that such conditions are satisfied, the Board may rely on information compiled by the PMC for the project requesting usage of LGPL APIs and vetted by the EMO."
(In reply to comment #83) > "The Eclipse Board must approve each and every usage of LGPL APIs in Eclipse > projects by a supermajority vote (consisting of two thirds of voting members), > and may do so only if it finds that the following conditions are satisfied: > a) there is no alternative open source software that provides the same or > similar function to the underlying software library invoked by the APIs that > can be obtained under a more permissive license; and > b) the functionality, usability or consumability of an Eclipse project would be > severely restricted or reduced absent the use of such LGPL APIs. > In determining that such conditions are satisfied, the Board may rely on > information compiled by the PMC for the project requesting usage of LGPL APIs > and vetted by the EMO." I assume they've given approval for GTK already. I do hope that wouldn't be a problem for Qt. Especially with Nokia on the board.
(In reply to comment #76) > Well my problem is more with QtJambi ('s Design) because it e.g. relies on > Java-GC and adds features I'm not really sure are needed (you can write > subclasses of C++-Objects in Java) which makes it harder to > understand/debug/maintain than a thin JNI-Layer but maybe that's just me That depends on what you want to achieve. SWT tries very hard to be a simple, inflexible UI toolkit which does the bare minimum which the Eclipse Platform needs. You need a change, go fork. Qt, on the other hand, was designed by people who understood one thing: It doesn't matter if it's hard to maintain, it must be easy to *use* for the developer. It must be cute. People must like to use it. Of course you can replace a well designed, balanced and working wrapper with something ... else. Just imagine how much time it will take to get everything to a point where it is working as it is right now. With the man- and brainpower that is available. And what the result will be like. The SWT people won't like it because the public API will contain a mix of basic SWT code and a lot of Qt code for fine tuning (there are so many things that you can do in Qt which SWT just doesn't offer). The Qt people won't like it because only a few things that they are used to will work the way they expect. Or you could restrict it to what SWT can do. Which kind of kills the point of using Qt at all if you can't use its features. In my opinion, it boils down to: Who do you want to alienate? A couple of lawyers at eclipse.org or all the people that you want to get on board to use SWT/Qt? That's why I argue: Use QtJambi, download the release files from eclipse.org, just replace the SWT jars in them and put that on a server outside eclipse.org. Problem solved, everyone happy, a lot of work not duplicated. New releases of eclipse and Qt will create a reasonable amount of work instead of an uphill struggle to get a new release ready twice a year (once for Eclipse and once for Qt).
(In reply to comment #85) > In my opinion, it boils down to: Who do you want to alienate? A couple of > lawyers at eclipse.org or all the people that you want to get on board to use > SWT/Qt? That's a bit of a twisted view. The people I want to get on board using SWT/Qt are Eclipse users, not necessarily developers. It's about improving SWT. That does bring up the question, if developers do start using Qt from behind SWT, wouldn't that cause major breakage on other versions of SWT? I don't get that strategy, unless we standardize on Qt across all platforms. Which would then beg, why do we have SWT? > That's why I argue: Use QtJambi, download the release files from eclipse.org, > just replace the SWT jars in them and put that on a server outside eclipse.org. > Problem solved, everyone happy, a lot of work not duplicated. New releases of > eclipse and Qt will create a reasonable amount of work instead of an uphill > struggle to get a new release ready twice a year (once for Eclipse and once for > Qt). Except no one will be able to figure out how to install this. So you alienate the users with this strategy. I'm not sure where we're going with this. Why is SWT/Qt so important? SWT/GTK is ugly as sin, but would SWT/Qt be any better? Have we jumped on SWT/Qt because it's cool technology? Does it solve a real problem? Probably a good point to pause and ask these questions before diving into the solution.
> Except no one will be able to figure out how to install this. So you alienate > the users with this strategy. > > I'm not sure where we're going with this. Why is SWT/Qt so important? SWT/GTK > is ugly as sin, but would SWT/Qt be any better? Have we jumped on SWT/Qt > because it's cool technology? Does it solve a real problem? Probably a good > point to pause and ask these questions before diving into the solution. I think there's a point in SWT/Qt indeed. You know, there a two SWT implementations for Linux currently (GTK and Motif), as well as two SWT implementations for Mac OS X (Carbon and Cocoa)... so I don't see the problem with a Qt implementation. I know Linux is kind of madness regarding desktop, there are so many choices and implementations... Gnome (GTK), KDE (Qt), XFCE (GTK), Fluxbox... whatever. Yes, it's mad, but it's also what makes Linux so good. I think there's room for a third SWT/Linux native implementation. Besides, regarding Linux itself, I think Qt fits better than GTK because Qt integrates into a GTK environment better than GTK does into a Qt one. Take a look at applications such as smplayer or vlc (both Qt applications) running under Gnome, XFCE or Fluxbox... thay just look like native GTK applications. I don't mean to drop GTK port... but I think there is room for a native Qt implementation as well.
I just totally agree. What's up with this question : does anybody still care ?
(In reply to comment #88) > I just totally agree. > > What's up with this question : does anybody still care ? I used to but I'm now more interested in JavaFX 2.
I would ;-) The question is more like: are the compeople still willing to invest time? Who else would need to devote resources? From a technical point of view: does Eclipse 4's new rendering layer make things somehow easier? http://www.vogella.com/articles/Eclipse4Renderer/article.html
"The compeople" …. I like that :-) Compeople will not invest in SWT/Qt anymore resources as it stands now. We are also currently investing time and resources into JavaFX 2.x. SWT/Qt was interesting for us in the past because we were and still are not always satisfied with the styling capabilities of SWT on Win32. We have writting our own Look and Feel Capability for SWT into Eclipse Riena. Still that is limited by the abilities of SWT and basically allows us to give a large application a common look. We have already started to get the first JavaFX widgets working with Riena, RCP and all that. Currently we are embedding JavaFX widgets and Canvas into an SWT based application. In the future everything should be JavaFX. This bug was started to discuss how SWT/Qt could be part of SWT at Eclipse.org. That pretty much failed for license reason and now SWT/Qt lives on EclipseLabs and gets little attention. I think the right time for SWT/Qt is over. I hear a lot more people are now interesting in JavaFX and they want to use it directly and not through an SWT API.
(In reply to comment #91) > This bug was started to discuss how SWT/Qt could be part of SWT at > Eclipse.org. That pretty much failed for license reason and now SWT/Qt lives > on EclipseLabs and gets little attention. So sad. I guess http://doc.qt.digia.com/4.4/license-gpl-exceptions.html doesn't extend to QtJambi? And if it did, would that help? > I think the right time for SWT/Qt is over. I hear a lot more people are now > interesting in JavaFX and they want to use it directly and not through an > SWT API. Oh dear. IMHO, so far anything UI coming from Sun was a mess, both the API + implementation and the visual appearance.
(In reply to comment #92) > (In reply to comment #91) > > This bug was started to discuss how SWT/Qt could be part of SWT at > > Eclipse.org. That pretty much failed for license reason and now SWT/Qt lives > > on EclipseLabs and gets little attention. > > So sad. I guess http://doc.qt.digia.com/4.4/license-gpl-exceptions.html > doesn't extend to QtJambi? And if it did, would that help? QtJambi is licensed under GPL or LGPL itself. The Eclipse Foundation does not allow LGPL software in their downloads. The other problem is that QtJambi (last time I checked) was behind Qt. (there is nearly no committer force committed to it) Also QtJambi and Qt are tightly coupled. So you always needed a certain QtJambi version for a certain Qt version. Some people suggested that SWT/Qt should be directly based on Qt (without QtJambi). That is something Nokia has started on a small scale for mobile device (that also have Qt). I think eSWT (SWT for embedded devices) supports Qt (not the desktop Qt but a subset) > > > I think the right time for SWT/Qt is over. I hear a lot more people are now > > interesting in JavaFX and they want to use it directly and not through an > > SWT API. > > Oh dear. IMHO, so far anything UI coming from Sun was a mess, both the API > + implementation and the visual appearance. I have a different opinion here but thats ok. We used Swing for a pretty large application and where quite satisfied with the API and the appearance. (did our own LnF there and many other things). Since RCP 3.x is tightly coupled to SWT we also had to use SWT for Eclipse Riena. If you dont like JavaFX fair enough. The feedback we hear from others is different. and even "Mr. SWT" (Steve Northovoer)is now doing JavaFX :-).
(In reply to comment #93) I didn't imagine it is so hard to create a Java binding for Qt using JNI... > If you dont like JavaFX fair enough. The feedback we hear from others is > different. and even "Mr. SWT" (Steve Northovoer)is now doing JavaFX :-). Reading about Steve made me look at the JavaFX demos. This is getting a bit off-topic, but still: * the default font has terribly bad kerning (and is plain ugly, if you ask people with typographic experience...) * the font antialiasing has nothing to do with the platform's (probably no subpixel-hinting) and it just looks alien * the animations are clunky (a simple moving ball is hopping irregularly and losing its shape in between in "http://download.oracle.com/otndocs/products/javafx/2.2/samples/Ensemble/index.html#SAMPLES/Animation/Transitions/Translate Transition", on 64bit Linux Chrome) That's subjective and aesthetical problems, but guess what is one important reason why Apple products sell like hell ;)
(In reply to comment #94) > (In reply to comment #93) > > I didn't imagine it is so hard to create a Java binding for Qt using JNI... > > > If you dont like JavaFX fair enough. The feedback we hear from others is > > different. and even "Mr. SWT" (Steve Northovoer)is now doing JavaFX :-). > > Reading about Steve made me look at the JavaFX demos. This is getting a bit > off-topic, but still: > * the default font has terribly bad kerning (and is plain ugly, if you ask > people with typographic experience...) > * the font antialiasing has nothing to do with the platform's (probably no > subpixel-hinting) and it just looks alien > * the animations are clunky (a simple moving ball is hopping irregularly and > losing its shape in between in > "http://download.oracle.com/otndocs/products/javafx/2.2/samples/Ensemble/ > index.html#SAMPLES/Animation/Transitions/Translate Transition", on 64bit > Linux Chrome) > > That's subjective and aesthetical problems, but guess what is one important > reason why Apple products sell like hell ;) right its off-topic but JavaFX supports subpixel-hinting: (Google is your friend) https://blogs.oracle.com/javafx/entry/lcd_text_support_in_javafx
Qt itself is also moving to a QML [1] which makes it easier to develop fluid UIs and utilize GPU better. There is no long term benefit of making a SWT Qt port anymore. However ability to develop UIs with QML and Javascript on RCP applications is a different story. [1] http://doc.qt.digia.com/4.8-snapshot/qml-intro.html
Marking the bug as wontfix. Years has passed, qtjambi is no longer actively developed and still at qt4 level. If someone is still interested in doing it on qt5 please open a new bug to start a fresh as the amount of comments here makes the bug already useless.
