Intégrer le SpellChecker

Bonjour,

J'aimerais intégrer le plugin SpellChecker d'Eclipse à mon application RCP.

Je constate que ce plugin est lié à JDT et je n'ai nullement besoin de ce dernier, donc je me demande quelle stratégie adopter pour l'intégrer sans que ça ne m'ajoute des fonctionnalités non requises.

Je suis sur un plateforme 3.7 et le plugin concerné principalement est org.eclipse.jdt.ui.

Ce plugin n'est malheureusement pas rendu générique au niveau de son moteur de vérification orthographique, puisqu'à l'origine il scrutait avant tout les sources Java. Et depuis, il n'a visiblement pas été refactoré.

Dans ce cas que vaut-il mieux faire ?

1 - Récupérer les sources du bundle en question, les intégrer à un plugin personnel et faire le ménage de tout ce qui n'est pas nécessaire.

2 - Référencer normalement le plugin et faire en sorte de masquer ou désactiver, par divers mécanismes (j'ignore lesquels exactement), les éléments non souhaités.

3 - Autres solutions ?

Merci d'avance pour votre aide.

Salut Laurent,

Quelques petites questions (avant de répondre aux tiennes :D):
- Quel est l'identifiant du plug-in SpellChecker? J'ai regardé dans les plug-ins ayant une dépendance vers org.eclipse.jdt.ui mais je l'ai pas trouvé... J'ai du passé à côté.
- Est-ce que tu as regardé du côté du plug-in org.eclipse.ui.workbench.texteditor? Il a l'air de proposer un moteur de correction (cf la classe org.eclipse.ui.texteditor.spelling.SpellingService).

Ensuite, je dirais que tout est une question d'impact...
Concernant la première hypothèse, il te faudrait essayer d'importer les sources et de supprimer la dépendance vers org.eclipse.jdt.ui pour constater les impacts. Mais même comme ça, le plug-in peut avoir une dépendance tierce qui va quand même dépendre du plug-in JDT UI. Bref, c'est pas évident de constater le travail à faire au premier coup d'oeil.
Pour la seconde hypothèse, c'est pas forcément très pénible de masquer des fonctionnalités, mais ça t'oblige, à minima, à utiliser des classes internes d'Eclipse. Et c'est "moche". Car elles sont soumises aux évolutions d'Eclipse et donc peuvent rendre les portages / évolutions de ton appli RCP potentiellement pénibles. Pour ma défense, j'ai pas trouvé de meilleures méthodes (que d'utiliser des classes internes).
Pour le troisième point, voir les questions plus haut :D Voir si tu peux utiliser le plug-in org.eclipse.ui.workbench.texteditor. En plus, tu peux récupérer une instance de ce SpellingService facilement, il te suffit d'utiliser la classe EditorsUI (dans le plug-in org.eclipse.ui.editors): EditorsUI.getSpellingService(); et le tour est joué.

Voilà, à+
Gueritarish

Merci pour ta réponse.

Citation:

---

Envoyé par Gueritarish

- Quel est l'identifiant du plug-in SpellChecker? J'ai regardé dans les plug-ins ayant une dépendance vers org.eclipse.jdt.ui mais je l'ai pas trouvé... J'ai du passer à côté.

---

En fait, dans ce plugin, il y a l'implémentation du moteur par défaut, au niveau du package org.eclipse.jdt.internal.ui.text.spelling.
Donc, lorsque l'on ajoute la dépendance vers le plugin, on peut voir apparaître le contenu de la page de préférences General > Editors > Text Editors > Spelling mais aussi disposer du mécanisme dans pas mal d'éditeurs, comme mon éditeur XML customisé.
On voit bien sur cette page qu'il est fait référence au langage Java. Or, logiquement à cet endroit, ça ne devrait pas être le cas puisque ça concerne potentiellement plus d'éditeurs que ceux liés au langage Java...
Mais bon, c'est ainsi.
Quand le plugin n'est pas référencé, la page de préférences existe mais elle est vide.

Citation:

---

Envoyé par Gueritarish

- Est-ce que tu as regardé du côté du plug-in org.eclipse.ui.workbench.texteditor? Il a l'air de proposer un moteur de correction (cf la classe org.eclipse.ui.texteditor.spelling.SpellingService).

---

Non, je n'avais pas spécialement regardé ce plugin mais celui-ci est évidemment nécessaire à celui que j'indique précédemment.

Donc, sans doute faut-il s'inspirer de ce qui est fait dans org.eclipse.jdt.ui pour implémenter un moteur de spelling adapté à son besoin mais effectivement, il faut parvenir à supprimer les dépendances inutiles, ce qui peut potentiellement s'avérer délicat

Citation:

---

Envoyé par Gueritarish

Pour la seconde hypothèse, c'est pas forcément très pénible de masquer des fonctionnalités, mais ça t'oblige, à minima, à utiliser des classes internes d'Eclipse. Et c'est "moche". Car elles sont soumises aux évolutions d'Eclipse et donc peuvent rendre les portages / évolutions de ton appli RCP potentiellement pénibles.

---

Mon application en est déjà remplie ! Et d'ailleurs, le passage de la plateforme 3.4.1 à 3.7.2 ne m'a pour l'instant pas semblé être problématique, donc c'est sûr qu'il faut avoir conscience des problèmes que ça peut poser mais visiblement y a de la marge. Quoi qu'il en soit, ça n'est pas un frein dans le contexte qui est le mien.

Citation:

---

Envoyé par Gueritarish

Pour le troisième point, voir les questions plus haut. Voir si tu peux utiliser le plug-in org.eclipse.ui.workbench.texteditor. En plus, tu peux récupérer une instance de ce SpellingService facilement, il te suffit d'utiliser la classe EditorsUI (dans le plug-in org.eclipse.ui.editors): EditorsUI.getSpellingService(); et le tour est joué.

---

Comme je l'expliquais, à partir du moment où j'ai le plugin org.eclipse.jdt.ui avec ses dépendances que voici :
http://www.developpez.net/forums/att...1&d=1343205025
http://www.developpez.net/forums/att...1&d=1343205287
Je n'ai rien d'autre à faire que de masquer ce qui n'est pas utile comme les éléments de JDT.

Comment puis-je faire cela ?

A mon avis, tu devrais, peut-être, tenter de voir l'implémentation JDT et d'essayer de créer la tienne à partir de ça (avec le plug-ni org.eclipse.ui.workbench.texteditor). J'ai regardé (vite fait), ça n'a pas l'air trop compliqué (mais c'est facile à dire :P).
Sinon, pour enlever des menus qui te gène, le mieux, c'est de passer par un IPerspectiveListener (pour s'assurer que tout est bien chargé).
Dans la méthode perspectiveActivated(), tu vas pouvoir faire:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

