search

bruno-medeiros / MelnormeEclipse

A framework for building Eclipse IDEs
https://github.com/bruno-medeiros/MelnormeEclipse/wiki
7 stars 3 forks source link

Core plugin depends on eclipse UI #8

Closed vladdu closed 8 years ago

vladdu commented 8 years ago

The core plugin depends on JFace and SWT, making it not what one usually thinks of when saying "core" (as opposed to "ui"). If there should be a separation between the two, shouldn't the ui stuff go to the ui plugin?

bruno-medeiros commented 8 years ago

Good catch, yeah, definitely there should be no dependencies on UI/SWT on the core plugin. Good news is that it's just one class that slipped through (AbstractAutoEditStrategy), so should be easy to fix, willl do it soon.

bruno-medeiros commented 8 years ago

Actually, no, there a few more classes, depending on org.eclipse.jface.text ..

bruno-medeiros commented 8 years ago

Well, I just commited https://github.com/bruno-medeiros/MelnormeEclipse/commit/95c9bce6379863b197bbedc41d0dc1e058029305, which removed a direct dependency on SWT code from the core plugin.

However, to my surprise, the org.eclipse.jface.text and org.eclipse.jface plugins, which the core depends on, depend indirectly on SWT, even though they are utilities about text and preference related code (such that in theory they shouldn't depend on SWT...)

vladdu commented 8 years ago

Yes, jface.* are UI plugins, unfortunately. They contain even things like ApplicationWindow, dialogs and wizards. The only way that I found to not depend on jface is to more or less duplicate the API classes (like ICompletionProposal) and let my core plugin use those, while converting to JFace classes in the ui plugin. I wish there was a nicer way...

bruno-medeiros commented 8 years ago

Yeah, I was half-way doing stuff like, for example DocumentCommand2 in commit https://github.com/bruno-medeiros/MelnormeEclipse/commit/b1806e538df40e98270da32855af23ae5a030504 is simplified version DocumentCommand which is in JFace.

For the partitioning code and partitioning rules, I didn't bother, I just moved that code back to UI plugin. (In any case, for some of the IDEs with complex parsing rules, for that there's melnorme.lang.ide.ui.text.AbstractLangScanner.LexingRule_RuleAdapter that adapts the IRule to a class in the ".tooling" plugin)