Table des matières

Notes du dév'

Voir aussi : 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 pour la version 0.2) :

Notes pour la 0.21

TODO :

0.21

0.22

Améliorations prévues pour la 0.3

Création de la branche 0.3

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

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 : 

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 :

En ordonnée :

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 : 

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 ?

Réflexions

Le but initial était de travailler avec :

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 :

Solutions envisagées et autres problèmes

Pour les champs de texte statiques, on pourrait :

Pour les champs de texte dynamiques, on pourrait :

Étude de la classe QGraphicsTextItem

Documentation complémentaire :

Nouvelles fonctionnalités relatives aux textes

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

:?: Questions :

Remarques :

Rien à voir : réflexions sur le futur des cartouches

Cartouches

É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 :

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 :

Autres classes impliquées :

Amélioration du chargement de l'application

Besoin : En l'état actuel des choses, l'application “slurpe” 1) 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.

Améliorations des conducteurs colorés

Transformer le dialogue de sélection de manière à mettre en avant certaines couleurs :

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

1) http://www.perl.com/pub/2003/11/21/slurp.html