Discussion :

[feda12]

Merci de ton explication Amnell, c'est effectivement un point qui est assez compliqué, je comptais passer par une QDeclarativeView, mais je pense que je vais revoir ça finalement.

Mais là je bloque sur le serveur, sur la papier c'est bien beau, mais à coder c'est autre chose

[Amnell]

Merci de ton explication Amnell, c'est effectivement un point qui est assez compliqué, je comptais passer par une QDeclarativeView, mais je pense que je vais revoir ça finalement.

Je ne comprends pas trop le "je comptais passer par une QDeclarativeView" car quoi qu'il en soit, on doit bien passer par une classe QDeclarativeQuelqueChose pour afficher la scène QML, que ce soit directement dans une QGraphicsScene ou bien dans une QDeclarativeView.

Mais là je bloque sur le serveur, sur la papier c'est bien beau, mais à coder c'est autre chose

L'intérêt d'un concours, c'est de se donner à fond et de progresser. Quel intérêt de faire toujours la même chose et de ne jamais explorer de nouveaux environs ? Si tu as des questions, n'hésite pas à les poser.

[feda12]

Le "je comptais passer par une QDeclarativeView", c'était qu'en fait au départ, je comptais coder une fenêtre normale en C++ et d'intégrer dans des layouts les widgets QML déclarés dans des QDeclarativeView, je me suis mal exprimé.

J'ai réalisé un serveur basique auquel on peut se connecter, cependant, je ne suis pas sur d'avoir choisi la meilleure solution afin de vérifier l'identité du client puisque je la vérifie seulement lorsque celui-ci émet une demande (par exemple: lister tous les patients) via un paquet genre "taillePseudo|pseudo|tailleMdp|mdp|tailleCmd|cmd". De plus, j'ai encore quelques principes qui m'échappent, comme par exemple retourner une liste d'objets.

[Amnell]

Pour résumer, tu partais sur la même idée que moi au départ.

Concernant le serveur, je pense que tu ne t'y prends pas correctement : tu souhaites juste envoyer une QString et la parser par la suite ? Et si le pseudo/autre contient le séparateur, comment déterminer les bonnes choses ? Pour envoyer un paquet avec le nom d'utilisateur puis le mot de passe, je fonctionne comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
    QByteArray packet;
    QDataStream out(&packet, QIODevice::WriteOnly);
 
    // ...
 
    out << username;
    out << password;
 
    // ...
 
    write(packet);

Et la récupération est très simple :

Code :

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

