====== Notes du dév' ======

Voir aussi : [[web:notes|Développement du site web]]
===== Reliquat de la 0.2 =====
Tâches non effectuées lors du développement de la 0.2 (cf [[notes_0.2|Notes pour la version 0.2]]) :
  * copier/coller entre projets : import automatique des éléments ?
  * Implémenter la possibilité de recharger partiellement le panel d'éléments puis lier cette fonctionnalité à la suppression, la création, le déplacement et la copie d'items via le panel d'éléments. L'ajouter également dans le menu contextuel.
  * Ergonomie : dans l'éditeur d'élément, l'utilisation des touches Ctrl (travail en coordonnées libres) et Shift (conservation de l'outil en cours) dans une moindre mesure n'est pas intuitive.
===== Notes pour la 0.21 =====
%%TODO%% :
  * [ok] Faire le point sur tout ce qui est améliorable pour la 0.21 => voir Changelog ci-dessous
  * [ok] Tenir à jour le [[doc:changelog_0.2_0.21|ChangeLog de la version 0.21]]
  * [no] Finir le guide de démarrage rapide ? Non, ce ne sera pas prêt pour la 0.21
  * [ok] Améliorer l'installeur Windows :
    * Réduire le nombre de langages proposés à ceux également proposés par QElectroTech, pour la cohérence
    * Placer la configuration dans le home de l'utilisateur, et non plus dans le dossier d'installation
    * Proposer la mise en place des associations de fichiers
    * [no] Intégrer le guide de démarrage rapide au niveau des raccourcis générés => non disponible
  * [ok] Test de l'application avec Qt 4.4.x, 4.5.x et 4.6.x : 
    * code adapté au nouveau comportement de Qt 4.6 par rapport à la méthode QGraphicsItem::itemChange(...).
    * modifications dans les classes QETTabBar et QETTabWidget testées avec Qt 4.4
  * [ok] Virer "titre du document" dans le cartouche ?
  * [ok] Faire le point sur les bugs de rendu connus :
    * Éditeur de schéma : problème de repaint en dehors du sceneRect => [[http://bugreports.qt.nokia.com/browse/QTBUG-4368|QTBUG-4368]] => corrigé à partir de la révision 792 (dans le trunk, repris dans la branche 0.3 lors de la révision 793)
    * Toutes les classes dérivant de QGraphicsView : le rubberband laisse des artefacts avec le thème Oxygen => D'après le [[http://bugreports.qt.nokia.com/browse/QTBUG-6195|QTBUG-6195]], il s'agit d'un bug Oxygen corrigé côté KDE.
  * [ok] Se décider à faire une release => samedi 06 et dimanche 07 Février 2010
==== 0.21 ====
  * [ok] Prévenir les packageurs du tag à venir (trem, scorpio, Remi) => trem n'est pas dispo le week-end de la release, mais bon, il faut bien faire la release un jour
  * [no] Préparer la dépêche pour linuxfr.org : Useless, il s'agit seulement d'une version mineure
  * [ok] Préparer la news pour qelectrotech.org => ''huxley:/home/xavier/news.qet.0.21.txt''
  * [ok] Vérifier [[doc:translation#statut_des_traductions|l'état des traductions]] : il serait souhaitable que les traductions espagnoles soient confirmées par Youssef ou Alfredo, mais à part ça, le statut des traductions est plus que satisfaisant ; les .ts pour Qt ont également été mis à jour
  * [ok] Modifier le displayedVersion et le splash screen
  * [ok] Générer la [[http://download.tuxfamily.org/qet/doc/0.21/html/index.html|documentation du code]], l'uploader et mettre à jour la page [[doc:start|documentation]].
  * [ok] Tagger la version dans le dépôt Subversion : <code bash>SVN_ROOT="svn+ssh://xavier@svn.tuxfamily.org/svnroot/qet/qet"
svn cp ${SVN_ROOT}/trunk ${SVN_ROOT}/tags/0.21 -m "Tag de la version 0.21"</code>
  * [ok] Générer le paquet src et l'uploader : <code bash>
SVN_ROOT="svn+ssh://xavier@svn.tuxfamily.org/svnroot/qet/qet"
SSH_ACCESS="xavier@ssh.tuxfamily.org"
SSH_TAGS_PATH="/home/qet/qet-repository/tags"
SSH_DEBIANWATCH_PATH="/home/qet/qet-repository/debianwatch"
QET_VERSION="0.21"

archive_name="qelectrotech-${QET_VERSION}-src"
now_date="$(date "+%Y%m%d")"
ssh_tags_dir="${SSH_TAGS_PATH}/${now_date}"

cd /tmp
umask 0022
svn export $SVN_ROOT/tags/${QET_VERSION} ${archive_name}
tar czvf ${archive_name}.tar.gz ${archive_name}/
chmod 664 ${archive_name}.tar.gz
ssh ${SSH_ACCESS} "mkdir -p ${ssh_tags_dir} && chmod g+w ${ssh_tags_dir}"

scp ${archive_name}.tar.gz ${SSH_ACCESS}:${ssh_tags_dir}/
rm -rf ${archive_name} ${archive_name}.tar.gz

ssh ${SSH_ACCESS} "cd ${SSH_DEBIANWATCH_PATH} && ln -s ../tags/${now_date}/${archive_name}.tar.gz ${archive_name}.tar.gz"
</code>
  * [ok] Ajouter un lien symbolique dans http://download.tuxfamily.org/qet/debianwatch/ (cf script ci-dessus) et mdifier releases.txt
  * Paquets pour :
    * [ok] Windows : paquet ready to use (ne pas oublier les .dll dans bin\)
    * [ok] Windows : installeur (ne pas oublier les .dll dans bin\)
    * [ok] Slackware,
    * Debian => Laurent,
    * [ok] Fedora => Remi,
    * MacOS => Benoît,
    * et Mandriva => trem
  * [ok] Mises à jour :
    * [ok] [[qet>/download.html|Page de téléchargement]]
    * [ok] [[http://www.jesuislibre.org/progdetail.php3?idprog=656|jesuislibre.org]]
    * [ok] [[http://www.qt-apps.org/content/show.php/QElectroTech?content=90198|qt-apps.org]]
    * [ok] [[http://freshmeat.net/projects/qelectrotech|FreshMeat]]
    * [ok] [[qet>/|news QET]]
==== 0.22 ====
  * [no] Prévenir les packageurs du tag à venir (trem, scorpio, Remi) => failed
  * [no] Préparer la dépêche pour linuxfr.org : Useless, il s'agit seulement d'une version mineure
  * [ok] Rédiger le [[doc:changelog_0.21_0.22|Changelog 0.21 -> 0.22]]
  * [ok] Préparer la news pour qelectrotech.org => ''huxley:/home/xavier/news.qet.0.22.txt''
  * [ok] Vérifier [[doc:translation#statut_des_traductions|l'état des traductions]] : All right
  * [ok] Modifier le displayedVersion et le splash screen
  * [ok] Générer la [[http://download.tuxfamily.org/qet/doc/0.22/html/index.html|documentation du code]], l'uploader et mettre à jour la page [[doc:start|documentation]].
  * [ok] Tagger la version dans le dépôt Subversion : <code bash>SVN_ROOT="svn+ssh://xavier@svn.tuxfamily.org/svnroot/qet/qet"
svn cp ${SVN_ROOT}/trunk ${SVN_ROOT}/tags/0.22 -m "Tag de la version 0.22"</code>
  * [ok] Générer le paquet src et l'uploader : <code bash>
SVN_ROOT="svn+ssh://xavier@svn.tuxfamily.org/svnroot/qet/qet"
SSH_ACCESS="xavier@ssh.tuxfamily.org"
SSH_TAGS_PATH="/home/qet/qet-repository/tags"
SSH_DEBIANWATCH_PATH="/home/qet/qet-repository/debianwatch"
QET_VERSION="0.22"

archive_name="qelectrotech-${QET_VERSION}-src"
now_date="$(date "+%Y%m%d")"
ssh_tags_dir="${SSH_TAGS_PATH}/${now_date}"

cd /tmp
umask 0022
svn export $SVN_ROOT/tags/${QET_VERSION} ${archive_name}
rm -rf ${archive_name}/ico/scalable ${archive_name}/ico/oxygen-icons/scalable/
tar czvf ${archive_name}.tar.gz ${archive_name}/
chmod 664 ${archive_name}.tar.gz
ssh ${SSH_ACCESS} "mkdir -p ${ssh_tags_dir} && chmod g+w ${ssh_tags_dir}"

scp ${archive_name}.tar.gz ${SSH_ACCESS}:${ssh_tags_dir}/
rm -rf ${archive_name} ${archive_name}.tar.gz

ssh ${SSH_ACCESS} "cd ${SSH_DEBIANWATCH_PATH} && ln -s ../tags/${now_date}/${archive_name}.tar.gz ${archive_name}.tar.gz"
</code>
  * [ok] Ajouter un lien symbolique dans http://download.tuxfamily.org/qet/debianwatch/ (cf script ci-dessus) et modifier releases.txt
  * [ok] Paquets pour :
    * [ok] Windows : paquet ready to use (ne pas oublier les .dll dans bin\)
    * [ok] Windows : installeur (ne pas oublier les .dll dans bin\)
    * [ok] Slackware,
    * [ok] Debian => Laurent,
    * [ok] Fedora => Remi,
    * MacOS => Benoît,
    * et Mandriva => trem
  * Mises à jour :
    * [ok] [[qet>/download.html|Page de téléchargement]]
    * [ok] [[http://www.jesuislibre.org/progdetail.php3?idprog=656|jesuislibre.org]]
    * [ok] [[http://www.qt-apps.org/content/show.php/QElectroTech?content=90198|qt-apps.org]]
    * [ok] [[http://freshmeat.net/projects/qelectrotech|FreshMeat]]
    * [ok] [[qet>/|news QET]]

===== Améliorations prévues pour la 0.3 =====
  * Clarifier la situation en ce qui concerne les suppressions d'item : l'item parent doit être alerté ; l'objet correspondant doit-il être systématiquement supprimé en conséquence ? Si oui, quand et par qui ?
  * Actuellement, les conflits catégories / catégories et éléments / éléments sont gérés => gérer les (capilotractés) conflits categories / éléments.
  * Impression PDF/PS : Limitation sous Windows : impossible de choisir le format de papier et les marges car le dialogue natif ne peut gérer que les "native printers"
  * Améliorer le comportement de l'éditeur de schémas lorsqu'on déplace la borne d'un élément : si la borne n'est pas trouvé à l'emplacement exact, utiliser la borne la plus proche.
  * Faire le point sur les problèmes relatifs aux textes.

===== Création de la branche 0.3 =====

<code bash>
SVNROOT="svn+ssh://xavier@svn.tuxfamily.org/svnroot/qet/qet"
BRANCHE="0.3"
svn cp "${SVNROOT}/trunk" "${SVNROOT}/branches/${BRANCHE}" -m "Creation de la branche ${BRANCHE}"
</code>
> Effectué  --- //[[xavier@qelectrotech.org|Xavier G.]] 16/08/2009 18:52//

===== Problème de positionnement des textes =====
==== Situation actuelle ====

=== Génération des .elmt dans l'éditeur d'élément ===
Dans l'éditeur d'éléments, les textes statiques et les champs de texte sont positionnés de la même manière : dans ElementScene::mouseReleaseEvent, si l'on est en mode Text ou TextField, la position du curseur est affectée aux champs de texte via PartText::setPos et PartTextField::setPos. Ces deux méthodes ont le même code : <code c++>void PartText::setPos(qreal x, qreal y) {
	QGraphicsTextItem::setPos(QPointF(x, y) - margin());
}</code>

Un décalage est donc appliqué à la position réellement cliquée ; cette marge est fournie par les méthodes margin(), identiques entre les deux classes : <code c++>QPointF PartTextField::margin() const {
	QFont used_font = font();
	QFontMetrics qfm(used_font);
	QPointF margin(
		(boundingRect().width () - qfm.width(toPlainText())) / 2.0,
		((boundingRect().height() - used_font.pointSizeF()) / 3.0) + used_font.pointSizeF()
	);
	return(margin);
}</code>
En abscisse :
  * la longueur du texte avec la police utilisée est calculée => :!: ceci suppose qu'il n'y a qu'une ligne de texte à ce moment là
  * elle est soustraite de la largeur du boundingRect => :!: ceci suppose que le boundingRect correspond au rectangle entourant le texte
  * et divisée par deux (pour chaque espace de chaque côté du texte)
  * Pour un texte fraîchement posé, ce calcul s'avère étonnamment fiable.
En ordonnée :
  * La hauteur du texte est récupérée => :!: là encore, ceci suppose qu'il n'y a qu'une seule ligne de texte ; de plus, cette valeur est simplement la hauteur en points, pas en pixels après rendu.
  * elle est soustraite de la hauteur du boundingRect => :!: là encore, ceci suppose que le boundingRect correspond au rectangle entourant le texte
  * le tout est divisé par 3 => :!: Valeur obtenue par tâtonnements ?
  * La hauteur du texte est rajoutée => :!: là encore, ceci suppose qu'il n'y a qu'une seule ligne de texte
  * Ce code semble chercher à déterminer soit le milieu vertical de la représentation graphique du texte, soit la baseline.

=== Lecture des .elmt dans l'éditeur de schémas ===

Lors du rendu des textes statiques sur le schéma, la méthode CustomElement::parseText passe directement les coordonnées lues dans la description XML à la méthode QPainter::drawText : <code c++>qp.drawText(QPointF(pos_x, pos_y), e.attribute("text"));</code>

Voici la documentation de cette méthode :
> ''void QPainter::drawText ( const [[http://doc.trolltech.com/4.5/qpointf.html|QPointF]] & position, const [[http://doc.trolltech.com/4.5/qstring.html|QString]] & text )''
> 
> Draws the given text with the currently defined text direction, beginning at the given position.
> 
> This function does not handle the newline character (\n), as it cannot break text into multiple lines, and it cannot display the newline character. Use the QPainter::drawText() overload that takes a rectangle instead if you want to draw multiple lines of text with the newline character, or if you want the text to be wrapped.
> 
> By default, [[http://doc.trolltech.com/4.5/qpainter.html|QPainter]] draws text anti-aliased.
> 
> **Note:** The y-position is used as the baseline of the font.

Constats :
  - l'abscisse correspond au **début du texte**
  - pour le rendu du texte, elle considère que l'ordonnée fournie précise la **position de la baseline** et non le milieu vertical du texte ;
  - elle ne gère pas l'insertion de plusieurs lignes dans un champ de texte statique.

Lors du positionnement des champs de texte sur le schéma, la position indiquée dans la description XML est passée à ElementTextItem::setPos, qui lui applique le traitement suivant : <code c++>actual_pos -= QPointF(0.0, boundingRect().height() / 2.0);</code>
=> **utilisation du milieu vertical du boundingRect du champ de texte**. :!: Attention : le boundingRect a été agrandie de 1.1px vers le haut (classe ElementTextItem) => à répercuter dans la classe PartTextField ?

=== Réflexions ===

Le but initial était de travailler avec :
  * en abscisse : l'extrémité gauche de la représentation graphique du texte (et non pas du rectangle qui apparaît lorsqu'on l'édite)
  * en ordonnée :
    * soit le milieu vertical de la représentation graphique du texte
    * soit le milieu vertical du boundingRect du champ de texte
    * soit l'ordonnée de la //baseline// de la première ligne
En clair, le but était d'enregistrer des coordonnées indiquant où commence la représentation graphique du texte afin que le chargement d'un texte statique (donc dessiné) n'ait pas à le calculer, et que le calcul inverse puisse être effectué pour les champs de texte.

Au final, dans l'éditeur de schéma, un décalage est tout de suite visible :
  * sur les textes statiques : le décalage est seulement vertical => sans doute une conséquence des calculs hasardeux pour l'ordonnée décrits ci-dessus
  * sur les champs de texte : décalage horizontal et vertical => le calcul pour passer de la position du texte (même erronée) à celle du champ de texte ne correspond pas du tout à celui effectué par l'éditeur d'élément.
==== Solutions envisagées et autres problèmes ====

Pour les champs de texte statiques, on pourrait :
  * [ok] affiner les calculs actuels de l'ordonnée, qui représenterait la baseline => solutionné : prendre en compte le documentMargin de la classe QTextDocument ainsi que l'ascent de la police utilisée
    * [ok] problème : il resterait à gérer les champs de texte à plusieurs lignes => solutionné en effectuant le rendu via la classe QTextDocument
  * [no] se baser sur le "top of the font" (voir http://qt.nokia.com/doc/4.5/qpainter.html#drawText-10 - définition à éclaircir)
    * [no] problème : les éléments existants (collection officielle ou non) ont été créés en "visant" la baseline
    * [no] solution : ajouter un attribut genre positionning="top" pour distinguer s'il faut appliquer l'ancien ou le nouveau comportement

Pour les champs de texte dynamiques, on pourrait :
  * [ok] affiner les calculs et les implémenter des deux côtés => choix du champ de texte positionné par le milieu de son côté gauche
  * [no] stocker simplement la position du champ de texte
    * problème : les éléments existants (collection officielle ou non) ont été créés avec le système actuel
    * solution : ajouter un attribut genre positionning="textfield" pour distinguer s'il faut appliquer l'ancien ou le nouveau comportement

===== Étude de la classe QGraphicsTextItem =====

{{:notes:qgraphicstextimage_commente.png|}}

Documentation complémentaire :
  * classe [[http://qt.nokia.com/doc/4.5/qgraphicstextitem.html|QGraphicsTextItem]]
  * classe [[http://qt.nokia.com/doc/4.5/qtextdocument.html|QTextDocument]]
  * [[http://www.fonts.com/aboutfonts/articles/fyti/anatomy.htm|Anatomy of a character]]
  * [[http://labs.trolltech.com/blogs/2008/08/28/font-anatomy/|Font anatomy]]
===== Nouvelles fonctionnalités relatives aux textes =====

Voici les nouvelles fonctionnalités demandées par rapport aux textes :
  * [ok] pouvoir pivoter des textes statiques dans l'éditeur d'éléments ; ceci implique :
    * [ok] de modifier l'éditeur de façon à pouvoir pivoter les textes statiques (cohérence du positionnement et du pivotement, annulations, etc.)
    * [ok] de modifier le format .elmt de façon à pouvoir mémoriser l'orientation d'un texte statique
  * [ok] pouvoir pivoter les textes dynamiques sur les schémas ; ceci est valable pour :
     * [ok] les textes indépendants    => modification de la classe DiagramTextItem => attribut XML "rotation" ajoutés aux éléments XML diagram/inputs/input         + annulations ok, rotation par rapport au point (0, 0), c-à-d le coin supérieur gauche du champ
     * [ok] les textes des conducteurs => modification de la classe DiagramTextItem => attribut XML "rotation" ajoutés aux éléments XML diagram/conductors/conductor + annulations ok, rotation par rapport au point (0, 0), c-à-d le coin supérieur gauche du champ
     * [ok] les textes dynamiques des éléments ; cela implique de pouvoir définir dans l'éditeur d'éléments, et ce pour chaque texte dynamique, une orientation par défaut. La rotation s'effectue par rapport au milieu du côté gauche du champ de texte
       * [ok] Modification des deux éditeurs pour que le positionnement se fasse correctement par rapport au milieu du côté gauche du champ de texte
       * [ok] Modification des deux éditeurs pour que l'ajout ou le retrait de lignes dans un champ de texte ne modifie pas sa position
       * [ok] Modification de l'éditeur d'élément pour que le changement de taille de police d'un champ de texte ne modifie pas sa position
       * [ok] Modification de la classe DiagramTextItem pour pouvoir pivoter via une méthode virtuelle qui fait réellement le travail de rotation
       * [ok] Redéfinition de cette méthode dans ElementTextItem pour effectuer la rotation par rapport au point
       * [ok] Adaptation de l'éditeur d'élément
     * [ok] Donner à l'utilisateur la possibilité de spécifier l'angle exact de l'orientation des champs de texte :
       * [ok] dialogue à finir (QTextOrientationWidget + QSpinBox = en faire un nouveau widget composite réutilisable, genre QTextOrientationSpinBoxWidget [quelle originalité, Xavier...] ?)
       * [ok] classe dérivée de QUndoCommand à réaliser : attributs : ''QHash<DiagramTextItem *, qreal> previous_state_'' pour undo, ''qreal applied_orientation_'' pour redo
     * [ok] Régler le bug/conflit entre la fonction followParentRotation (FPR) et la rotation elle-même : **plan** :
       * [ok] Dans un premier temps, désactiver la contre-rotation qui est actuellement appliquée aux champs de texte sans FPR lors du pivotement de leur élément parent
       * [ok] Implémenter le repositionnement des textes (cf ci-dessous)
       * [ok] Modifier la classe qui effectue et annule les pivotements d'éléments de façon à ce qu'elle inclut, pour chaque texte sans FPR de l'élément, une rotation et un déplacement ; le non-FPR est alors un `hint' pour dire « pivoter l'élément parent revient à pivoter l'élément parent, puis à pivoter et repositionner ce texte comme si l'utilisateur l'avait fait lui-même. »
       * [ok] Lors du chargement des schémas :
         * [ok] si le schéma chargé est en version >= 0.3, prendre en compte l'orientation et la position définies par l'utilisateur
         * [ok] si le schéma chargé est en version < 0.3, positionner le texte avec l'ancien comportement (=considérer la position ainsi calculée comme définie par l'utilisateur)
  * [ok] pouvoir repositionner les textes dynamiques comme on le souhaite :
     * [ok] la position des textes indépendants est déjà modifiable
     * [ok] textes dynamiques des éléments => flag à activer + gestion des déplacements + gestion des annulations + export XML à modifier
     * [ok] textes des conducteurs :
       * [ok] flag pour détecter le déplacement par l'utilisateur
       * [ok] algo pour limiter ce déplacement aux alentours du conducteur
       * [ok] algo pour ramener le texte dans les alentours du conducteur si celui-ci est modifié
       * [ok] annulation des repositionnements dûs à la modification d'un conducteur
       * [ok] annulation des repositionnements à la souris
       * [ok] annulation du flag moved_by_user
       * [ok] annulation des repositionnements dûs aux déplacement d'éléments
         * [ok] lors de l'update des conductorsToUpdate()
           * [ok] mémoriser les positions de leurs ConductorTextItem
      * [ok] Enregistrer les positions dans les fichiers et les relire
  * pouvoir utiliser du texte enrichi : de manière pragmatique, cela pourrait se limiter à :
    * taille du texte (mais surtout pas la police)
    * couleur du texte
    * gras/italique/souligné/barré

:?: Questions :
  * [ok] le positionnement d'un champ de texte ayant un parent doit-il être //absolu// (le parent bouge, le texte ne le suit pas) ou //relatif// (le parent bouge, la position du texte en est modifiée) ? => à priori relatif ; pour du positionnement absolu, il y a les champs de texte indépendants
  * [ok] quels attributs XML pour spécifier la position modifiée d'un champ de texte ? => "userposition", pour être cohérent avec l'attribut "userrotation", utilisé pour redéfinir l'orientation d'un champ de texte dynamique d'élément sur le schéma
  * [ok] par rapport à quel point est effectué le pivotement ? => le même que pour le positionnement, c-à-d :
    * textes des conducteurs et textes indépendants : coin supérieur gauche
    * textes dynamiques des éléments : milieu du côté gauche du champ de texte
    * textes statiques des éléments : baseline du texte
  * [ok] concernant l'édition des champs de texte, faut-il :
    * [ok] opter pour la même politique que les champs de texte indépendants actuels (à savoir : clic pour sélectionner [et donc déplacer/pivoter] et double-clic pour éditer)
    * [no] OU opter pour une édition via un simple clic, un déplacement en maintenant une touche enfoncée (éventuel conflit avec l'édition de texte ?) et un pivotement avec un raccourci clavier ?
  * dans un logiciel où l'on peut positionner et pivoter les textes comme on le souhaite, qu'advient-il de l'option "maintenir horizontal malgré les rotations de l'élément" ? => bonne question en fait
Remarques :
  * [ok] Si les textes et leurs parents (éléments, conducteurs) peuvent être largement séparés/éloignés, il serait de bon ton de mettre en valeur le conducteur / l'élement parent d'un texte sélectionné et vice-versa.
  * Une option "remettre à la position initiale" pourrait également servir.

Rien à voir : [[titleblock_future|réflexions sur le futur des cartouches]]

===== Cartouches =====

  * [ok] Implémenter un objet DiagramContext (dico noms => valeurs après interprétation)
  * [ok] Lorsque les informations du borderTitleBlock changent, générer ce DiagramContext et l'assigner à l'TitleBlockTemplate
  * [ok] TitleBlockTemplate : générer les textes du template à partir du DiagramContext :
    * [ok] se limiter à des remplacements de chaînes de caractères, mais bien foutu (syntaxe pour éviter les ambiguités notamment) -- le template décide de la présentation mais pas de la sémantique (ex : date du jour contre date fixe => responsabilité du BorderTitleBlock)
    * [ok] gérer également l'alignement (horizontal et vertical) dans la cellule 
  * [ok] TitleBlockTemplate : conserver la dernière longueur pour laquelle le cartouche a été généré, afin de savoir s'il faut regénérer le cache.
  * [ok] TitleBlockTemplate : lors de la réassignation d'un DiagramContext, invalider le rendu en cache du cartouche
  * [ok] QET : réaliser un template pour remplacer le cartouche actuel
  * [ok] Intégrer ce template en tant que ressource Qt
  * [ok] Utiliser désormais ce template pour rendre le cartouche par défaut :
    * [ok] supprimer le code de rendu de l'ancien cartouche
    * [ok] ne plus mettre à jour le diagram context à chaque rendu
    * [ok] tester (annulations notamment)
  * [ok] Rendre le debug optionnel via un #define
  * [ok] Ajouter une classe TitleBlockTemplateRenderer qui se charge de rendre un TitleBlockTemplate
  * [ok] Mettre en place une API pour qu'un QETProject embarque un ensemble de templates :
    * [ok] attributs (un hash name => xml et un hash name => TitleBlockTemplate, laissé vide)
    * [ok] chargement depuis le XML
    * [ok] mise en place d'une méthode fournissant un template en échange d'un nom de template : const TitleBlockTemplate *QETProject::gettemplateByName(const QString &template_name); qui initialise ce template si besoin
  * [ok] Panel : afficher les modèles de cartouche embarqués dans le projet
  * [ok] Panel : mettre en place un menu contextuel et les dialogues qui vont avec pour :
    * [ok] intégrer un modèle de cartouche à un projet (ajout)
    * [ok] modifier un modèle de cartouche d'un projet (édition)
    * [ok] supprimer un modèle de cartouche d'un projet (suppression => émettre un signal pour que les schémas concernés reprennent le cartouche par défaut)
  * [ok] Mettre en place un dialogue pour définir le template utilisé par un schéma parmi ceux embarqués dans le projet
  * [ok] Faire en sorte que le schéma utilise le template ainsi assigné
  * [ok] Il semblerait qu'il règne un bordel monstre au niveau de la gestion des attributs entre Diagram::fromXml()/toXml() et les classes BorderTitleBlock, TitleBlockProperties et BorderProperties (avec les méthodes import* et export*) : nettoyer tout ça => rev1141
  * [ok] (rev1142) Un template personnalisé ne sert à rien si on ne peut pas y mettre les valeurs que l'on veut. L'utilisateur doit pouvoir ajouter ses propres associations noms/valeurs au "DiagramContext", et ce aux niveaux habituels de configuration, à savoir :
    - Dans le binaire de l'application : aucune association nom/valeur, pas d'options de compilation prévues pour cela
    - Dans la configuration utilisateur
    - Dans la configuration du projet courant
    - Dans le schéma courant
  * [ok] Note : ces associations noms/valeurs sont libres, mais elles ne pourront toutefois pas écraser les valeurs historiques (author, title, filename, folio, date) et/ou générées dynamiquement (numéro et nombre de folio(s))
  * [ok] Donner la possibilité de spécifier la taille de police de chaque champ dans les modèles de cartouche.
  * [ok] Donner la possibilité d'adapter la taille de la police si un texte final ne rentre pas dans sa cellule => option "hadjust", à "true" par défaut.
  * Peaufiner un peu l'éditeur de templates :
    * [ok] intégration facilitée des images (fopen, base64, concat, insert)
    * checks poussés lors de l'enregistrement
    * éviter de quitter directement si modifications ?
  * Créer un éditeur de templates convivial
    * Définir l'interface voulue => cf section ci-dessous => pas encore sûr du résultat final => expérimenter/tâtonner un peu.

==== Éditeur de modèle de cartouche / Titleblock template editor ====
Besoins :
Un truc pas trop compliqué à utiliser, qui permette de définir un tableau constitué de cellules de longueurs et largeurs variables, un peu façon tableur.
La longueur du rendu visuel serait une option de l'éditeur.
Les propriétés de chaque cellule se définiraient via un petit panel.
Pour les cellules de type logo, ce panel propose le choix entre :
  * utiliser une image déjà incorporée dans le modèle
  * incorporer une nouvelle image dans ce modèle et l'utiliser pour cette cellule
Prévoir un petit panel permettant de lister les images incorporées
Gérer la suppression d'une image incorporée.


Classes possibles pour l'implémentation du tableau semi-WYSIWYG : 
  * QTextTable
  * QTableWidget
  * Classe perso basée sur TitleBlockTemplate ?
Autres classes impliquées :
  * QMainWindow et cie (QMenuBar, QMenu, QAction, etc.)
  * TitleBlockCell
  

===== Amélioration du chargement de l'application =====

Besoin : En l'état actuel des choses, l'application "slurpe" ((http://www.perl.com/pub/2003/11/21/slurp.html)) environ 800 éléments et catégories lorsqu'elle démarre, ce qui occasionne une impression de lenteur sur certaines machines.

Objectifs : sans revoir en profondeur l'architecture actuelle, faire en sorte que l'interface fournisse un meilleur feedback de l'avancement du chargement à l'utilisateur.
  * QETapp :
    * [ok] charger les collections common et custom dans le constructeur de la classe QETApp
    * fournir un retour sur ce chargement dans le splash screen :
      * créer une classe ElementEvent
      * créer une classe ElementSplashScreenEvent en dérivant
      * ajouter des méthodes statiques eventHandlers(), addHandler() et removeHandler() à la classe ElementsCollectionItem
      * lier le tout pour que la QETApp puisse enregistrer un handler dédié au suivi du chargement des éléments auprès de la classe ElementsCollectionItem
  * ElementsPanel :
    * [ok] ne plus recharger les collections au démarrage, puisqu'elles sont chargées par la classe QETApp
    * [ok] générer une barre de progression en bas du panel
  * Répartir la lecture / le chargement des différentes collections dans plusieurs threads (avec QtConcurrent ?)
===== Améliorations des conducteurs colorés =====

Transformer le dialogue de sélection de manière à mettre en avant certaines couleurs :
  * noir : #000000 : Par défaut
  * Puissance :
    * noir :  : L1 : power-l1:#000000
    * brun : #6D3700 : L2 : power-l2
    * gris : #606060 : L3 : power-l3
    * bleu : #0000ff : Neutre : power-neutral
    * vert et jaune successif : #009900:#FFFF00 : Protection équipotentielle / terre / masse
  * Commande :
    * rouge : #ff0000 : Phase de commande
    * bleu clair : #0080FF : Neutre de commande
  * Norme historique :
    * vert : #009900 : L1
    * jaune : #FFFF00 : L2
    * brun : #6D3700 : L3
  * deux couleurs personnalisées
  * une couleur personnalisée
Prévoir un système de templates pour l'apparence des conducteurs : on lit deux dossiers (un fourni par QET, l'autre dans la conf user), on y trouve un fichier XML par template ; chaque fichier XML contient les traductions du nom du template et ses caractéristiques (couleur1, couleur2, pointillés/style de trait). Le nom du template ET ses caractéristiques sont embarquées dans le conducteur ; dans les propriétés du conducteur, si le nom du template est reconnu, on le sélectionne dans la liste, sinon on considère qu'il s'agit d'une couleur personnalisée.

===== Todo pour Youssef =====

  * promotion
    * relancer la traduction en catalan
    * relancer les personnes motivées (ex: demander symboles manquants)
  * traduction
    * s'occuper ou déléguer la traduction en catalan
  * symboles
    * faire un rapide audit des symboles manquants
    * s'occuper de todo_elements