Version imprimable
Mouais... Moins convaincu avec celui-là. J'aurais préféré des cônes plus visibles, où on peut vraiment voir que c'est en 3D et pas une vue 2D aplatie grossièrement (on est loin de Crysis, dit autrement). Je suppose que tu peux faire tourner les cônes pour afficher d'autres couleurs ? Selon les trois axes pour afficher tout le spectre rien qu'avec des rotations, non ?Citation:
Envoyé par gbdivers
(Bosse sur ce que tu veux, tant que tu bosses ; moi, j'y vois pas d'inconvénient !).
C'est en Qml?
Tu sait si on peut créé une image avec JS et l'utiliser comme source dans qml?
pfff, je me doutais qu'il y en aurait 1 qui allait me dire que c'est pas de la vrai 3D :)Citation:
J'aurais préféré des cônes plus visibles, où on peut vraiment voir que c'est en 3D et pas une vue 2D aplatie grossièrement (on est loin de Crysis, dit autrement). Je suppose que tu peux faire tourner les cônes pour afficher d'autres couleurs ? Selon les trois axes pour afficher tout le spectre rien qu'avec des rotations, non ?
Le problème est que si j'essaie de faire de la vrai 3D (un cône, avec des ombres, des textures, des super armes et qui conduit une Chevrolet dans New-York), on ne voit plus grand chose et le picking est un peu plus compliqué (là, je récupère simplement l'image 2D et je fais le picking dessus)
Je viens juste de formater mon disque dur pour réinstallé Qt 1.0 et ne plus avoir du QML :aie:Citation:
C'est en Qml?
Tu sait si on peut créé une image avec JS et l'utiliser comme source dans qml?
Plus sérieusement, pour JS, je ne sais pas. Je n'ai pas encore abordé cette partie (j'ai fait que du QML interfacé avec C++)
ok.Citation:
Envoyé par gbdivers
Moi je me suis amusé rapidement. J'ai réussi a faire une fenêtre avec le dégradé mais l'appli prend 1Go de mémoire :aie:
Créé des rectangle de 1x1 avec la couleur du pixel n'est pas une bonne idée du tous :whistle2:
Pour mon premier code QML je suis assez fière 8-) d'ailleurs je vous le donne
J'ai trouvé cette classe qui me permettrais de créé l'image de fond et de la donné à l'affichage, mais cela oblige à avoir un bout de code C++ :cry:Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
http://qt.developpez.com/doc/latest/...imageprovider/
J'ai essayé ton bout de code, 1024,8 M 8O
Moi je dis pas mal ! :ccool:
:) J'adore cette approche !Citation:
Créé des rectangle de 1x1 avec la couleur du pixel n'est pas une bonne idée du tout
Tu nous fait la version redimensionnable pour faire un widget de 800x800 ?
Je n'avais pas encore vu cette possibilité de créer des objets QML dans du QML
Pour les images, je pense que le problème sera le même qu'avec QImage::pixel() : comme QImage (et équivalents) ne sont pas des QObjects, on ne peut pas accéder aux propriétés et fonctions, ni dans QML, ni dans les scripts. On peut juste les lire, les afficher et effectuer les modifications habituelles des item QML (rotation, effet, animation, etc.)Citation:
Tu sait si on peut créé une image avec JS et l'utiliser comme source dans qml?
Il faudrait créer une classe ImageObject, qui hériterait de QObject, et de rendre accessible les propriétés (avec Q_PROPERTY) et les fonctions (avec Q_INVOKABLE)
Effectivement, en 3D c'est pas génial. Pas moyen d'améliorer le rendu.
De plus, toutes les couleurs ne sont pas accessibles : sur la surface du cône, on a accès au valeurs HSV (h=0 à 1, s=1, v=0 à 1) et sur la base, on a les valeurs HSV (h=0 à 1, s=0 à 1, v=0). Pour les valeurs s!=1 et v!=1 en même temps, il faut accéder à l'intérieur du cône, ce qui n'est pas possible comme j'ai fait (notamment, on n'a pas les différentes valeurs de gris)
Bref, je laisse tomber cette approche
Je me suis demandé à quel point Qml était puissant. Vue que j'ai pas trouvé comment faire un image en JS, j'ai essayé cela pour voir. J'était surpris que ca passe :aie:Citation:
Envoyé par gbdivers
C'est marrant qu'ils n'ont pas pensés à un canvas pour faire du dessin. J'utilise qml avec QtCreator 2.1-béta. J'ai pas installé Qt 4.7 car elle devrais sortir trés bientôt il me semble donc je peut pas encore testé. En tous cas, j'ai l'impression de commencer à comprend la philosophie de la bête.Citation:
Envoyé par gbdivers
surtout que HSV et HSL sont des espaces cylindrique :PCitation:
Envoyé par gbdivers
Perso, je n'ai pas trouvé de super idée d'editeur de couleur :cry:
[edit]
tien y as un webview dans QML. J'ai peut être une piste :mouarf:
Faut avoir une compilation récente des sources de Qt, mais ca semble intéressant.Citation:
Envoyé par yan
Avec le webview je peut charger un bout de hmtl en y ajoutant un canvas et utiliser evaluateJavaScript
http://qt.developpez.com/doc/latest/...ascript-method
pour lui injecté du code js et lui faire dessiner sur le canva :mrgreen:
J'ai réussi à faire mon gradiant 8-)
Je sais pas si c'est une bonne solution :aie:
Sinon y as ce plugin qml :
http://gitorious.org/qml-painterplugin
Voilà une première version, on peut piquer la couleur et changer de couleur de fond.
C'est du c++, et ce n'était pas gagné vu mon incompétence notoire dans ce langage !
Le langage mis à part, Qt, pour le framework est vraiment sympa pour une première approche.
C'était de loin bien plus simple que de me farcir les particularités du langage.
allez hop je retourne debugger, il parait que mon bout d'appli supporte pas bien le redimensionnement (entre autres) :o
http://www.developpez.net/forums/att...e-1.png/?stc=1
En tout cas ça à l'air sympa le qml avec le JS, bien plus simple à écrire.
Félicitation ! Ça a l'air pas mal.Citation:
Voilà une première version, on peut piquer la couleur et changer de couleur de fond.
:arf:Citation:
En tout cas ça à l'air sympa le qml avec le JS, bien plus simple à écrire.
Tu verras le code et les explications vendredi de la semaine prochaine pour le QML. Tu verras que ce n'est pas si simple
Pour vous aider dans l'exercice Qt n°1, voici la description d'une méthode possible (il y a en d'autres) pour résoudre ce problème. Si vous n'en avez pas besoin, vous pouvez vous en passer.
Cette solution se base sur la création d'un nouveau widget, héritant directement de QWidget. Ce widget pourra recevoir la couleur principale via un slot et emettre la couleur sélectionnée via un signal.
Pour créer les nuances de gris, on va dessiner dans une QImage grâce à deux QLinearGradient. La fonction paintEvent sera utilisée pour dessiner la QImage représentant les nuances de gris et le curseur.
Donc, au final, vous devrez utiliser au moins les classes : QWidget, QImage et QLinearGradient.
Bon courage !
PS : si vous avez besoin de plus d'aide que ce qui est disponible ici en haut, n'hésitez pas à nous contacter par MP.
Arf, je n'ai découvert l'exercice Qt qu'hier soir, pourtant c'est pas faute qu'il soit en gros sur la page d'accueil :aie:
Je vais essayer de faire quelque chose ... personnellement j'aime bien celui de photoshop (enfin pour le peu que je l'aie utilisé), il est peut-être simple et tout carré mais bon au moins c'est fonctionnel (oui je sais, je n'ai pas l'âme d'un artiste mais je n'y peux rien, ça a toujours été comme ça :mrgreen:)
Je suis décidément vraiment mauvais ...
Déjà que j'ai passé une heure à déboguer mon programme alors que j'avais juste oublié le #include <QPainter> et ensuite pas moyen d'avoir un rendu correct :aie:
J'ai un widget carré de 256*256 mais je n'arrive pas à dessiner les deux dégradés. J'ai bien les deux QLinearGradient, un sur les axes des x et l'autre sur y mais je ne comprends pas comment mélanger les deux résultats. J'ai essayé avec le paramètre alpha (j'utilise le système RGB) mais on dirait bien que ce n'est pas comme ça qu'il faut faire :
http://www.developpez.net/forums/att...1&d=1283120541
J'ai eu beau chercher dans la doc là je sèche un peu ... quelqu'un pourrait me donner une piste ?
Sinon il y a toujours la méthode de la double boucle for en définissant tout à la main mais bon, ça me semble pas très élégant :roll:
EDIT : ha j'ai trouvé la fonction permettant de mixer les couleurs, reste à trouver les bons paramètres et c'est pas encore gagné :aie:
http://www.developpez.net/forums/att...1&d=1283123661
Petit rappel pour tous les participants :
Il reste que 3 jours pour poster ici vos réponses à cet exercice. Vous pouvez poster directement ici ou rédiger votre réponse dans un document et le mettre en pièce jointe.
Jouer le jeu : si quelqu'un pose une réponse, éviter de modifier la votre en fonction de ce que vous pourriez lire dedans.
Hello,
voilà ma version.
Il n'y à pas beaucoup d'option, quelques bugs de dessin (hum hum :whistle2:), mais j'ai pu voir quelques un des aspects graphiques de Qt et ai réussi à me dépatouiller du c++ donc je suis content !
Un screen :
Pièce jointe 66709
et les sources !
Pièce jointe 66710
C'est clair, les messages d'erreurs d'includes c'est l'horreur ! Tellement l'horreur que la prochaine fois j'essaierais de le faire en py ou un autre langage !!Citation:
Déjà que j'ai passé une heure à déboguer mon programme alors que j'avais juste oublié le #include <QPainter> et ensuite pas moyen d'avoir un rendu correct
... Peut être QML qui sait ^^
A plus
Voici mon code pour la version QML, avec la doc en pdf.
C'est très perfectible :
* la couleur principale par défaut est affichée mais aucune couleur sélectionnée par défaut.
* le widget n'est redimensionnable
Vous me direz si la version QML est plus simple que la version C++ :aie:
En tout cas tu as fais une super pres ! Ma copie à l'air pauvrette à côté.... J'avoue avoir même fais l'impasse de la doc du code : /
Ceci dit je regarderais ce soir, là je n'ai pas bien saisis ta méthode de détermination de la couleur pickée :aie:
a plus
@kaymak
Ne t'inquiète pas, tu as encore le temps de rédiger un petit quelque chose pour expliquer tes choix et faciliter la compréhension de ton code.
@autres
Vous avez eu le temps de préparer votre réponse à ce premier exercice Qt ?
Il vous reste encore un peu de temps, donc n'hésitez pas à peaufiner si vous voulez.
J'attends encore avant de poster mon code Qt/C++, pour ne pas vous influencer.
Bonsoir à tous,
Il ne vous reste qu'un peu plus d'une journée avant le rendu de la première partie du ColorPicker. Il est temps de paufiner votre code et de rendre celui-ci avant demain soir minuit.
Parce que je suis prince et que j'habite en Angleterre, ça fera 1h du matin pour les français (minuit heure de greenwich) ;)
N'oubliais pas de mettre les explications qui vont avec votre, je vous rappel qu'il s'agit d'un exercice de présentation.
Le résultat sera annoncé dans 1 semaine jour pour jour et la 2ème partie lancé en même temps ;)
Bon courage pour la dernière ligne droite !
J'aurais bien aimé terminé, améliorer mon colorpicker, mais je ne pense pas que je vais repasser ici avant très longtemps, je met en ligne les sources.
Dernier jour pour rendre les solutions !
Voici la mienne, version Qt/C++
Tu aurais pu faire le ménage et enlever :Citation:
Envoyé par gbdivers
etCode:QT += declarative
Je vois déjà un certains John sortir les cartons rouges des malus ;)Code:#include <qdeclarative.h>
Sinon :ccool:
Je comprend pas de quoi tu parles... :aie:
(je l'ai vu après avoir posté et j'ai pensé, naïvement, que bip bip ne passerait pas avant que j'ai le temps d'uploader les fichiers corrigés :))
C'est quoi exactement ta définition de bipbip ? Comment tu imagines pouvoir être plus rapide ? Tu dérailles coyote !Citation:
Envoyé par gbdivers
Heu en voyant ce qu'a fait gbdivers, j'ai honte ...
Je n'y ai certainement pas passé assez de temps mais quand même, j'aurais bien aimé rendre un truc mieux (aujourd'hui impossible, trop de trucs à faire :cry:)
Il y a deux trois commentaires dans le code, histoire de dire j'ai expliqué :roll:
En tout cas, ça ne va pas prendre longtemps à corriger :aie:
La première partie de l'exercice Qt est maintenant terminée !
Nous avons donc 4 dépôts de sources et je remercie déjà ces personnes pour leur participation. Les résultats seront disponible sur ce post au plus tard vendredi prochain qui sera également la date de l'annonce de la prochaine partie du même sujet.
A bientôt ;)
Je viens de voir qu'il y avait une erreur dans mon code. Lors du mouseReleaseEvent, je ne teste pas si la souris est encore dans le widget. Il faut remplacer la fonction par :
Code:
2
3
4
5
6
7
8
9
10
11
12
Trop tard ;) S'il n'y avait que ça qui n'allait pas dans ton code :aie:Citation:
Envoyé par gbdivers
Et voilà, la correction de la première partie est terminée !
Pour rappel, nous avions 4 participants à savoir kaymak, gbdivers, abdelite et myzu69.
Et le vainqueur pour cette première partie est .......... gbdivers, félicitation à lui !
:lahola:
L'ensemble des participations étaient d'un bon niveau C++ et Qt mais certaines avaient quelque soucis concernant l'exactitude de la sélection ou du rendu de la couleur. Seul le widget de gbdivers était parfaitement fonctionnel même si quelques améliorations peuvent être faite.
Les corrections de chaque participation vont être poster dans quelques instant à la suite de ce post. Je vous rappel que le temps de correction étant très court, elle a été faite de manière subjective et ne respecte pas une grille de notation bien précise comme l'aurait été un défi Qt.
La partie 2 de l'exercice sera donc annoncé vendredi avec le code du widget de gbdivers améliorer de manière à respecter les malus qu'il a reçu :p
A vendredi
Commentaires :
Utilisation des QLinearGradients pour dessiner le dégradé dans une QImage puis sur le widget. L'affichage et la sélection est correcte mais le dégradé commence à 1 au lieu de 0, ce qui signifie qu'on doit perdre une couleur. En passant à 0, la sélection du point en bas à droite est incorrecte.
Lors du redimensionnement de la fenêtre, la couleur sélectionnée change en fonction du redimensionnement effectué, ce qui est un comportement étrange. Il serait préférable à mon goût de ne pas sélectionner de couleur ou de sélectionner un point fixe (noir, blanc, couleur, couleur centrale...)
La couleur peut être sélectionnée à l'aide de tous les boutons de la souris, il serait sûrement préférable de limiter cette tâche à un seul bouton (gauche par exemple).
Le gradient dans l'image n'est dessiné qu'une seule fois lors de la création du widget et est ensuite remis à l'échelle en fonction de la taille du widget, ce qui n'est pas l'idéal, à voir si on n'a pas trop de pertes ou de modifications des couleurs dues à la transformation.
À l'erreur près de la perte d'une couleur sur la plage de 0 à 256 et de la mise à l'échelle de la QImage, le fonctionnement du widget est très bien réalisé.
Les plus :
- présence de commentaires dans le code ;
- utilisation des signaux et des slots pour la communication entre widgets ;
- utilisation d'une sous classe de QWidget permettant de réimplémenter les gestionnaires événementiels afin de dessiner et de sélectionner la couleur dans le gradient ;
- utilisation d'un curseur originale ;) pour dessiner le point de sélection ;
- la sélection continue d'être effectuée quand la souris est pressée et est en déplacement en dehors du widget ;
- code C++ très correct.
Les moins :
- peu d'originalité dans le design du widget, forme rectangulaire ;
- pas de document annexe pour expliquer les choix de programmation ou les étapes de développement ;
- sélection possible avec tous les boutons de la souris ;
- scaled de l'image contenant le gradient ;
- pas de changement de curseur permettant de savoir qu'on est en mode sélection.
Capture d'écran :
http://qt.developpez.com/exercices/0...ture_ecran.png
Sources :
Archive
Commentaires :
Le widget fonctionne correctement avec l'affichage de l'intégralité des nuances de gris d'une couleur ainsi qu'une sélection précise et correcte de la couleur pointée. Utilisation d'une méthode de calcul de l'ensemble des pixels avec la fonction QColor::fromHsvF().
Le seul bémol est l'utilisation de la fonction setMouseTracking(true) et d'un booléen m_tracking pour savoir si le bouton de la souris est pressé ou non pour sélectionner la couleur dans mouseMoveEvent à ce moment-là. Lorsque setMouseTracking est désactivé (comportement par défaut), la fonction mouseMoveEvent est cependant appelée lorsqu'un bouton de la souris est pressé. Un test pour savoir quel bouton de la souris est pressé dans la fonction mouseMoveEvent suffirait largement et éviterait d'appeler cette fonction chaque fois que la souris se déplace sur le widget (même si la condition sur m_tracking fait qu'il ne ce passe rien).
La sélection de la couleur s'arrête lorsqu'on sort du widget et recommence à l'endroit ou l'on rentre de nouveau provoquant un saut du curseur. Il serait intéressant de permettre de continuer la selection en dehors du widget. De plus l'erreur QImage::pixel: coordinate (693,-4) out of range est affichée sur la sortie standard lorsque la souris est pressé et déplacé en dehors du widget (corrigé par le participant après coup).
Très bonne participation dans l'ensemble !
Les plus :
- réalisation d'un document PDF expliquant les choix de conception ;
- changement du point de sélection d'une couleur (blanc ou noir) en fonction de la zone pointée pour un meilleure contraste ;
- utilisation des signaux et des slots pour la communication entre widgets ;
- utilisation d'une sous classe de QWidget permettant de réimplémenter les gestionnaires événementiels afin de dessiner et de sélectionner la couleur dans le gradient ;
- utilisation d'une simple ellipse pour dessiner le point actuellement selectionné ;
- personnalisation du point de sélection possible ;
- code C++ de bonne qualité.
Les moins :
- peu d'originalité dans le design du widget, forme rectangulaire ;
- aucun commentaire dans le code notamment sur le calcul HSV ;
- utilisation de setMouseTracking(true) ;
- pas de changement de curseur permettant de savoir qu'on est en mode sélection ;
- arrêt de la sélection de la couleur quand on sort du widget.
Capture d'écran :
http://qt.developpez.com/exercices/0...ture_ecran.png
Sources :
Archive
Commentaires :
L'indentation n'est pas toujours des meilleures. Par exemple, un return aligné sur l'initialisation de la variable retournée : sémantiquement, on peut comprendre qu'on fasse tout ce qui concerne une variable dans un bloc. La retourner, c'est plus du niveau de la fonction que de la variable. Ne pas hésiter à aérer le code : parfois un retour à la ligne entre les initialisations et le traitement, parfois pas.
Peu d'explication sur les choix et les valeurs des variables. Le nombre 21 se balade dans le code... Si il s'agit d'une constante de taille par exemple, le définir dans le header, un namespace anonyme ou n'importe quoi mais ne pas l'utiliser directement dans le code. Si tu veux changer la hauteur de ton widget tu dois ensuite la modifier partout. Pour 255, ça peut se comprendre car c'est une valeur universelle qui ne changera jamais.
Le nom du widget, GradientValue, me paraît très mal choisi : il correspond à une valeur, pas à un widget ou à quelque contrôle permettant de choisir une couleur. Son nom indique un helper, pas un élément graphique. Un nom comme ColorChooser aurait été bien plus explicite.
Il n'y pas de sélection a proprement parler avec un clique de la souris et un symbole permettant de voir le point sélectionné, l'utilisation de setMouseTracking(true) est très étrange pour un widget de la sorte mais implémenté correctement par rapport aux autres participations.
Comportement très étrange à mon goût, le widget ne fait pas la même taille en fonction de la couleur sélectionné. Je n'ai jamais vu un widget de sélection de gradient changer de taille. Ton calcul de la largeur du widget est fait à l'aide de la valeur de la saturation. Tu peux nous expliquer pourquoi ?
Les valeurs choisis ne sont pas correctes quand on sélectionne une autre couleur que le blanc par contre la pixmap affiché est bonne :
http://qt.developpez.com/exercices/0...te_erreurs.png
Si j'ai bien compris dans ton message ta participation n'était pas totalement fini et prore, mais je me permet de faire quelques commentaires sur le code, cela peut t'aider ainsi que n'importe quel lecteur.
Classe Window :
Code inutile ->
La fonction paintEvent n'a aucune utilité ici et n'est absolument pas virtuelle pure donc obligatoire.
Améliorations ->Code:
2
3
4
5
Lorsqu'on veut sélectionner une couleur on repars toujours de la couleur blanche à cause de cette ligne de code :
Il serait plus logique de repartir de la couleur précédemment sélectionné avec :Code:m_color = QColorDialog::getColor(Qt::white, this);
Classe GradientValue :Code:m_color = QColorDialog::getColor(m_color, this);
Qu'elle est l'intérêt d'avoir tes attributs en protected alors qu'ils ont soit un accesseur/modificateur public, soit uniquement interne au widget. A mettre tout en private.
L'idée d'utiliser QPixmapCache pour stocker les pixmap générés est super coté optimisation mais ne fonctionne que dans le cas d'un widget de taille fixe (ce qui est ton cas).
Du code de test dans une projet rendu ça ne le fait pas trop...
Au final participation un peu trop brouillon, il faudrait essayer de rendre un projet plus propre. La sélection de la valeur dans le gradient est à revoir car incorrecte par rapport à la pixmap affichée.Code:QMessageBox::information(this, "test", QColor::fromHsl(65, 98, 255).name());
Les plus :
- utilisation des signaux et des slots pour la communication entre widgets ;
- utilisation d'une sous classe de QWidget permettant de réimplémenter les gestionnaires événementiels afin de dessiner et de sélectionner la couleur dans le gradient ;
- utilisation de QPixmapCache pour mettre en cache la pixmap calculé ;
- code C++ correct.
Les moins :
- peu d'originalité dans le design du widget, forme rectangulaire ;
- aucun commentaire dans le code notamment sur la création de la pixmap generatePixmap() ;
- utilisation de setMouseTracking(true) peu utile mais bien utilisé ;
- pas de changement de curseur permettant de savoir qu'on est en mode sélection ;
- pas de sélection avec clique de souris ;
- widget changeant de taille en fonction de la couleur choisis ;
- la couleur affiché lors du survol de la souris est incorrecte malgré une pixmap correcte à l'écran.
Capture d'écran :
http://qt.developpez.com/exercices/0...ture_ecran.png
Sources :
Archive
Commentaires :
Deux énormes problèmes pour cette contribution : elle ne compile tout simplement pas dans la version donnée (QColor* ColorSlide::couleur_choisie(); au lieu de QColor* couleur_choisie();, dans tous les fichiers d'en-têtes). Ensuite, le widget ne fonctionne correctement que sous Mac OS X (testé avec Windows Vista 32 bits et le Qt SDK 2010.05 RC1, Windows 7 64 bits et Qt 4.6.3 et Mac OS X 10.6.4, XCode 3.2.3 et le binaire Qt 4.7.0 RC1).
Par contre, c'est bien celui que j'aurai le plus apprécié ! C'est le seul qui permet de changer la couleur sur laquelle se base le widget, par exemple. C'est la seule à envisager l'étape suivante dès le début ! Quand il fonctionne, il fonctionne vraiment parfaitement !
Dans le code, je me demande où sont passés les commentaires. Surtout que la solution proposée n'est pas très simpliste, loin de là. Ils n'auraient pas du tout été superflus, loin de là.
Les conventions de codage ne sont pas non plus toujours hyper compréhensibles. Remarquons déjà l'effort de se limiter à environ 80 colonnes par ligne, ce qui est tout bon mais mène parfois à des extrémités peu lisibles :
Ici, sur une ligne, on atteint presque les 80 caractères. Ce qui me dérange le plus, c'est de fermer la parenthèse de fillRect et de QBrush en même temps alors que l'un est clairement subordonné à l'autre et que cela est déjà marqué par un espace à l'ouverture des parenthèses...Code:
2
3p.fillRect( rect, QBrush( QColor(this->_backgroundColor->toRgb()) ));
Remarquons aussi que l'API proposée n'est pas très Qt-friendly : les classes sont en CamelCase, on s'y attendait ; par contre, leurs méthodes sont nommées tout à fait différemment : mettre_a_jour_previsu, par exemple. Ce n'est pas mauvais en soi, c'est dépaysant quand on utilise Qt. Il aurait fallu tout mettre à la manière de Qt (s'ils ont des règles de codage, c'est aussi pour guider les utilisateurs, faire en sorte qu'ils ne doivent pas en apprendre plusieurs pour chaque projet - la leur et celle de Qt). De même, la langue utilisée : très personnellement, je trouve ce genre de code assez choquant visuellement (signal et slot définis dans des classes hors Qt) :
On a des variables nommées d'une manière extrêmement mauvaise : int _taille_echantillon;. Là, c'est à éviter d'urgence : tous les noms de variables commençant par _ sont réservés au compilateur.Code:
2
3connect(this->graphicsView, SIGNAL(color_picked(QColor*)), this, SLOT(mettre_a_jour_previsu(QColor*)));
Aussi, parfois des inconsistances. Soit un espace avant, soit un espace avant et un après, jamais l'un et l'autre :
Soit on ferme sur la dernière ligne, soit on ferme sur la ligne suivante :Code:
2
3void moved(QMouseEvent *event); void color_picked(QColor * color);
Ici, pour être aussi explicite que possible, j'ai pris du code contigu... ce qui est encore plus choquant à la lecture !Code:
2
3
4
5
6
7
8
9
10QPixmap pixmap = QPixmap::grabWidget(this, mouseEvent->x(), mouseEvent->y(), this->_taille_echantillon, this->_taille_echantillon); emit color_picked( this->couleurMoyenne( pixmap ) );
En conclusion, niveau interface utilisateur, si le widget fonctionnait sur tous les OS, il aurait pu facilement être premier ; là, ce n'est pas possible à cause de ce problème. Le code est pas trop mal mais tu t'es surement un peu compliqué pour faire ce widget et je pense qu'en regardant celui qui est premier tu vas te rendre compte de la simplicité ;) Si tu continue la deuxième partie et corrige tes problèmes, tu peux très largement conserver ton widget.
Les plus :
- widget qui fonctionne très bien quand il fonctionne ;) ;
- code C++ correct.
Les moins :
- ne compile que sous Mac OS X (on a pas tous la chance d'en avoir un...) ;
- pas de document annexe pour expliquer les choix de programmation ou les étapes de développement ;
- code légèrement compliqué alors que la solution pourrait être beaucoup plus claire :
- style de programmation parfois étrange.
Capture d'écran :
http://qt.developpez.com/exercices/0...ture_ecran.png
Sources :
Archive
Gbdivers à également fournit une version du widget réalisé avec QML, le nouveau langage de Qt faisant partie de Qt Quick. Etant le seul participant à avoir réaliser une version QML, celle-ci est donc mise hors compétition. Je dois également avouer que je n'ai pas actuellement les connaissances pour la corriger ou juger de l'efficacité ou l'inutilité du code présent :p
Dourouc nous fait quand même le plaisir de laisser quelques commentaires :
Tout d'abord, disons que ce widget m'a étonné. Au premier abord, un simple color picker. Puis j'ai vu les couleurs s'alterner ! Inattendu ! Pas pratique à l'usage du tout mais c'est esthétique ! Au moins, on sait que tout est prévu pour changer dynamiquement la couleur, ce qui se révèle capital en utilisation réelle. Aussi, petit truc qui n'apparaît pas instantanément : la couleur sélectionnée est affichée dans une autre fenêtre. Ceci m'a bien l'air prévu pour continuer l'exercice !
Niveau code, maintenant. Ce n'est pas très glorieux. On trouve de tout dans les fichiers. Un bel exemple :
Oui, c'est bien aligné ; c'est même esthétique tant qu'on n'essaye pas de comprendre. Maintenant, voir que l'émission d'un signal a droit à sa ligne en solo et qu'une fonction un peu plus élaborée est remise dans son cagibi-ligne, ça me rappelle de mauvais souvenirs de code impossible à maintenir.Code:
2
3
4
5
6
7
8
9
10
11
12
13
Parfois une petite coquille, rien de grave :
Parfois, je dois me dire assez étonné :Code:
2
Certaines lignes sont absolument illisibles pour moi (cette notion variant ici assez fortement) :Code:
2
Je trouve que ceci est beaucoup plus lisible :Code:
2
3
4ColorPickerContext.selected_red = (1 - (cursor.y / height)) * (1 + (cursor.x / width) * (main_red - 1))
À part ça, je dois dire que rien n'est à redire.Code:
2
3
4
5
6
7
8
9
10
11ColorPickerContext.selected_red = ( 1 - (cursor.y / height) ) * ( 1 + (cursor.x / width) * (main_red - 1) )
Capture d'écran :
http://qt.developpez.com/exercices/0...ml_capture.png
Sources :
Archive
Outch, pour moi c'est bien moins lisible ! (Peut-être du aux tabulations qui rendent très mal !)Citation:
Envoyé par johnlamericain
Je verais plus un truc comme :
Code:
2
C'est normale et devrais même y avoirCitation:
Parfois, je dois me dire assez étonné :
Code:if (hue >= 1.0) hue=0.0;
le hue représente une position sur un cercle. Le 0 et 1 sont la même position.Code:if (hue < 0.0) hue=1.0;
Niveau code, maintenant. Ce n'est pas très glorieux. On trouve de tout dans les fichiers.
En effet, j'avoue. Ce n'est pas comme ça que je code d'habitude :aie:
En effet, j'ai documenté le code du QML et de GradientWidget mais pas les autres classes...Citation:
Parfois, je dois me dire assez étonné :
Citation:
if (hue >= 1.0) hue=0.0;
Comme l'a indiqué Yan, la teinte est codé cycliquement de 0.0 à 1.0 (0.0 et 1.0 étant la même teinte, le rouge). En fait, cela correspond en degré à la gamme 0° à 360°. Et évidement, 360° = 0°, 370° = 10°, etc.
Pourquoi pas de : "if (hue < 0.0) hue=1.0;" ?
En fait, il faut regarde la ligne juste au dessus :
C'est le code contenu dans la fonction appelée automatiquement par le timer pour mettre à jour la teinte. Donc, comme on ne fait qu'incrémenter, pas besoin de vérifier que hue<0Citation:
hue += 0.01; i
if (hue >= 1.0) hue=0.0;
Petite remarque concernant "hue=0.0;". J'aurais pu écrire "hue -= 1.0;" et on pourrait s'attendre à avoir la suite :
C'est une erreur a ne pas faire !Citation:
0.0 -> 0.01 -> 0.02 -> (...) -> 0.98 -> 0.99 -> 1.0 = 0.0 -> etc.
Quand on regarde ce qui se passe en réalité, on obtient en utilisant "hue -= 1.0;", selon les cycles :
On voit que la différence entre la valeur mesuré et la valeur attendue (0) diverge. Cela est du à l'encodage des nombres réels par l'ordinateur !Code:
2
3
4
5
6
7
8
Ici, l'erreur est sans importance, mais dans d'autres cas, cela peut devenir génant.
Je trouve ma version plus lisible : les goûts et les couleurs...Citation:
Je trouve que ceci est beaucoup plus lisible :
Bravo aux participants, et plus particulièrement à gbdivers !
L'indentation est parfaite, dit moi ou ça coince. Pour le return mal aligné, je ne vois franchement pas où... Pour les sauts de lignes c'est vrai que j'aurais dû plus aérer.Citation:
L'indentation n'est pas toujours des meilleures. Par exemple, un return aligné sur l'initialisation de la variable retournée : sémantiquement, on peut comprendre qu'on fasse tout ce qui concerne une variable dans un bloc. La retourner, c'est plus du niveau de la fonction que de la variable. Ne pas hésiter à aérer le code : parfois un retour à la ligne entre les initialisations et le traitement, parfois pas.
Pour le 21 ça se comprends aussi désolé ! 42 / 2 = 21 ! :zekill:Citation:
Peu d'explication sur les choix et les valeurs des variables. Le nombre 21 se balade dans le code... Si il s'agit d'une constante de taille par exemple, le définir dans le header, un namespace anonyme ou n'importe quoi mais ne pas l'utiliser directement dans le code. Si tu veux changer la hauteur de ton widget tu dois ensuite la modifier partout. Pour 255, ça peut se comprendre car c'est une valeur universelle qui ne changera jamais.
Sinon je vais voir si je peux me rattraper avec la partie 2 dès demain. Bonne continuation à vous.
Une demi-réponse universelle, est-ce réellement une réponse ? J'aurais tendance à dire que non : si on te coupe en deux, tu ne formes pas deux humains, ni deux demi-humains mais bien une bouillie difforme (tout dépend de la coupe, c'est vrai mais dans tous les cas ce ne sera pas beau à voir).Citation:
Envoyé par Abdelite