1
2
3
4
5
6
void XXX::handleSomething(QDataStream *data, ...)
{
    QString username, password;
 
    *data >> username;
    *data >> password;

[feda12]

Oui, je comptais utiliser une QString dans l'esprit, c'est à dire que chaque commande sera envoyé à son module correspondant, c'est vrai que ta solution me va parfaitement, merci beaucoup.

[LittleWhite]

Plus qu'un mois
(Il faut que j'aille fouetter mes coéquipiers pour voir le projet avancé )

Sinon, je voulais savoir, je crois me rappeler qu'il est écrit qu'il faudra expliquer nos choix sur les différents points du défi (j'imagine, l'architecture réseau et autres).
Comment allons nous expliquer nos choix ? Dans une documentation jointe au projet ? ou par oral ? ou alors, par une liste de questions à répondre ?

[dourouc05]

(Il faut que j'aille fouetter mes coéquipiers pour voir le projet avancé )

Fouette, fouette, vas-y, mais ne leur fais pas trop mal !

Sinon, je voulais savoir, je crois me rappeler qu'il est écrit qu'il faudra expliquer nos choix sur les différents points du défi (j'imagine, l'architecture réseau et autres).
Comment allons nous expliquer nos choix ? Dans une documentation jointe au projet ? ou par oral ? ou alors, par une liste de questions à répondre ?

C'est dans les bonus.

Pour expliquer vos choix... il faut expliquer vos choix. Un fichier décrivant tout ce à quoi vous avez pensé, pourquoi certaines voies n'ont pas été retenues, les points principaux du débat sur l'architecture retenue, etc. Pas de questions plus précises que ça, ça risque de varier d'un projet à l'autre.

[johnlamericain]

Il reste un peu moins d'un mois au défi et je suis sur que vous avancez bien

Si vous avez rencontrer des problèmes et découvert leurs solutions, n'hésiter pas à faire partager ces précieuses informations à tout le monde en proposant des questions pour la FAQ Qt !

Bonne continuation !

[johnlamericain]

Il vous reste un peu plus d'une dizaine de jours pour finir votre défi, le peaufiner et nous le soumettre !

Quel est l'état actuel de votre projet ?

[0x4e84]

Il vous reste un peu plus d'une dizaine de jours pour finir votre défi, le peaufiner et nous le soumettre !

Quel est l'état actuel de votre projet ?

Encore beaucoup à faire de mon côté. Ca va se finir au sprint...

[Amnell]

Encore beaucoup à faire de mon côté. Ca va se finir au sprint...

Je n'aurais pas pu dire mieux, moi qui pensais qu'il restait encore un mois et demi . Quoi qu'il en soit, je sais quoi faire des derniers week-ends.

[johnlamericain]

Bon courage alors, les récompenses seront au rendez-vous

[0x4e84]

Bon courage alors, les récompenses seront au rendez-vous

Merci. C'est une belle motivation!

[Amnell]

Bonjour,

J'ai une petite question à poser aux membres du jury pour savoir ce qu'ils pensent de la question.

Je souhaite réaliser entièrement mon interface graphique avec QML. Un problème se pose alors : comment gérer les éléments graphiques un peu poussés ? Par exemple, si je veux réaliser une courbe changeant dynamiquement pour le cardiogramme, je vais avoir le choix entre quelques solutions :

Nécessairement autre chose que créer dynamiquement cinquante mille rectangles avec Qt.createComponent() puis les détruire quelques ms après avec la fonction delete() (ou pire, en les retirant depuis le C++ avec viewer->scene()->removeItem()).

Je pourrais également créer le widget depuis le C++ (avec Qwt par exemple), faire un viewer->scene()->addWidget(linstancedelaclassedeQwt) puis manipuler le tout avec le QGraphicsProxyWidget* résultant.

Avec Qt Quick, il est possible d'étendre QML en créant de nouveaux composants QML, des classes C++ dérivées de QObject si le composant ne doit pas être graphique ou de QDeclarativeItem si le composant doit avoir un rendu graphique. Si l'on crée une classe nommée "MyClass", dérivée de QDeclarativeItem, on aurait juste à faire un qmlRegisterType pour pouvoir l'utiliser en tant que composant QML :

Code :

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

1
2
3
4
5
import ...
 
MyClass {
    property: value;
}

Ma question est donc : est-ce que la solution d'étendre QML peut permettre de gagner des points ou du moins de ne pas en perdre vu que ça passe côté C++ via une classe indépendante ?

[johnlamericain]

Ma question est donc : est-ce que la solution d'étendre QML peut permettre de gagner des points ou du moins de ne pas en perdre vu que ça passe côté C++ via une classe indépendante ?

Qt Quick et les composants QML sont encore jeune et c'est normal que tu ne puisses pas faire des interfaces très (très) poussés qu'en QML. Il n'y a pas de problème pour que tu passes par une classe C++.

Il faut savoir que les points sur le QML ne sont pas fixes dans le sens ou tu les a ou pas. C'est de 0 jusqu'à 8 (si je me souviens bien) et du coup l'utilisation d'autre chose ne t'enleverra pas des points, mais plus tu l'utilisera pour différentes choses (et à bonne escient), t'en fera gagner.

[gbdivers]

l'utilisation d'autre chose ne t'enleverra pas des points

Je vais être un peu plus méchant que John
On n'enlèvera pas de point si on utilise autre chose que le QML. Par contre, quand on a le choix des outils à utiliser (QML, C++, lib externe), ce choix ne doit pas être fait au hasard. Donc vous pourrez peut être perdre des points pour avoir utiliser le mauvais outil pour un problème.
Ca me fait penser au problème du color picker que l'on avait proposé il y a quelques mois. J'avais fait une version QML qui était peut performante et qui posait de problème de scintillement. La version C++ était la bonne approche.

Bon courage

[Amnell]

On n'enlèvera pas de point si on utilise autre chose que le QML. Par contre, quand on a le choix des outils à utiliser (QML, C++, lib externe), ce choix ne doit pas être fait au hasard.

La question était surtout portée sur les mots présents dans la page du concours : est-ce que l'extension de QML par Qt Quick (même module) est un plus pour l'application si la nécessité est présente, par exemple pour réaliser quelque chose d'initialement non réalisable uniquement avec les composants de base fournis par QML ? L'ambiguïté est présente car le fait de créer un composant QML via Qt Quick (C++) va nécessairement mener à mieux exploiter QML.

[LittleWhite]

* LittleWhite demande à ce que gbdivers ne soit pas dans le jury
(Enfin, cela importe peu si j'arrive pas à rendre ma copie à temps)

Note un peu plus sérieuse: En voyant ce que demande gbdivers, je serais tenté de pensé qu'il faut une doc très complête, dans le sens -> cahiers des charges et cahier des choix (je viens de l'inventer celui là) pour réponse à toute les questions. Vu que je doute qu'il y ai un échange après la date limite (genre d'oral).

Note 2: Il était tout de même vraiment dur (complet ?) ce défi

[gbdivers]

Pas d'inquiétude. Le plus important n'est pas la sévérité de la notation (en fait, je suis assez gentil en général dans les notations) ou l'avancement de votre projet dans l'absolu. Le plus important est ce que vous avez fait par rapport aux autres équipes

[LittleWhite]

* LittleWhite espère maintenant que les autres équipes n'ont rien fait