Liste initiale avant "écrêmage"; tout là-dedans n'est pas forcément assez important pour être mis en avant dans la comm, mais certains points peuvent quand même intéresser des gens ici:
- #442268 SVG images not properly displayed
Si vous utilisez des SVGs (les vôtres ou certaines formes de base de Sirius), ils seront maintenant rendus proprement quel que soit le niveau de zoom. Auparavant le rendu SVG => bitmap se faisait toujours en une seule taille, et c'est ensuite le bitmap qui était scalé (perdant tout l'avantage de la nature vectorielle de SVG). Par contre il n'y a pas de magie, il y a un compromis entre perfs et occupation mémoire. Une nouvelle propriété système org.eclipse.sirius.diagram.ui.svg.maxCacheSizeMB (documentée uniquement dans les release notes) est disponible pour tweaker la taille du cache utilisé, qui est à 50 par défaut (soit 50MB).
- #459993 Add support for internationalization (I18N)
Pour Sirius 3.1 on avait rendu toutes les UIs de Sirius lui-même internationalisables. Avec 4.0 vous pouvez maintenant faire des modeleurs complètement interationalisables: dans vos VSMs vous verrez certains champs apparaître avec un fond bleu. Ils correspondent aux éléments de vos VSMs (non interprétés) qui seront visibles des utilisateurs finaux (par exemple: nom des points de vue, des layers, des tools, etc.). Si vous mettez une valeur de la forme %maCleUnique, au runtime Sirius ira chercher la valeur à afficher dans le plugin_XX.properties correspondant à la locale courante, ou dans plugin.properties par défaut. Les plugin_XX.properties peuvent être directement dans le plug-in du modeleur ou dans des fragments OSGi développés et déployés séparément.
- #481573 Provide an extensible mechanism to allow developers to customize the diagram tabbar
Un nouveau point d'extension (org.eclipse.sirius.diagram.ui.tabbarContributor) permet de contrôler intégralement le contenu de la tabbar, y compris retirer ou réordonner les éléments fournis par défaut par Sirius (en plus de rajouter les siens qui était déjà possible via un autre point d'extension. Voir la doc développeur pour les détails.
- #482528 Add support for properties view specification
C'est encore expérimental en 4.0, et pas installé par défaut.
- #482831 Make it easier to leverage EMF.Edit customizations from Sirius representations
Sirius 4.0 fournit en standard la classe org.eclipse.sirius.ext.emf.edit.EditingDomainServices qui fournit de nombreuses méthodes (58) pour accéder facilement dans vos expressions (AQL par exemple) aux diverses fonctionnalités standard d'EMF Edit, par exemple les label providers, property descriptor (getChoiceOfValues()), etc. Si vous voulez l'utiliser il faut pour l'instant la déclarer explicitement dans vos VSMs comme n'importe quelle classe de service, c'est juste qu'elle est fournie par Sirius (ne pas oublier de rajouter le plug-in org.eclipse.sirius.ext.emf.edit dans vos dépendances si vous l'utilisez).
- #483459 Make sure Sirius 4.0 is compatible with Neon
Sirius 4.0 est officiellement compatible Mars et Neon, Neon étant la plateforme de référence (pour OD en particulier). Voir cette annonce pour les autres changements en terme de compatibilité. En résumé:
-
Java 7 minimum. On ne passera à Java 8 que quand Mars sera abandonné.
-
Semi-abandon de la compatibilité Juno, Kepler et Luna. Pour l'instant ça compile toujours sur ces plateformes, mais on s'autorisera à casser cette compat sans préavis dès qu'on aura une bonne raison technique de le faire.
-
Du point de vue de tous les utilisateurs sauf Capella, il faut considérer que le support d'Acceleo 2 (Query Legacy) est abandonné. AQL est toujours techniquement optionel mais est la solution recommandée.
-
#491208 Provide an easy way to move in all directions for large diagrams
Il est maintenant possible de scroller dans les diagrammes par clic-drag du bouton du milieu de la souris ("à la Google Maps" mais avec un autre bouton).
- #440296 Specify border nodes side in the VSM
Les border nodes peuvent maintenant être configurés pour n'être positionnable que sur certains côtés de leur parent (nord/sud/est/ouest ou n'import quelle combinaison).
- #442133 Closing a large session can take a very long time
La fermeture des sessions un peu volumineuses pouvait prendre beaucoup de temps, mais devrait maintenant être quasi-immédiate, car on ne perd plus de temps (et de mémoire) à décharger explicitement toutes les ressources (qui vont être abandonnées juste après de toute façon). Si vous utilisez des métamodèles ou configurations de session un peu "exotiques", ce changement peut vous impacter. Il y a un point d'extension pour vous permettre de prendre la main et de faire les éventuels nettoyages dont vous avez besoin et qui ne se feront plus tout seuls.
- #458751 Make dependency to JDT optional
Le runtime de Sirius n'a plus de dépendance au JDT (la partie "specifier" avec les éditeurs de VSM en dépend toujours). Cela devrait permettre de faire des "products" plus légers.
- #481025 Border on non-rectangular svg file based style should not be drawn following the selection bounds
Le titre n'est pas forcément très parlant, mais dans le cadre de ce ticket un nouveau point d'extension a été rajouté qui vous permet d'étendre la liste des "Basic Shapes" disponibles sur les Nodes avec vos propres SVGs, au-delà des square/dot/triangle/etc. de base. Si vous suivez quelques règles pour encoder vos SVG (voir la doc), Sirius sera capable de leur appliquer les couleurs et tailles de bordures définies dans le VSM.
tl;dr: vous pouvez faire des plug-ins qui contribuent des bibliothèques de formes ("stencils") sous forme de SVGs.
- #489001 Embed AQL (and ANTLR) directly in the Sirius update-site
Les repositories Sirius (e.g. http://download.eclipse.org/sirius/updates/milestones/4.0.0rc1/neon/) incluent directement les JARs d'AQL (et ANTLR). Plus besoin d'enregister explicitement un update-site Acceleo pour y avoir accès quand vous installez le support AQL de Sirius.
- #486654 Add typed variable capability in variable filter
Les filtres (sur les diagrammes) peuvent maintenant être configurables par autre chose qu'un élément de modèle sélectionné par l'utilisateur. Par exemple il est possible de faire un filtre qui quand il est activé demande une chaine (ou un nombre, ou autre chose) à l'utilisateur et utilise cette chaîne dans son expression de filtrage (comme une regexp par exemple).
- #493330 Warn specifiers if any RepresentationDescription in their VSM lacks explicit metamodel setting
En 4.0, si vous n'associez pas explicitement de métamodèle à vos Representation Description, la validation du VSM lèvera un warning. C'est un changement relativement mineur en soit, mais je le mentionne car c'est une première étape qui en annonce d'autres à venir sur ce sujet. On va progressivement aller vers un mode où: 1) enregistrer les métamodèles sera obligatoire, et 2) Sirius se basera exclusivement sur ces infos pour tout ce qui concerne la completion/validation/évaluation d'expressions, de domainClass, etc. Actuellement chaque mécanisme qui a besoin de ces infos a plus ou moins sa propre magie/ses heuristiques, ce qui conduit à pas mal de complexité et d'incohérences. Le but est de (progressivement) forcer le specifier a être plus explicite afin de pouvoir être nous même plus fiables et cohérents (et peut-être un peu plus performants sur certains points).