Notes du dév'

Voir aussi : Développement du site web

Tâches non effectuées lors du développement de la 0.2 (cf 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.

TODO :

• Faire le point sur tout ce qui est améliorable pour la 0.21 ⇒ voir Changelog ci-dessous
• Tenir à jour le ChangeLog de la version 0.21
• Finir le guide de démarrage rapide ? Non, ce ne sera pas prêt pour la 0.21
• 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
  • Intégrer le guide de démarrage rapide au niveau des raccourcis générés ⇒ non disponible
• 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
• Virer “titre du document” dans le cartouche ?
• Faire le point sur les bugs de rendu connus :
  • Éditeur de schéma : problème de repaint en dehors du sceneRect ⇒ 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 QTBUG-6195, il s'agit d'un bug Oxygen corrigé côté KDE.
• Se décider à faire une release ⇒ samedi 06 et dimanche 07 Février 2010

• 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
• Préparer la dépêche pour linuxfr.org : Useless, il s'agit seulement d'une version mineure
• Préparer la news pour qelectrotech.org ⇒ huxley:/home/xavier/news.qet.0.21.txt
• Vérifier 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
• Modifier le displayedVersion et le splash screen
• Générer la documentation du code, l'uploader et mettre à jour la page documentation.
• Tagger la version dans le dépôt Subversion :

  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"

• Générer le paquet src et l'uploader :

  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"

• Ajouter un lien symbolique dans http://download.tuxfamily.org/qet/debianwatch/ (cf script ci-dessus) et mdifier releases.txt
• Paquets pour :
  • Windows : paquet ready to use (ne pas oublier les .dll dans bin\)
  • Windows : installeur (ne pas oublier les .dll dans bin\)
  • Slackware,
  • Debian ⇒ Laurent,
  • Fedora ⇒ Remi,
  • MacOS ⇒ Benoît,
  • et Mandriva ⇒ trem
• Mises à jour :
  • Page de téléchargement
  • jesuislibre.org
  • qt-apps.org
  • FreshMeat
  • news QET

• Prévenir les packageurs du tag à venir (trem, scorpio, Remi) ⇒ failed
• Préparer la dépêche pour linuxfr.org : Useless, il s'agit seulement d'une version mineure
• Rédiger le Changelog 0.21 -> 0.22
• Préparer la news pour qelectrotech.org ⇒ huxley:/home/xavier/news.qet.0.22.txt
• Vérifier l'état des traductions : All right
• Modifier le displayedVersion et le splash screen
• Générer la documentation du code, l'uploader et mettre à jour la page documentation.
• Tagger la version dans le dépôt Subversion :

  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"

• Générer le paquet src et l'uploader :

  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"

• Ajouter un lien symbolique dans http://download.tuxfamily.org/qet/debianwatch/ (cf script ci-dessus) et modifier releases.txt
• Paquets pour :
  • Windows : paquet ready to use (ne pas oublier les .dll dans bin\)
  • Windows : installeur (ne pas oublier les .dll dans bin\)
  • Slackware,
  • Debian ⇒ Laurent,
  • Fedora ⇒ Remi,
  • MacOS ⇒ Benoît,
  • et Mandriva ⇒ trem
• Mises à jour :
  • Page de téléchargement
  • jesuislibre.org
  • qt-apps.org
  • FreshMeat
  • news QET

• 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.

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}"

Effectué — Xavier G. 16/08/2009 18:52

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 :

void PartText::setPos(qreal x, qreal y) {
	QGraphicsTextItem::setPos(QPointF(x, y) - margin());
}

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 :

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);
}

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.

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 :

qp.drawText(QPointF(pos_x, pos_y), e.attribute("text"));

Voici la documentation de cette méthode :

void QPainter::drawText ( const QPointF & position, const 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, QPainter draws text anti-aliased.

Note: The y-position is used as the baseline of the font.

Constats :

1. l'abscisse correspond au début du texte
2. 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 ;
3. 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 :

actual_pos -= QPointF(0.0, boundingRect().height() / 2.0);

⇒ 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 ?

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.

Pour les champs de texte statiques, on pourrait :

• 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
  • problème : il resterait à gérer les champs de texte à plusieurs lignes ⇒ solutionné en effectuant le rendu via la classe QTextDocument
• se baser sur le “top of the font” (voir http://qt.nokia.com/doc/4.5/qpainter.html#drawText-10 - définition à éclaircir)
  • problème : les éléments existants (collection officielle ou non) ont été créés en “visant” la baseline
  • 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 :

• 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
• 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

Documentation complémentaire :

• classe QGraphicsTextItem
• classe QTextDocument
• Anatomy of a character
• Font anatomy

Voici les nouvelles fonctionnalités demandées par rapport aux textes :

• pouvoir pivoter des textes statiques dans l'éditeur d'éléments ; ceci implique :
  • de modifier l'éditeur de façon à pouvoir pivoter les textes statiques (cohérence du positionnement et du pivotement, annulations, etc.)
  • de modifier le format .elmt de façon à pouvoir mémoriser l'orientation d'un texte statique
• pouvoir pivoter les textes dynamiques sur les schémas ; ceci est valable pour :
  • 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
  • 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
  • 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
    • Modification des deux éditeurs pour que le positionnement se fasse correctement par rapport au milieu du côté gauche du champ de texte
    • Modification des deux éditeurs pour que l'ajout ou le retrait de lignes dans un champ de texte ne modifie pas sa position
    • 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
    • Modification de la classe DiagramTextItem pour pouvoir pivoter via une méthode virtuelle qui fait réellement le travail de rotation
    • Redéfinition de cette méthode dans ElementTextItem pour effectuer la rotation par rapport au point
    • Adaptation de l'éditeur d'élément
  • Donner à l'utilisateur la possibilité de spécifier l'angle exact de l'orientation des champs de texte :
    • dialogue à finir (QTextOrientationWidget + QSpinBox = en faire un nouveau widget composite réutilisable, genre QTextOrientationSpinBoxWidget [quelle originalité, Xavier…] ?)
    • classe dérivée de QUndoCommand à réaliser : attributs : QHash<DiagramTextItem *, qreal> previous_state_ pour undo, qreal applied_orientation_ pour redo
  • Régler le bug/conflit entre la fonction followParentRotation (FPR) et la rotation elle-même : plan :
    • 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
    • Implémenter le repositionnement des textes (cf ci-dessous)
    • 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. »
    • Lors du chargement des schémas :
      • si le schéma chargé est en version >= 0.3, prendre en compte l'orientation et la position définies par l'utilisateur
      • 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)
• pouvoir repositionner les textes dynamiques comme on le souhaite :
  • la position des textes indépendants est déjà modifiable
  • textes dynamiques des éléments ⇒ flag à activer + gestion des déplacements + gestion des annulations + export XML à modifier
  • textes des conducteurs :
    • flag pour détecter le déplacement par l'utilisateur
    • algo pour limiter ce déplacement aux alentours du conducteur
    • algo pour ramener le texte dans les alentours du conducteur si celui-ci est modifié
    • annulation des repositionnements dûs à la modification d'un conducteur
    • annulation des repositionnements à la souris
    • annulation du flag moved_by_user
    • annulation des repositionnements dûs aux déplacement d'éléments
      • lors de l'update des conductorsToUpdate()
        • mémoriser les positions de leurs ConductorTextItem
    • 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 :

• 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
• 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
• 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
• concernant l'édition des champs de texte, faut-il :
  • 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)
  • 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 :

• 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 : réflexions sur le futur des cartouches

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.