Community
Participate
Working Groups
It would be nice if the LTK UI bundle would not depend on all the compare,editors,team and IDE bundles. I assume it does depend on them to provide the preview viewer for textual changes. However it would be better if the preview viewer could be moved into a separate bundle. That way the LTK UI would be usable inside a standard RCP application.
Are you saying you would want to re-implement the whole preview/compare stuff?
No, Dani. I just do not need it in my case. I am developing a warehouse management RCP. We do not do text changes but for instance changes on orders. I would have to implement my own IChangeViewer anyway (to display a map of the warehouse, or a list of new goods in a tray if you have a goods move change). It would be nice if we could factor the IDE/Editor/Text code out of the base ltk UI bundle, or otherwise I would have to implement my own LTK UI all-together. LTK is very nice. I was about to implement something like that myself. Despite its name, its fitting my domain perfectly well :)
If size of your RCP doesn't matter too much you could simply life with the additional bundles for now. Maybe you have to cut away some unwanted UI contributions though.
This is indeed a very big size overhead. I would rather implement my own very little wizard then to perform the change operations. Or copy the code for the wizards from ltk. Also is it currently possible in LTK to have participants contribute to the UI too? For instance, in my special case, lets say I want the user to decide to reassign a picker to an order after the split process has been performed. The participant would have to let the user choose a picker to assign to the newly created orders and therefore the user should choose one from a listbox/combo. The refactoring process of course does not know about this special requirement of the participant. The UI code that generates the wizard would have to allow the participant to add content to the wizard. I know that participants are in Core and have no access to the UI. However they are supplied with the refactoring parameters. If maybe another extension could create a view binding to the particpant and create additional data for it that it then can use for its change creation?
>Also is it currently possible in LTK to have participants contribute to the UI >too? No, see bug 68609.
Thanks Dani, I have commented to that bug. What do you think of splitting the compare stuff and preview viewer out of the base ltk UI bundle? Would that be possible to do?
>What do you think of splitting the >compare stuff and preview viewer out of the base ltk UI bundle? We'd have to see how much the separation really brings given it was not designed to run in RCP only. For sure not something we plan to do but if someone has time and wants to try it we can take a look at the patch.
I will try to do it and check in a patch
Could the dependencies to the team plugins be set to optional, please? If I try to set up a minimal run configuration the team.core and team.ui plugins are included into the configuration, just because they are not optional. The impact should be minimal.
>Could the dependencies to the team plugins be set to optional, please? Which parts of LTK UI are you using that don't require Team?
I want to set up a minimal launch config for a GMF editor. It requires at least org.eclipse.ui.workbench, which includes org.eclipse.ui.navigator.resources, which has a dependency to ltk.core.refactoring and ltk.ui.refactoring. The same issue there, it would be nice if they don't strongly rely on LTK. However, if o.e.ui.navigator.resources is in the launch config, it pulls the both ltk plugins, which include o.e.team. In my situation I neither want ltk to be included nor the team plugins. The config should really be minimal. I think it would not harm for LTK if the dependency is optional, wouldn't it?
In order to mark a bundle optional, we would have to exactly define which parts of the main bundle still work and which don't if the optional bundle is not present. This is too much work for us to do at this point.
(In reply to comment #12) > In order to mark a bundle optional, we would have to exactly define which parts > of the main bundle still work and which don't if the optional bundle is not > present. This is too much work for us to do at this point. I agree. But to solve Karsten's problem (comment 11), we would only have to touch org.eclipse.ui.navigator.resources.ResourceDropAdapterAssistant and pull out the direct dependencies on the ltk.*.refactoring plug-ins. Then we could make org.eclipse.ui.navigator.resources only depend optionally on the ltk.*.refactoring plug-ins. I won't have time to implement this, but I can review a patch if someone writes one.
