Community
Participate
Working Groups
GTK and Motif implementations do not participate in some of the KDE services, and often are visually dis-jointed from a surrounding KDE desktop. Having a "native" KDE-backed (or at least QT-backed) implementation of SWT would be highly desireable.
To be considered post R2.0.
Moving from Later.
Any chance of seeing this in 2.2? I would appreciate a "native" QT version for working under Linux, and I sencond the arguments of the original reporter. I remember some postings or web pages saying that SWT/QT is less of a techical problem and more of a legal one. Something about an incompatibility between the CPL and the GPL (under which QT is available). If so, it might be easiest to buy Trolltech. :)
There is no plan in place to do this.
The http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/dev.html website says, that "SWT for Qt/E will be included in the next release of the IBM WebSphere Micro Environment and WebSphere Customer Environment products. We are currently working on determining the feasibility of releasing SWT for Qt/E to the Eclipse project." Is that still a leftover from times back, or is that something new? Any news if swt/qt can be done, when the QT license is used? This was asked in the swt newsgroup several times, but I've only heard answers to the swt <-> qt/gpl issue, but not qt/QTL. If eclipse.org had some laywers looking into it, it would be nice if the result would be posted somewhere...
I'd definitely love a solid clarification on this. It is well-known that the patent clauses in CPL prevent interoperation with the GPL, but I haven't heard any word on exactly what incompatibility there is between the CPL and the QPL. Afterall, nobody will run SWT/Qt on Windows, they will run SWT/Windows. We only care about SWT/Qt on KDE, and you can license Qt/Free under the QPL.
You need to ask the Qt guys about this. They need to work it out with the Eclipse lawyers. Us developers can do nothing.
Saying that is simply passing the buck. I just emailed Trolltech to ask about this and they said that "as long as CPL is a recognised Open Source license" (which it is), then it should be fine. That is to say, if there is any incompatibility, it is up to the Eclipse team to determine it, not Trolltech.
I'm no license expert, but since QT libraries are GPL (not LGPL), you cannot ship them with closed source commercial software. Trolltech charges money for commercial usage of their libraries. So I'm guessing this is the problem. You couldn't, as far as I know, ship QT libraries with "closed source" commercial software, as 3rd party vendors doesn't need to have their code distributed under CPL/EPL. After all, I could then create closed source commercial software using QT without paying anything to Trolltech. But I'm a big KDE fan and I use KDE everyday (and the GTK tree widget is driving me nuts) so I wish this could be done. Maybe it can't be shipped with Eclipse, but someone could definitivly do it as an open source GPL project..
I wish people would stop spouting this "Qt is GPL is evil" bullshit, personally. It's a common misconception which probably started from the GTK zealots who wanted to believe that somehow GTK's license is superior. In _fact_, the Qt libraries are dual license, GPL/QPL. Obviously since GPL and CPL are incompatible, there is no point licensing it under the GPL in the case of Eclipse/SWT. But QPL is an obvious choice, and is perfectly legal according to Trolltech themselves. And you can already develop a commercial product which works with Qt. You just can't _distribute_ Qt with that commercial product. This is exactly the same as it would be in SWT/Qt would just be released. And I see no point in developing the entire thing again when IBM have already been boasting about having completed it.
> Saying that is simply passing the buck. I am an engineer and can do or say nothing about the legal world. If you want something to happen, you will need to deal with entities from that world, not the developers.
Now, that Eclipse is EPL instead of CPL, does it mean it will support also KDE (Qt)?
Even if it is problematic, maybe it is possible to follow the JDT spell checker example (it comes without dictionaries, since most free dictionaries are GPL-ed) - distribute Eclipse under CPL with no "in question" plugins and develop the Qt/SWT implementation under the appropriate license. Users will download this alternative implementation and install it on their systems. This should be legal since it's legal to write GPL programs that run on windows (and you can't force M$ to open source windows ...).
Still can't help. It's between Trolltech and Eclipse.org. Whatever they decide is the answer.
Genady Beryozkin's solution sounded like it didn't involve the legal dispute at all, actually. Maybe you should try it.
Nothing to try. I can't develop or release QT code into Eclipse CVS without risking my job.
What if you (or somebody else) opens a Sourceforge project and commits the code there? Or can IBM (I assume you wrote the code as part of your IBM job) make the code available as "public domain"?
I'm not a lawyer and have no idea. I just want to hack code.
That's exactly it. It doesn't have to go into Eclipse CVS. Any bit that goes into Eclipse CVS doesn't even have to contain Qt code. There is a standard workaround for this sort of issue. 1. Binding library licensed under some flexible license like BSD. 2. Implementation of SWT as a frontend of said binding, licensed under the EPL. 3. Implementation of Qt as a backend of said binding, licensed under the GPL. But besides all that, Trolltech already told me ages ago that there shouldn't be a problem. It seems that the Eclipse.org side is where the problem is, so at least the bug is in the right place. Perhaps if the "lowly developer" can't do it, the bug should be reassigned to someone who _can_.
*** Bug 107686 has been marked as a duplicate of this bug. ***
What is the licensing problem? I thought Qt/KDE were under GPL? (Albeit Qt make corportions pay certain fees?)
I'm not a lawyer but I guess it's because of the incompatibilities between the EPL/CPL and the GPL. SWT would be linked against GPL code, which requires the SWT code to be released under GPL as well. I'm not sure what this will mean for RCP apps.
The two licences are definitely incompatible at the moment, as the GPL doesn't allow extra restrictions to be placed upon the redistribution, whereas the CPL requires the patents to be mentioned (that's the broad summary, anyway.) This requirement for the patents to be mentioned directly breaks the GPL's requirement on not having extra restrictions. Supposedly the *next* GPL (version 3.0) is going to have consideration for patents, so maybe by that version will be compatible with the CPL. All this is pretty much academic anyway, for two reasons. 1. Trolltech have already said that "as long as CPL is a recognised Open Source license" then there should be no problem. Presumably at this point, the Eclipse project are just covering their arses... you know, in case they release it, and then Trolltech change their mind. This seems pretty unlikely though, especially if you know what Trolltech are like. They're pretty supportive of open source projects and have been known to do things like give free licences of Qt to certain open source projects (e.g. the Psi project.) A little negotiation goes a long way with those guys. 2. The GPL/CPL licence incompatibility problem would only exist in situations where the SWT project redistributed Qt itself. Source code which *links* to Qt could be released without repurcussions, and would satisfy the majority of the cases out there. If it were for Windows, I could understand it, because there is a culture of redistributing every library with the executable. But SWT/Qt wouldn't be used on Windows because we already have SWT/Win32. SWT/Qt would be used on *nix systems, where distributing source is pretty common. It would also allow people who actually have a commercial Qt licence already, to get a nice Java wrapper around that library, for slightly simpler development. But you know, I think the fact that the SWT team haven't done the port, and simply don't want to do the port, outweighs the sanity of these two points, no matter how true they may be.
With GPLv3 it should be possible; I hope this issue can be pursued. http://news.zdnet.com/2100-9595_22-6028746.html "Second, there are also more programs under more licenses which, while free, are incompatible with GPL. To enable broader technical collaboration, we have added the enhanced compatibility provisions of the license to allow more people to share more code across more projects than ever before. The ability to share Eclipse License code and Apache License Code...means that GPL now reaches far more broadly across the world of programs and projects than it ever did before."
A year later... Now that Java is GPL'd this situation looks even more absurd ~~ I love Java, Eclipse & KDE, IMHO the 3 best in their respective categories... Why do I have to run eclipse at a "sub-windows" performance with an awful file opening dialog, non-working drag-n-drops, buggy trees etc etc ...? If there is a special case to add to whatever license or a third license type to release something with, why not just do it ? Why not release them separately ? I basically run an eclipse under qt with the gtk-qt bridge and I am still not in prison, so somewhere a license shunt is somewhere possible. (In reply to comment #24)
The problem wasn't Java in the first place. The problem was CPL's incompatibility with the GPL.
(In reply to comment #26) > The problem wasn't Java in the first place. The problem was CPL's > incompatibility with the GPL. > Yes, I know, I was making a point that eclipse is built on a gpl'ed compiler, run a gpl'ed system and a gpl'ed vm and has to use *indirectly* a gpl'ed graphic toolkit (I mean by that the gtk / gtk-qt / qt bridge). The only thing that allows it, if I understand correctly is that gtk is lgpl so the gpl and the cpl are compatible with it ? So exactly like you said yourself, so be it, if we release a qt-binding-custom-just-for-swt-friendly-lgpl as a 1 to 1, method by method exposition of the qt-official-java-binding-evil-gpl would it work ? Would eclipse.org use it ?
Sorry for this off-topic reply but there is something wrong in comment #27. (In reply to comment #27) > [...] eclipse is built on a gpl'ed compiler, > run a gpl'ed system and a gpl'ed vm [...] Eclipse is built using its own compiler - the Eclipse compiler - which is EPL not GPL. Additionally, Sun made it clear that a GPLed VM and class library does not 'infect' the software running on it. Last but not least, there is also J9, IBMs VM to compile and test against.
(In reply to comment #3) > Any chance of seeing this in 2.2? I would appreciate a "native" QT version for > working under Linux, and I sencond the arguments of the original reporter. > I remember some postings or web pages saying that SWT/QT is less of a techical > problem and more of a legal one. Something about an incompatibility between the > CPL and the GPL (under which QT is available). If so, it might be easiest to > buy Trolltech. :) I like the idea. In 4+ years we could have raised the money already :)
http://trolltech.com/products/qt/gplexception Does it make any difference ?
The GPL exception explicitly allows linking to CPL code. Unfortunately right now the only Qt version that has been released with this license is 4.3.1, while the existing code probably requires Qt 3.x. Porting it shouldn't be too hard though, assuming the source got released (and releasing the source shouldn't be a problem even with pure GPL - just linking it to pure GPL code would be problematic, which is, of course, something people who download the source for the sole purpose of porting it to Qt 4.x wouldn't do.
We had the contribution of eSWT on QTe code on eRCP project CVS [1]. There had not been enough interest for it to complete eSWT level interest so far. Also there is a recent change on the ownership of the QT [2]. What is the interest and level of existing code for a SWT implementation? Is there an existing code base that can be contributed for SWT (besides the current eSWT contribution) ? Would SWT team be interested on a complete SWT implementation? [1] http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ercp/org.eclipse.ercp.swt.core.qte/?root=DSDP_Project [2] http://trolltech.com/28012008/28012008
> Would SWT team be interested on a complete SWT implementation? Are you offering to provide one? One interesting thing about the eSWT implemenation is that it is based on the UGL API, unlike SWT on the desktop.
Unfortunately, I do not have a ready implementation that I can contribute for the moment. On the other hand we have done some performance comparison for GTK+ implementation of SWT with the UGL based eSWT implementation of GTK+. We found out that there are no significant performance differences between the two approaches. I think it is possible for eSWT & SWT to share the same base implementation. Qt may be possibly be the first shared implementation. The existing code for eSWT Qt is based on UGL, is UGL approach suitable for desktop SWT? eRCP does not really have a mandate/requirement on the approach for the eSWT implementations, for instance S60 and Series 80 implementations are not based on UGL.
UGL is not the preferred approach for the desktop.
(In reply to comment #30) > http://trolltech.com/products/qt/gplexception > > Does it make any difference ? > I'm sure there were more knowledgeable discussions about this elsewhere (unfortunately not on org.eclipse.foundation), but here's my understanding: If *Eclipse.org* wanted to distribute a port of SWT for Qt, there would be *NO LICENCE PROBLEM* anymore with these new GPL exceptions, that explicitly list the Eclipse Public Licence (EPL). Now if any company wanted to distribute (sell) a *commercial product* with these hypothetical SWT/Qt binaries, ie. offer a build for that platform next to their other supported platfoms, they'd have to go and make a deal with Trolltech (whatever that may mean in numbers). The question of course is: who would be financing the port? The SWT team, as far as I can see, is mostly on IBM's payroll. Why would IBM finance it, if they'd have to omit the builds of their products for that platform? I'd say: IBM please! While you're at it big time anyway, why not the QT port?! If IBM really wanted to also offer builds for Qt, maybe Trolltech would even have a good offer, Nokia-owned as they are. That's of course unless Steve Northover & Co. would anyway refuse to support YAPS!, Yet Another Platform for SWT!
I am so looking forward to this.
*** Bug 241543 has been marked as a duplicate of this bug. ***
Qt 3.3.8b comes with the exact same additional rights as Qt 4.x, among others, it is explicitly allowed to link Qt 3.3.8b and EPL/CPL code. With the legal problem out of the way, can somebody publish the code?
Please see thread with subject "SWT for KDE / Qt?" in newsgroup eclipse.foundation for a discussion on the legal implications, and why this requires major legal research (that nobody currently wants to fund).
link to newsgroup discussion mentioned in comment #40: http://www.eclipse.org/newsportal/article.php?id=1727&group=eclipse.foundation#1727
*** Bug 242438 has been marked as a duplicate of this bug. ***
Does LGPL help? http://www.qtsoftware.com/about/news/lgpl-license-option-added-to-qt
Bug should be renamed to QT4/KDE4 implementation of SWT.
I renamed the bug ; is there a chance we can have Qt support for Eclipse ? It would make things easier for SWT I think.
I'm by no means a lawyer. But AFAIK there shouldn't be a problem linking from EPL code to LGPL code, right ? Can anyone with a legal background comment on this ?
How about opening a CQ ?
The LGPL in Qt 4.5 will include some exclusion rule for other open source licenses, it's better to wait for the details before opening a CQ.
(In reply to comment #46) > I'm by no means a lawyer. But AFAIK there shouldn't be a problem linking from > EPL code to LGPL code, right ? Can anyone with a legal background comment on > this ? Please have a look at bug 246945. It discusses the issue of interfacing with libs that are not EPL compatible.
Just FYI, GTK+ is also under GNU LGPL 2.1.
Qt Jambi libary is LGPL now, too. http://labs.trolltech.com/blogs/2009/05/11/qt-jambi-450_01-released-contributors-wanted/
For those of you who are only interested in Form-Based-Frontends (who don't need support for all widget types, custom drawing, ...) you can take a look at my UFaceKit-Project [1,2]. At EclipseCon 09 I showed an E4-RCP-Application running on top of the current E4-Code and the UFaceKit-QT-Jambi-Port (this version is based on the "old" GPL-Release). I'm going to file a CQ for QT-Jambi soon but I think QT-Jambi is not helping us to get a SWT-QT-Port because this should happen at a low-level C-bridge because maintaing QT-Jambi (Nokia is not going to provide funding for it after this release) is out-of-scope for SWT. Besides that there are different philosphies behind QT-Jambi and SWT (QT-Jambi: Rely on Java-Garbage-Collector, SWT: Dipose when not needed) and writting an abstraction of an abstraction (SWT => QT-Jambi => QT) is performance wise a bad idea. The lack of funding from Nokia (IMHO the QT-Jambi-Project will go to end of live with the next major QT-Release) opens the door for Eclipse/SWT to give Java-Developers who want to use QT a new home. [1]http://wiki.eclipse.org/UFaceKit [2]http://www.eclipse.org/ufacekit/
@Tom Schindl: Thank you for this explanation. I will give UFaceKit a try next time I have to create a user interface.
Has there been any progress on a Qt port lately?
(In reply to comment #54) > Has there been any progress on a Qt port lately? Nokia has contributed an eSWT implementation on Qt to eRCP project. Although this is an implementation for eSWT it is a good starting point for the full SWT implementation. eSWT team already expressed interest to work with anyone who would like to complete the implementation to full SWT, sadly no interest so far.
(In reply to comment #55) > Nokia has contributed an eSWT implementation on Qt to eRCP project. Although > this is an implementation for eSWT it is a good starting point for the full SWT > implementation. eSWT team already expressed interest to work with anyone who > would like to complete the implementation to full SWT, sadly no interest so > far. Well I only have mediocre experience with Qt and SWT (and none with the native code used there) but if that's good enough to be of some use to the SWT team I'd be glad to help.
Native code generation is probably the first thing to resolve. eSWT code at the moment does not use code generation for the native parts. I think getting the SWT's code generation working for Qt would be the first step.
Gorkem, do you have a link to the eSWT code?
(In reply to comment #58) > Gorkem, do you have a link to the eSWT code? I found this in /cvsroot/rt. http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ercp/eswt/qt/?root=RT_Project
(In reply to comment #57) > eSWT code at the moment does not use code generation for the native parts. So is _anything_ generated at all or is everything handwritten?
(In reply to comment #60) > So is _anything_ generated at all or is everything handwritten? It is all hand-made, just like grandpa used to make. This code is created by a team that is very efficient with C++ (The earlier eSWT implementation on Symbian was done mostly on C++). The work had to start fast and team did not mind coding the JNI wrappers. Although we did want to integrate the code generator, it never became a priority. Other than a few places where C++ code is used for performance and simplicity, JNI code is very simple and can be generated.
(In reply to comment #61) > Other than a few places where C++ code > is used for performance and simplicity, JNI code is very simple and can be > generated. From opening random files, I'm guessing the "very simple" JNI code is mostly contained in os.cpp file? In case you didn't know, SWT's JNI generator can generate C++ code.
(In reply to comment #62) > From opening random files, I'm guessing the "very simple" JNI code is mostly > contained in os.cpp file? In case you didn't know, SWT's JNI generator can > generate C++ code. correct all the jni calls are in os.cpp file. Back when we have started generator was not able to do C++ code. I know it get modified for Objective-C and either Silenio or Steve commented after those changes that it could be used for C++ as well. However, I do not think it is used for C++ now.
Remy has created bug 290987 for tracking the progress of taking JNI generator into use. He also did some experimentation with encouraging results. Please do follow that report if you would like to help with the work or just interested.
I must admit I'm not current with all developments of the matter. So I really need to ask: is there still any legal barrier against creating a SWT implementation over Qt on Linux? I see none, since both Qt and GTK+ are available under exactly the same license, LGPL 2.1. Ports for other operating systems (Windows, Mac OS) are not interesting because the native look & feel advantage of SWT over Swing is lost in those cases.
Seems like there is already Qt port developed inside Riena project (http://wiki.eclipse.org/Riena_Project) and was presented on EclipseCon yesterday http://www.eclipsecon.org/2010/sessions/sessions?id=1142
As it seems, they are unfortunately only working on a windows port. Some additional information on this project would be of use.
see also bug 318484 .
I'm closing this bug. Whoever is still interested in doing Qt5 port (there is no point in talking about starting Qt4 port now) please open a new bug to start the discussion clean as with that many comments it's not quite clear who/what/when proposed.
