Discussion :

[Invité]

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.

[gbdivers]

Dernier jour pour rendre les solutions !

Voici la mienne, version Qt/C++

[johnlamericain]

Dernier jour pour rendre les solutions !

Voici la mienne, version Qt/C++

Tu aurais pu faire le ménage et enlever :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

QT       += declarative

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#include <qdeclarative.h>

Je vois déjà un certains John sortir les cartons rouges des malus

Sinon

[gbdivers]

Je comprend pas de quoi tu parles...

(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 )

[johnlamericain]

Je comprend pas de quoi tu parles...

(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 !

[myzu69]

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 )

Il y a deux trois commentaires dans le code, histoire de dire j'ai expliqué

En tout cas, ça ne va pas prendre longtemps à corriger

[johnlamericain]

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

[gbdivers]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
void GradientWidget::mouseReleaseEvent(QMouseEvent *event)
{
    if (event->button() == Qt::LeftButton)
    {
        m_tracking = false;
        if (rect().contains(event->pos()))
        {
            m_cursor_position = event->pos();
            updateSelectedColor();
        }
    }
}

[johnlamericain]

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.

Trop tard S'il n'y avait que ça qui n'allait pas dans ton code

[johnlamericain]

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 !



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

[johnlamericain]

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 :



Sources :

Archive

[johnlamericain]

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 :



Sources :

Archive

[johnlamericain]

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 :



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.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void Window::paintEvent(QPaintEvent* argPaintEvent)
{
    Q_UNUSED(argPaintEvent);
 
}

Améliorations ->

Lorsqu'on veut sélectionner une couleur on repars toujours de la couleur blanche à cause de cette ligne de code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

m_color = QColorDialog::getColor(Qt::white, this);

Il serait plus logique de repartir de la couleur précédemment sélectionné avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

m_color = QColorDialog::getColor(m_color, this);

Classe GradientValue :

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

QMessageBox::information(this, "test", QColor::fromHsl(65, 98, 255).name());

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.

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 :



Sources :

Archive

[johnlamericain]

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
    p.fillRect( rect,
                QBrush( QColor(this->_backgroundColor->toRgb()) ));

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

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
    connect(this->graphicsView, SIGNAL(color_picked(QColor*)),
            this, SLOT(mettre_a_jour_previsu(QColor*)));

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.

Aussi, parfois des inconsistances. Soit un espace avant, soit un espace avant et un après, jamais l'un et l'autre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
    void moved(QMouseEvent *event);
    void color_picked(QColor * color);

Soit on ferme sur la dernière ligne, soit on ferme sur la ligne suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
        QPixmap pixmap =
                QPixmap::grabWidget(this,
                                    mouseEvent->x(),
                                    mouseEvent->y(),
                                    this->_taille_echantillon,
                                    this->_taille_echantillon);
        emit color_picked(
                this->couleurMoyenne( pixmap )
                );

Ici, pour être aussi explicite que possible, j'ai pris du code contigu... ce qui est encore plus choquant à la lecture !

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 :



Sources :

Archive

[johnlamericain]

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
	void    selectedColorChanged()
    {
        emit colorSelected(QColor::fromRgbF(selected_red, selected_green, selected_blue));
    }
 
    // 5 lignes utiles
 
    float   selectedRed() const { return selected_red; }
 
	// 2 lignes utiles
 
	void    setSelectedRed(const float red) { selected_red = red; selectedColorChanged(); }

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.

Parfois une petite coquille, rien de grave :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
setWindowTitle("Selected color");;

Parfois, je dois me dire assez étonné :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if (hue >= 1.0) hue=0.0;

Certaines lignes sont absolument illisibles pour moi (cette notion variant ici assez fortement) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
        ColorPickerContext.selected_red =
                (1 - (cursor.y / height)) *
                (1 + (cursor.x / width) * (main_red - 1))

Je trouve que ceci est beaucoup plus lisible :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
        ColorPickerContext.selected_red =
                (
					1
				  - (cursor.y / height)
				)
				*
                (
					1
				  + (cursor.x / width) * (main_red - 1)
				)

À part ça, je dois dire que rien n'est à redire.

Capture d'écran :



Sources :

Archive

[bobti89]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
        ColorPickerContext.selected_red =
                (
					1
				  - (cursor.y / height)
				)
				*
                (
					1
				  + (cursor.x / width) * (main_red - 1)
				)

Outch, pour moi c'est bien moins lisible ! (Peut-être du aux tabulations qui rendent très mal !)
Je verais plus un truc comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ColorPickerContext.selected_red =   ( 1 - (cursor.y / height)                  )
                                  * ( 1 + (cursor.x / width ) * (main_red - 1) )

[yan]

Parfois, je dois me dire assez étonné :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (hue >= 1.0) hue=0.0;

C'est normale et devrais même y avoir

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (hue < 0.0) hue=1.0;

le hue représente une position sur un cercle. Le 0 et 1 sont la même position.

[gbdivers]

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

Parfois, je dois me dire assez étonné :

if (hue >= 1.0) hue=0.0;

En effet, j'ai documenté le code du QML et de GradientWidget mais pas les autres classes...
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 :

hue += 0.01; i
if (hue >= 1.0) hue=0.0;

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

Petite remarque concernant "hue=0.0;". J'aurais pu écrire "hue -= 1.0;" et on pourrait s'attendre à avoir la suite :

0.0 -> 0.01 -> 0.02 -> (...) -> 0.98 -> 0.99 -> 1.0 = 0.0 -> etc.

C'est une erreur a ne pas faire !
Quand on regarde ce qui se passe en réalité, on obtient en utilisant "hue -= 1.0;", selon les cycles :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
cycle		différence
1		0,00000061
10		0,00000597
20		0,00001193
50		0,00002981
100		0,00005961
200		0,00011922
300		0,00017882

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 !
Ici, l'erreur est sans importance, mais dans d'autres cas, cela peut devenir génant.

Je trouve que ceci est beaucoup plus lisible :

Je trouve ma version plus lisible : les goûts et les couleurs...

[Invité]

Bravo aux participants, et plus particulièrement à gbdivers !

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.

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.

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.

Pour le 21 ça se comprends aussi désolé ! 42 / 2 = 21 !

Sinon je vais voir si je peux me rattraper avec la partie 2 dès demain. Bonne continuation à vous.

[dourouc05]

Pour le 21 ça se comprends aussi désolé ! 42 / 2 = 21 !

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