Aujourd’hui, première approche de la problèmatique de la toolbar dynamique selon le plugin chargé.

Pour commencer, première approche du système de gestion des composantes de toolbar, notamment comment espacer deux éléments sans pouvoir spécifier, comme en swing, la colonne dans laquelle tel élément doit être placé. Il faut ici créer un nombre de colonne max et fixer un espacement entre deux éléments éloignés. De plus, les toolItem composant une toolBar ne peuvent pas subir ce genre de manipulation. Il faut donc créer une toolbar, même si c’est pour un seul élement… De ce point de vue là, swing est beaucoup plus flexible et rapide à prendre en main que swt.

En effet, selon le nouvel ihm, il doit y avoir en bas de l’appli une toolbar qui varie selon le plugin affiché. Le problème ici vient du fait qu’il n’existe pas encore dans la version existante d’UBIK de moyen de connître le plugin actif. Dès lors, il n’existe que deux solutions:

Détecter le tab actif dans le tabFolder (le “browser” de plugin). En fonction de cela, on devrait pouvoir détecter le plugin actif, et récupérer une toolbar selon le nom du plugin (qui seront alors détectée en static vraisemblablement)

Ou alors créer une toolbar dans chaque plugin, et dupliquer les boutons communs (prendre la main et full screen). Néanmoins, il y a une perte d’optimisation et le résultat n’est pas franchement le meilleur à mettre en place, même si c’est le plus simple.