Community
Participate
Working Groups
3.1 M4 SWT should be as seamless to compile against and run with as Swing. The way to go is a SWT container that can be added to the build path for compiling and also has the dll location attached so that the default 'Java application' launch configuration can be used (this would eliminate the SWT application launcher) We would like to offer this SWT container as part of JDT (or PDE) so it is contained in the platform build of Eclipse. VE already has a SWT container that implements exactly what is wanted, and more. It has the following features: You can specify either to - use the SWT.jar from your current development instance of Eclipse - or using the PDE plugin lookup - or use a custom location DLL's can be inside a packaged JAR; the container keeps extracated native libraries in an internal folder while in use. Additionally the container can also specify to contain the JAR's of JFace (and all its prerequisits). What we had in mind was a bit simpler; No PDE location and no JFace support. JFace support looks to be the wrong thing to have in an SWT container. (Wouldn't clients better use RCP and the Eclipse plugin model (-> PDE container) when using JFace? It also seems to me also that this container would be broken as soon as JFace would e.g. require a new plugin as prerequisite) Implementing a second simpler SWT container in JDT UI would definintly look bad and confusing. Gili, what do you think about moving your container down? I suspect that simplifying the container is not an option for you. I guess we would have to introduce a new plugin that has PDE dependency or integrate this container into PDE altough it is not really part of the plugin development (but uses the PDE functionalty to find and process the SWT JAR)
I think that pushing the container down is the right approach. In regards to the JFace option, given that JFace is a separate download; including the right jars would be desired. Also, it is very likely that a user may be developing on a target that is different than the running (Platform) one. E.g., IDE is 3.1, while developing on a 3.2 environment. This is the reason the VE SWT Container provides the ability to work with that PDE target. If you are in a Plugin environment, though the PDE dependency container provides all the .jars. It does not provide access to the .dlls. This is not a problem if you run/debug a whole RCP app. But it is a problem if someone adds a “main” and tries to run/debug a custom composite. They need to “run as SWT”. … be nice if the PDE dependency container contribute those .dlls by default.
Veronika has the details about this. I'll get her to add them to this bug report.
In reply to comment 1: I definitly see that it's convenient to have PDE and JFace support all in one, what I don't really like is that this mixes some of the concepts and gives them the wrong names. JFace isn't part of SWT but above it. Plugins and PDE are a different world than the SWT container and you have to make a clear choice when developing (RCP or Java application). Therefore, the SWT container should not really depend on PDE. But I guess we could close both eyes here. But if you have space for simplifications, I think I would favour to be conceptionally clean, especially as we make it part of the platform. Also note that JFace isn't a deparate download yet (but there are requests). Until this is the case I would rather stick on pushing RCP.
Veronika, what are your requirements?
What I would like to see is a seamless way for an application to compile against and run with SWT. Ideally, as seamless as something that is part of the JDK. Erich had talked about providing a quick fix to address compile concerns. This is not quite as seamless as how Eclipse treats the JDK but it is better than what we have today. A special launcher is not sufficient because there are many cases where you may wish to use SWT and we do not want to require a special launcher for each of them -- For example, running a JUnit test that involves SWT is not satisified by the Run as SWT Application launcher.
I think that we can fulfill these requirement with the SWT container. The SWT container will eliminate the SWT launch config. Now, VE-team, how should we proceed? As mentioned, the PDE dependency the JFace feature are the things we would like to drop. 1. Conceptionally, I think we should clearly separate the two worlds. If your into PDE or JFace, you should use the PDE container that knows how to find the swt or jface plugin. If standalone JFace is a highly requested feature (and when we offer a download for it), we should maybe better call the container a JFACE container. 2. Implementation: We thought of adding the SWT container into JDT.UI. If the PDE feature is kept, then we can't do that but maybe PDE wants to integrate the container. Or we request a new plugin. This new plugin would require PDE and not work with a pure platform JDT installation (Which of course is probably not a real problem)
We have to defer this item. I really need feedback from VE to reach a consensus. I don't want to introduce a second SWT container and mess up their story. I see two solutions: - extract VE's SWT container as-is to a new plugin. That plugin has PDE (and JFace) dependency. That will be a hard thing to sell to the PMC. - introduce a new container in JDT that only supports specifying a SWT-library path (no PDE, JFace). A extension point could open the container to extra arguments so that VE can keep the container compatible, if that's a must.
>- introduce a new container in JDT that only supports specifying >a SWT-library path (no PDE, JFace). Why not do this?
All products that include the VE plugin would present 2 SWT containers in the list of containers.
We need to speak with a representative from VE ASAP to get this resolved. Is there someone on this bug report who can represent VE and if not, Martin can you add one? We would really like to see VE use the solution provided by the SDK.
I thought Gili and Rich are in the VE team, they have been on the bug report since the beginning.
Gili and Rich, can you please comment. Martin, could you add this to an integration build so we can try it out to iron out some of the issues with other components. We can always take it back out if we can't make it work but the clock is ticking and we would really like to explore this avenue for 3.2. Maybe it could be in a separate download for now and we can try it out before making it part of a build.
I have't implemented anything myself yet. But just install the VE plugin. - create a new project - on the buildpath page add library, SWT Container - use normal launcher to run or debug
The big problem is the VE SWT container does many things that you said you didn't want to do. We need those things to perform correctly. We could probably handle splitting out JFACE though we don't want to because most people really DO think of SWT and JFACE together. They don't think of them as separate entities. Also JFace does now work standalone outside of Eclipse. Maybe it hasn't be published as such, but the defect to make it standalone has been completed. But we do need to be able to point to PDE target SWT or even a standalone SWT. This is because the SWT that is being used by the IDE (what we call Platform) is not necessarily the SWT that the user wants to use. The requirement for PDE could be changed into an optional. If not there, then it would not provide the PDE target capability. When we are using the PDE we are not using it for RCP plugins, we are using it to provide the SWT for a runtime non-RCP application. Much like installed JRE's. We aren't using SWT containers with plugins projects, that is straight PDE. But we are using PDE to determine the SWT to use when the user wants to use the SWT out of the target platform. Without these capabilities an SWT container provided by you would be a problem to us and would conflict with us. It would be confusing to the user because we would have to them remove the SWT container you provide and instead have ours.
For the SWT team we also want to be able to point the SWT Container to either the one used by the eclipse version you are running (this would be the default) or one in the workspace or one in some external SWT standalone download. I think there will need to be a preference page that can configure the location of the SWT jar/dlls - much as there is a preference page for the JRE Container. I believe launching Eclipse from Eclipse or running an RCP application will not make any use of the SWT container and will not be affected by the presence of an SWT container. The only thing mentioned in Comment #14 which SWT does not want is the JFace dependency. Could there be a separate container for JFace? If you have JFace in the SWT container, and there is no JFace in the location where there is standalone SWT, what happens? Is JFace going to have standalone downloads (nightly, integration, milestone) the same way SWT does?
As for JFace, we could tolerate having a similiar but separate container that was only for JFace. It is just very convienent to have them together because that is the way most users think of it.
If PDE support is important, then JDT can't offer this container. Maybe PDE is interested in taking over.
What do you mean by PDE support? All we are looking for is the ability to find the SWT jar and DLLs that come with the Eclipse install.
I would call it PDE as soon as the PDE lookup path (workspace, target location) has to followed. To just find the swt archive in our own eclipse installation should be doable without the complete PDE knowledge (but would help of course as well). A minimal SWT cotainer would offer that and a user interface to browse for a swt archive.
Any hope?
Deferred from the JDT UI standpoint. It would be great if VE could split off their container and add it as a separate plugin to the SDK build.
This one makes me particularly sad, seeing as we never ask anyone for anything and this is the only Eclipse item on the SWT wish list for 3.2.
*** Bug 138792 has been marked as a duplicate of this bug. ***
Martin, would it be ok if we reopen this and give it a target milestone of 3.3? Having it marked as "Resolved - Later" is a problem because it does not appear in searches on open bugs. Thanks.
I personally don't think people confuse SWT and JFace. Perhaps the VE team have confused JFace with SWT if they are putting the JFace libraries in an SWT container :-) Having two containers (one for SWT, one for JFace) would make sense; if PDE/VE needs more then they can be added at a later stage. The problem seems one of 'who is going to provide this?' which is an inward question. I think that the real benefit is to the end users who want to write SWT applciations -- and from their point of view, it doesn't really matter who provides it. It certainly shouldn't have to rely on VE to be installed to work; nor PDE, for that matter. If I download the JDT, and I have the action 'Run as SWT application', then I would hope to see an SWT library in the user libraries of the classpath. Given that JDT-UI implicitly deals with launch configurations and the menu items to 'run as SWT applciation', I think that JDT-UI should provide this user library. I don't think VE's (in)action on this bug should stop this bug from going forwards for 3.2. Heck, if it's just a naming issue, why not call it REAL_SWT and use that instead? Or ONLY_SWT? If it's just that VE have already used a name with the characters S, W and T so far, then it seems to me that both are perfectly doable by using a different name. Alex.
The idea of this bug is to get rid of 'Run as SWT application'. :) JDT UI has already said they could provide an SWT container. But it's a non-trivial issue and they need to coordinate with VE, so at this point it has to be deferred.
We have this for SWT and JFace in VE today. Download VE and get rolling. If folks want this to be pushed down into JDT, I'm sure it could be done. The code is there.
I would like to try reopening this again for eclipse 3.3. Perhaps someone from JDT UI can review what has been done in VE. This is the one thing that SWT keeps trying to ask for in eclipse.
I'm glad that someone else gets as bugged with the RESOLVE NEVER as I do :-) I'm glad that this was reopened. Maybe there's a slight possibility that it will actually get processed, but I'm not holding my breath.
(In reply to comment #29) > I'm glad that someone else gets as bugged with the RESOLVE NEVER as I do :-) > I'm glad that this was reopened. Maybe there's a slight possibility that it > will actually get processed, but I'm not holding my breath. Right now, VE is extremely strapped for resources (I'm no longer speaking as VE leader, just as an interested observer). Would you be willing to help make the changes in VE? Joe Winchester is the new VE leader; as long as I've known him, he's been really enthusiastic about helping new people get up and running. If you'd like, I'd be happy to make the introduction.
I'm willing to help out where I can, but it seems to me this is more of a communications issue between teams than anything else. VE currently provides it, JDT want it -- isn't it a case of just agreeing that the SWT and JFace containers would be better in JDT and then making it happen? Anyone from JDT or VE care to comment? And yes, I'd seen you'd moved on; congratulations. I'd have put it as a comment on your blog, but you don't allow them. You're almost as bad as Bjorn :-) Alex.
Joe: in comment 31, Alex indicates that if there's a way he can help VE with the work we need to do to resolve this bug, he might be interested to help. Could you help him get up and running? Alex: > And yes, I'd seen you'd moved on; congratulations. I'd have put it as a comment > on your blog, but you don't allow them. You're almost as bad as Bjorn :-) Thanks. :-)
We hacked SWT to extract the DLL from the JAR (even though no Java application on the planet does this). I'm bitter, but ready to move on.
Steve, How does this affect whether there's a JDT container for SWT or not? Alex.
Steve, Did you mean to put your last comment on this bug against bug 166865 instead, and if so, did you mean to close that one, rather than this one? In which case, can you re-open this one? Alex.
2 questions: 1 - Is there a open bug to provide a standalone JFace jar download? 2 - Regarding the JFace need, in my experience, it is impractical to use only SWT without JFace. If you use Trees, Tables or Combos, you *** need *** JFace viewers. It is impractical to use these raw controls. I see SWT being the native raw integration, and the JFace being like the MVC part of Swing, so they are complementary.
There should be no changes at all necessary to anyone from Eclipse, other than using 'Run as Java Application'. JDT will not need "Offer a SWT container in JDT" so this bug is WONTFIX.
Another way to accomplish this effect (that works today) is: * Paste the SWT snippet * Right-click the project -> PDE tools -> Make plug-in project * Open the manifest in the manifest editor * Add SWT (or org.eclipse.ui if you want JFace) as a dependency and save This works well for me. Maybe it could become the preferred documented solution for everybody?
The one advantage of having a SWT (or JFace) container is that you don't need to know what version of Eclipse you're running on. At present, you end up with e.g. /path/to/my/org.eclipse.swt_1.2.3.jar in the .classpath and thus it makes it fragile because you can't store that in a version control system or can cause problems when upgrading, even to the next point release. It's not really about 'running' as Steve puts it, but about setting up the classpaths so that it will compile and have a platform- and version- independent qualifier in the .classpath The other approach is to define an SWT variable, like JUnit does, so that you can use the variable instead. It would have been cleaner to provide this as a container that could be added directly, but a variable will work just as well. The problem with Dave's approach (#38) is that whilst it would work, it involves all sorts of other hastle, not the least of which is that the META-INF/MANIFEST.MF can't be relocated within the project; and almost all Java projects use some variant of 'src/resources' to store all the runtime resources in. So I can't see people who have directories structured wanting to be limited to the inflexibility of PDE's layout -- but there's a different bug for that, and the only reason for mentioning it is that it effectively blocks #38 from being a general solution that everyone can buy into. With the target JREs taking more of a high profile in Eclipse (e.g. replacing target platform), why shouldn't the same apply to SWT and JFace? Steve's reason for closing it seems to be entirely focussed on the fact that run-as-SWT-app doesn't need this; therefore, there is no other for needing this. I disagree with that point of view.
(In reply to comment #38) > Another way to accomplish this effect (that works today) is: > > * Paste the SWT snippet > * Right-click the project -> PDE tools -> Make plug-in project > * Open the manifest in the manifest editor > * Add SWT (or org.eclipse.ui if you want JFace) as a dependency and save > > This works well for me. Maybe it could become the preferred documented > solution for everybody? > This works, but why I have to turn my project into a plugin project just to get the jars? Sounds like to kill a bug with a nuclear bomb.
(In reply to comment #40) > (In reply to comment #38) > > Another way to accomplish this effect (that works today) is: > > > > * Paste the SWT snippet > > * Right-click the project -> PDE tools -> Make plug-in project > > * Open the manifest in the manifest editor > > * Add SWT (or org.eclipse.ui if you want JFace) as a dependency and save > > > > This works well for me. Maybe it could become the preferred documented > > solution for everybody? > > > > This works, but why I have to turn my project into a plugin project just to get > the jars? > > Sounds like to kill a bug with a nuclear bomb. <LOL/> Yeah. Maybe. After 4 years of programming in Eclipse, using just a plain old Java project (compared to a PDE project) makes me feel naked. PDE is just so much easier. :-) FWIW, I almost never use regular Java projects any more.