IWorkbenchWindow iww = PlatformUI.getWorkbench().getActiveWorkbenchWindow(); WWinActionBars mainBars = null; IMenuManager mainMgr = null;   if (iww instanceof WorkbenchWindow) { WorkbenchWindow ww = ((WorkbenchWindow) iww); mainBars = ww.getActionBars(); mainMgr = mainBars.getMenuManager();   // Suppression de menus: IContributionItem[] items = mainMgr.getItems(); for (IContributionItem item : items) { if ("org.eclipse.search.menu".equals(item.getId())) { item.setVisible(false); } }   // Suppression des "fils" du menu File: IMenuManager fileMenuMgr = mainMgr.findMenuUsingPath("file"); // Même méthode que précédemment... IContributionItem[] fileItem = fileMenuMgr.getItems();   mainBars.updateActionBars(); }

---

Voilà, à+
Gueritarish

Bon, j'imagine qu'il ne suffit pas de créer une classe et de lui faire implémenter l'interface IPerspectiveListener pour que ça fonctionne ?

J'ai tenté de voir comment c'était fait au niveau d'autres classes qui implémentent cette interface mais bon, je n'ai pas compris comment c'était exploité ensuite. De ce que je vois, ça ne se passe pas dans le fichier plugin.xml, ou alors je n'ai pas regardé dans le bon.

Je ne connais pas grand chose à la plateforme malheureusement, faudrait que je me forme, c'est sûr...

Alors, je suis naze :D
Je te donne la moitié des infos... Donc, bien sûr il faut que ta classe implémente IPerspectiveListener, l'étape d'après consiste quand même à utiliser ta PerspectiveFactory ou ton Application pour ajouter ce listener à la liste qui va bien:

Code:

---

PlatformUI.getWorkbench().getActiveWorkbenchWindow().addPerspectiveListener(myLystener);

---

Pense au removePerspectiveListener() à la fermeture de ton application.

Voilà, à+
Gueritarish

Alors ce qu'il y a c'est que je n'ai pas de perspective spécifique, c'est Resource qui est utilisée.
Quant à la classe de type Application, je n'en ai pas non plus.
C'est normal selon toi ? Je dis une bêtise ? (je ne suis pas à l'origine de l'application)

Bon, de toute manière, ce n'est pas seulement une histoire de Perspective car dans les préférences générales on retrouve aussi des rubriques propres à JDT et qu'il faudrait faire disparaître.

Alors, ce n'est pas un RCP :D
Du coup, c'est un peu plus compliqué pour pouvoir faire ce que tu souhaites. Mais ça reste faisable ;)
Il te faut:

• ajouter une dépendance vers org.eclipse.ui.ide.application.
• ajouter un point d'extension org.eclipse.core.runtime.applications (renseigne son ID) ainsi qu'une extension application et ajouter un run.
• créer une classe qui hérite de IDEApplication pour ce run.
• créer un product (tu en as peut-être un). Dans ce product, dans la partie "Product Definition" (dans l'onglet Overview), tu sélectionnes l'application que tu as créé dans la combo Application.

Après, il te "suffit" de surcharger les méthodes start(IApplicationContext appContext) et stop() pour ajouter ton code.
Sinon, pour enlever une préférence du gestionnaire, c'est :

Code:

---

1 2	PreferenceManager manager = PlatformUI.getWorkbench().getPreferenceManager(); manager.remove("id.preference");

---

Voilà, à+
Gueritarish

J'ai quand même un plugin où il y a la dépendance vers org.eclipse.ui.ide.application et où il y également le .product.

L'application est censée pouvoir être installée sur un Eclipse normal mais aussi en standalone. Si ça peut expliquer des choses...

Merci, je vais essayer d'implémenter tout ça selon tes indications.

Salut Laurent,

Je suis tombé sur les activities ce matin. Feature dont j'ignorais totalement l'existence (merci sam9722). On tombe pile dans ton domaine d'application. Bon, le revers de la médaille, c'est que tu as sans doute déjà implémenté pas mal de truc :?

Voilà, à+
Gueritarish

Oui, merci, en fait entre temps je suis tombé dessus et ça résout effectivement la plupart des cas pour parvenir à faire disparaître les éléments que l'on veut masquer.

Bon, ce n'est pas particulièrement trivial comme façon de faire car il faut quand même saisir que l'on détourne le rôle d'une Activity, juste pour pouvoir lui "coller" des éléments (View et dérivés) que l'on veut masquer. A l'inverse de son rôle d'origine, on n'active jamais cette Activity et ainsi, les éléments restent masqués (sauf contre-ordres possibles de différentes manières).

C'est donc un peu tordu à mon sens comme principe. De plus, il faut être précis dans l'élaboration des patterns des activityPatternBinding que l'on définit car on a vite fait de supprimer plus de choses que nécessaires.

Allez, on va dire "problème résolu" ;)
Merci encore