Enlil

De OpenESubWiki.

Enlil est un projet de SAD, fondé sur le code d'Enki.

Sommaire

En général

  • toujours basé sur le moteur d'open
  • reprise des fonctionnalités d'Enki
  • prendre en compte le futur temps réel d'openESub 2.0

Architecture

  • séparation core / gui / modules
    • core, c'est le modèle de données d'enlil (zop, soum, etc..)
    • gui, c'est la fenêtre principale
    • trace, c'est juste une interface abstraite vers un module traceur
    • module = dock(s) (graphique) + plugin (code):
      • un plugin, qui est le code du module, qui fait le lien avec le core
      • un ou plusieurs docks, qui sont les mini-gui qui modifient le plugin
      • (voir la partie Interface pour cette notion de dock)
  • créer 2 classes modules abstraite (une pour les docks GUI, un pour les plugin code)
  • séparation des fichiers Dock (Gtk) des fichiers "code" python pur (+gobject)
  • dépendance au gobject de la glib pour les plugins (support des signaux) ?
  • expliciter la déclaration d'un plugin/dock (dans Enki, elle est implictement basé sur le nom du fichier) ?

Installation / Configuration

  • configuration par interface
  • installation dans /usr/local ou c:/program files
  • fichier de conf : ~/.Enlil.conf prioritaire sur Enlil.conf
  • limiter le fichier de conf principal a ce qui est indispensable pour faire marcher Enlil (les paths du moteur)
  • tout ce qui est configurable par interface est décalé dans le .Enlil.conf
  • distinguer le nom du fichier de conf utilisateur sous windows et sous linux (windows n'aime pas les points en début de fichier) (c'est déjà le cas entre le enki "normal" et le enkiexe)
  • utiliser 2 fichiers de conf, le premier a la racine du rep du programme, qui fixe les défaults y compris le nom du fichier de conf "utilisateur". Le fichier de conf utilisateur a la priorité sur le fichier programme

Core

  • Navigation en arbre - concept : les CR sont les "Etats", les ordres sont les "transitions"
  • partie considérée dans son ensemble et non comme des CRs isolés
  • lien générique vers le traceur ????
  • mecanisme de sélection répercuté sur les modules
    • utiliser le même procédé que pour enki (methode 'select_done' dans tous les modules ) ?
    • ou bien plutot utiliser l'évènementiel intégré a gobject ?
  • exploiter la liste de "participants" présente dans le CR
    • => pour un "Etat" donné (un CR), tous les soums sont dans le modèle, mais flagué dead or alive
  • centraliser la gestion des arrondis dans le core
  • utiliser des getteurs et setteurs systèmatiquement
  • notion de "contexte" utilisable par les plugins pour "sauvegarder" des données aditionnelles liée a une situation

(par exemple les sillages, les calques "lourds" types cloche, etc...)

  • notion de log

Core (Détails)

  • classe core =
    • classe de configuration
    • classe scenarioListe
    • accesseurs pour simplifier l'accès au scenatio + CR courant
  • classe scenarioListe
    • liste de classe scenario
    • scenario courant
  • classe scenario
    • donnée : répertoire/origine du scenario
    • pointeur vers la première classe situation
    • accesseurs pour se simplifier la vie ;)
    • données : inhérentes au scenario (zop, participants, etc...)
  • classe situation
    • l'équivalent de la classe CR actuelle, sauf la donnée sur la zop ?
    • liste de classe transition (ordres)
  • classe transition
    • équivalent a la classe ordre actuelle
    • pointeur vers la situation d'origine
    • pointeur vers la situation d'arrivée

Traceur

  • faut il un traceur modulaire ?
    • je pense aux calques, notament
  • utiliser le traceur svg de theFab dans un pixbuf (ça marche)
  • double cloche
  • persistence de la cloche (cas d'un soum "perdu de vu", pour avoir en visuel les différentes positions possibles...
  • filtrer a l'affichage de la cloche les positions impossibles
  • utliser shift/alt/ctrl+clic pour accèler l'accès aux fonctions
  • pouvoir tracer un sillage pour toutes les situations. Acuellement Enki ne le fait que pour les tours simulés. Un sillage est l'ensemble des positions connues des soums et torpilles au cours d'une partie (en prenant compte des minitours pour obtenir un effet plus 'smooth')
  • remplacer les cloches, bruits, sonar, zone d'accrochage, ... par une zone (surface) semi-transparente (en tenant compte des surfaces de recouvrement entre les zones)
  • utiliser un triangle (ou similaire) pour représenter les soums (et leur cap) au moins pour éviter de représenter un vecteur vitesse égale à 0 quand le soum est à l'arrêt (un triangle couvrant l'imprésicion dû aux arrondis me semble un choix intuitivement judicieux)

Interface

  • pygtk
  • usage de glade facilité (mais pas obligatoire) par des objets interface générique
  • gestion de la modularité au niveau de l'interface
  • utilisation d'une barre de status pour signaler les événements (et surtout les non-événements)
  • une zone de log pour donner de l'information sans forcer a fermer une popup
  • Pouvoir appliquer un calque avec des options d'affichage différente pour chaque soum

CR / Sauvegarde

  • Modalité de sauvegarde des simulations ?
  •  ??? versionning des tag xml du CR (pour distinguer positions calculées, position officielle du CR, par exemple)

Suivi et publication

  • Prise de note associé a une partie, a un CR
  • inclure un export png et/ou ps d'un CR
  • générer un fichier ps avec les l'ensemble des CR pour pouvoir facilement "publier" une partie a titre pédagogique

Vrac

  • Moteur inverse
    • pour torpilles (partiellement ok dans Enki, manque la prise en compte de l'accrochage)
    • pour soums
  • Ajouter un module "Facteur" qui affiche les faits (soum bidule blaste truc) ... à rapprocher du log décrit plus haut
  • avertissements anti Round()
Outils personnels