Relecture rapide. Bon boulot. Partie sur les events intéressante et complète (postEvent, processEvents)
Utilisation avancée des widgets avec Qt
Pourquoi "avancé" ? Tu vois quoi comme base de l'utilisation des widgets ?
Préférer la syntaxe des connect de Qt5
Récupérer des événements pour un widge
Enfin, nous comprendrons comment relier les événements entre les widgets, notamment avec les signaux et slots, mais pas seulement !
Peut être maladroit. Les signaux-slots sont un autre système de découplage du code, pas forcement un prolongement des events
include <QtGui/QWidget>
Le code semble globalement compatible avec Qt5. Sauf le module QtGui qui devient QtWidgets… mais en fait, c'est une mauvaise pratique de mettre le nom du module, autant mettre directement le nom de la classe.
Le constructeur spécifie l'héritage à QWidget
C'est la déclaration de la classe qui spécifie l'héritage. Le constructeur du parent sera dans tous les cas appelé, même si on ne le spécifie pas dans le constructeur de la classe.
Intercepter un événement simple
Ca serait peut être pas mal de faire un encadré pour montrer rapidement (avec un schéma si possible) le fonctionnement des events : génération d'un event, prise en charge par l'event loop, appel de event() du QObject cible, dispatch dans les fonctions xxxEvent. Si event non accepté, transmission au QObject parent
Cela permet de comprendre d'où vient ces fonctions events
virtual void mousePressEvent(QMouseEvent* event);
Je conseille de passer au C++11 :
| void mousePressEvent(QMouseEvent* event) Q_DECL_OVERRIDE;
|
En effet, vous ne devez jamais appeler directement cette méthode
Si. D'ailleurs tu montres comment faire par la suite, pour appeler l'implémentation de la classe de base.
On peut déclarer la méthode dans l'espace privé si notre widget n'est pas hérité, ou pour empêcher une classe fille de ré-implémenter la méthode.
Bof, je ne suis pas fan de modifier l'accessibilité des fonctions.
documentation
Met peut être un lien vers la doc, si le lecteur a la curiosité d'aller lire le reste de la doc. Ou si la doc change
en séparant les boutons par l'opérateur OU
OU bit à bit (bitwise OR) != || (OU logique)
Un des éléments importants de la programmation événementielle avec Qt est la gestion des signaux et slots.
Bof bof. Je n'aime pas faire ce rapprochement. L'utilisation des signaux-slots et de events n'est pas corrélé. On peut utiliser l'un sans l'autre (en particulier, si le traitement de l'event ne nécessite pas de découplage, pas de raison d'utiliser des signaux-slots).
Surtout que ton exemple montre un signal clicked émit par MonWidget (et non connecté), un autre émit par le button. Risque de confusion sur les signaux.
En effet, la plupart des événements peuvent être simulés en interne par notre application via un slot approprié
Je crois vraiment qu'il y a confusion entre signaux-slots et events…
Voici un exemple pour simuler un clic de souris :
Évite les codes qui sortent de l'éditeur du tuto. Fais un retour à la ligne pour simplifier la lecture
cela écrase les implémentations des parents
Bof "écrase". Masque ?
Du dessin sur notre widget
Trop de smileys… ?
une méthode dessine()
Bof le nom. updateCachePixmap() ?
this->
Bof le this systématique
Les éléments dynamiques du dessin
Une petite note, pour dire que QtGraphics est probablement plus adapté pour faire le rendu de jeux ?
je vous invite à consulter l'lien : annexe du tutoriel.
Erreur de frappe
Correction
Pas de raison de mettre les variables membres en protected. Mettre en private
Préférer l'initialisation des variables membres dans la déclaration de la classe (C++11)
Il manque des const dans le code
La classe QKeyEvent
Attention à la cohérence dans la présentation. Vérifier que les tableaux ont les mêmes colonnes dans le même ordre
TP : le jeu du casse-briques
Aie, mes yeux !
Très clairement, QtGraphics est plus adapté pour cela
CasseBriques
Cela fait un peu classe fourre-tout, cela manque de conception
mGagne, mGagne
Pourquoi pas une variable "state" ? (gagné, perdu, pas commencé, pause, etc)
Pas lu les annexes
