Discussion :

[0x4e84]

Bonsoir amis Qt-istes,

Au vu des participations déjà annoncées, le niveau du défi s'annonce élevé, et c'est d'autant plus motivant!
Le sujet se prête à de belles expérimentations et implique l'utilisation de nombreuses techniques de Qt.
Nous allons aussi tenter notre chance, ne serait-ce que pour apprendre...

Nous participons à deux. Luthin se joint à moi pour le design (il m'avait déjà bien aidé pour le défi Buddhabrot).

Notre idée: un client léger, une interface simple et épurée, réalisée avec Qt Quick. C'est le côté serveur qui se chargera de fournir les images, y compris le rendu 3D. Pour le reste, on décidera au fur et à mesure... En attendant... au travail!

Ah, oui... le nom de l'application! Ce sera "Dr. Cute" et "Mr. Hyde", pour le client et le serveur respectivement (clin d'oeil à R.L. Stevenson, et surtout au grand Serge!).


0x4e84 & Luthin

[johnlamericain]

Bienvenue dans la compétition et bon courage à tous les deux !

[gbdivers]

Bon courage !

Un choix intéressant de générer les images côté serveur. Comment pensez vous gérer les animations fluides en cas de latence réseaux ? Votre application pourra tourner hors ligne ?

[dourouc05]

Notre idée: un client léger, une interface simple et épurée, réalisée avec Qt Quick. C'est le côté serveur qui se chargera de fournir les images, y compris le rendu 3D. Pour le reste, on décidera au fur et à mesure... En attendant... au travail!

Ça me semble une belle idée de départ. Maintenant, côté serveur, il ne faut pas oublier que l'on peut avoir énormément de donnée à gérer (envoyer un cliché RX en JPG, ça ne sera pas forcément le meilleur si on doit un peu zoomer, par exemple), il faut que le serveur tienne le coup, le réseau aussi... Mais les périphériques auxquels peut être destinée l'application ne sont pas forcément très puissants (un smartphone ne pourra pas faire du ray tracing...), je suppose que c'est dans cette optique que tout sera généré côté serveur.

Bon courage !

[0x4e84]

Si le temps de latence du réseau est un problème potentiel, le temps de latence du forum Qt-DVP est en tout cas extrêmement court!

Bienvenue dans la compétition et bon courage à tous les deux !

Merci!

Un choix intéressant de générer les images côté serveur. Comment pensez vous gérer les animations fluides en cas de latence réseaux ? Votre application pourra tourner hors ligne ?

La faisabilité du concept reste encore à démontrer, bien-sûr, et il y aura un gros travail d'optimisation à effectuer (d'autant plus un défi que je pars avec absolument aucune expérience au niveau réseau). Un cache intelligent et l'envoi d'images par "tiles" seront certainement nécessaires.
L'idée est effectivement de nécessiter une connexion permanente au réseau (à moins que celà soit en contradiction avec les exigences du défi), mais en cas d'interruption, les données en cache seront toujours accessibles.

Ça me semble une belle idée de départ. Maintenant, côté serveur, il ne faut pas oublier que l'on peut avoir énormément de donnée à gérer (envoyer un cliché RX en JPG, ça ne sera pas forcément le meilleur si on doit un peu zoomer, par exemple), il faut que le serveur tienne le coup, le réseau aussi...

Merci dourouc05 pour les encouragements.
Oui, je suis bien conscient de la charge au niveau du réseau, et il va me falloir trouver des moyens d'optimiser le tout...
D'un autre côté, je pars dans l'optique d'une application pour l'hôpital "du futur", et j'imagine que les débits que supporteront les réseaux vont continuer à augmenter de manière drastique dans le futur...
D'où la décision de focaliser sur l'hypothèse d'un terminal mobile minimaliste en termes de puissance de calcul (tablette, smartphone...). Cela permettrait aussi de limiter le coût de déploiement...

Mais les périphériques auxquels peut être destinée l'application ne sont pas forcément très puissants (un smartphone ne pourra pas faire du ray tracing...), je suppose que c'est dans cette optique que tout sera généré côté serveur.

Yep, exactement, je suis parti dans cette idée.
Après la théorie, on va essayer de passer à la pratique, maintenant!...


A+!

0x4e84

[Amnell]

Un choix intéressant de générer les images côté serveur. Comment pensez vous gérer les animations fluides en cas de latence réseaux ? Votre application pourra tourner hors ligne ?

D'un autre côté, dans le principe, sauf à être branché à des dispositifs externes, je vois mal comment une app' cliente pourrait générer elle-même les informations dont elle a besoin.

[0x4e84]

Juste pour le fun, un premier rendu "fil de fer" très simpliste (vue "de haut", tous les triangles représentés, sans tenir compte des faces cachées...) du système veineux...

0x4e84

[dourouc05]

Heureusement que tu précises ce que c'est, sinon je n'aurais jamais trouvé !

[0x4e84]

Mon coéquipier et moi-même ne sommes finalement pas assez pas très avancés dans le projet pour espérer mais essaierons quand-même de soumettre un projet décent d'ici demain.

Nous retirons donc notre participation (sur la pointe des pieds pour ne pas déranger les autres candidats encore au travail, shhhhtt...).

0x4e84 + luthin

Edit: Merci yan, gbdivers et Amnell pour vos message de soutien... Je vais essayer de délivrer qq chose d'ici demain quand-même.

[0x4e84]

Au vu de la nouvelle qui vient de tomber (date limite de rendu de projet reportée au 14 Septembre), une seule chose à dire:

On s'y remet de plus belle!
Merci le jury!

[gbdivers]

Tu en es où ? Reste plus qu'une heure. Si tu veux, tu peux nous rejoindre sur le chat (avec Amnell et LittleWhite) pour du soutiens de dernière ligne droite.

[gbdivers]

Félicitation pour avoir fini le projet

Un petit problème, ça compile pas il manque au moins 1 fichier (sessionsmanager.h appelé dans le main.cpp)

[0x4e84]

Hé hé, je ne t'avais même pas vu jusqu'à maintenant...

Non, tout va bien, j'ai utilisé la dernière heure pour documenter un peu l'évolution du projet...

Dr. Cute et Mr. Hyde ont maintenant pris leur envol, et sont dans les mains du jury. J'attends vos retours avec impatience.

Je n'ai pas implémenté tout ce que j'aurais souhaité implémenter, mais étant donné l'ampleur du défi, j'estime avoir fait de mon mieux.

De plus, pas de bugs de dernière minutes, donc je suis d'autant plus serein... ;-)

Sur ce, j'ai du sommeil à rattraper, maintenant...



0x4e84

PS: Une dernière série de captures, juste pour le fun, maintenant que les dés sont jetés...

[gbdivers]

Ok, il faut commenter les lignes suivantes :

dans MrHyde/serveur.h

Code :

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

#include "config.h"

dans MrHyde/main.cpp

Code :

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

#include "sessionmanager.h"

Merci John pour le hack

[0x4e84]

Félicitation pour avoir fini le projet

Un petit problème, ça compile pas il manque au moins 1 fichier (sessionsmanager.h appelé dans le main.cpp)

J'ai fait le ménage dans les fichiers non utilisés, mais j'ai oublié les #include...
Typique d'une fin de projet, malheureusement...

J'ai renvoyé les fichiers main.cpp et server.h de Mr. Hyde à l'adresse de la rubrique.


Désolé pour le contre-temps, et j'espère que ce sera tout maintenant...


0x4e84


Edit: oui, merci John!...

[Amnell]

Salut,

Je suis en train de regarder ta participation et je me retrouve coincé devant un petit soucis : le choix du docteur. J'ai lancé l'application MrHyde avec le dossier data contenant la db sqlite à côté puis le client, j'ai configuré le port correctement et mis un CONFIG += console côté client afin de voir un peu ce qu'il se passe. Lorsque je vais dans le menu de connexion, "Login", un cadre s'affiche au centre de l'écran. Selon les logs du client, un paquet a été envoyé et la liste des médecins a été reçue. Seul soucis, la liste est restée vide dans le client. Ais-je mal procédé ? Je voulais voir ce que tu avais fait de beau côté 3D.

Bonne soirée,
Amnell.

[yan]

IL va chercher le .sql dans ../data donc bien faire attention d'où tu lande MrHyde.

Es ce normale que l'on ne voit qu'un scan?

[johnlamericain]

IL va chercher le .sql dans ../data donc bien faire attention d'où tu lande MrHyde.

Es ce normale que l'on ne voit qu'un scan?

Je cite :

L'envoi de données binaires (images) m'a donné du fil à retordre, mais j'ai finalement réussi à implémenter in-extremis l'envoi d'une image (issue du fichier de resource plutôt que de la base de donneés, malheureusement...). A ce stade-là, c'est donc plus un proof-of-concept qu'une implémentation correcte...

[0x4e84]

Salut,

Je suis en train de regarder ta participation et je me retrouve coincé devant un petit soucis : le choix du docteur. J'ai lancé l'application MrHyde avec le dossier data contenant la db sqlite à côté puis le client, j'ai configuré le port correctement et mis un CONFIG += console côté client afin de voir un peu ce qu'il se passe. Lorsque je vais dans le menu de connexion, "Login", un cadre s'affiche au centre de l'écran. Selon les logs du client, un paquet a été envoyé et la liste des médecins a été reçue. Seul soucis, la liste est restée vide dans le client. Ais-je mal procédé ?

Salut Amnell,

Je vois très bien quel est ton problème, et celà m'est même arrivé en dernière minute, après que j'ai nettoyé mes répertoires et tenté de lancer l'application depuis une copie de mon répertoire d'origine...

IL va chercher le .sql dans ../data donc bien faire attention d'où tu lance MrHyde.

Yan a apparemment aussi rencontré ce problème et a trouvé la solution ;-)
Il faut en effet copier le fichier sqlite dans le répertoire "data" se situant au même niveau hierarchique et en parallèle du répertoire où se trouve l'exécutable... (cf capture, ce sera plus clair!)
Une alternative, plus simple encore, est d'effacer le (ou les) fichiers sqlite et de lancer une première fois MrHyde avec le paramètre "-prepare". Il va créer le fichier sqlite contenant les exemples. Tu peux ensuite le lancer sans paramètre, pour le fonctionnement normal.

Celà aurait pû être plus intuitif, je te l'accorde...

Est-ce normale que l'on ne voie qu'un scan?

Ici, c'est au tour de John d'avoir trouvé la réponse dans le fichier README.txt...

Je cite :

L'envoi de données binaires (images) m'a donné du fil à retordre, mais j'ai finalement réussi à implémenter in-extremis l'envoi d'une image (issue du fichier de resource plutôt que de la base de donneés, malheureusement...). A ce stade-là, c'est donc plus un proof-of-concept qu'une implémentation correcte...

Je voulais voir ce que tu avais fait de beau côté 3D.

Je ne l'ai pas lié au projet, par manque de temps... J'avais résussi à implémenter l'affichage 3D à l'écran, avec redimensionnement et rotation dans l'espace à la souris. Il ne me restait qu'effectuer le rendu en mémoire au lieu de l'écran (j'avais déjà trouvé des infos pour faire ça) et à gérer les requètes du client (envoi de l'angle selon x, y, z et zoom) puis envoyer l'image, comme j'ai envoyé l'image du scan...

Peut-être avec quelques jours de plus? Mais j'ai déjà obtenu 2 semaines, fautes de quoi je n'aurais rien pû rendre du tout, je ne vais donc pas me plaindre... :-)

[Amnell]

Yan a apparemment aussi rencontré ce problème et a trouvé la solution ;-)

Effectivement, j'avais un fichier .sqlite automatiquement créé qui faisait exactement 0 octet, d'où la difficulté d'une réception du modèle des médecins.

Je ne l'ai pas lié au projet, par manque de temps... J'avais résussi à implémenter l'affichage 3D à l'écran, avec redimensionnement et rotation dans l'espace à la souris. Il ne me restait qu'effectuer le rendu en mémoire au lieu de l'écran (j'avais déjà trouvé des infos pour faire ça) et à gérer les requètes du client (envoi de l'angle selon x, y, z et zoom) puis envoyer l'image, comme j'ai envoyé l'image du scan...

Peut-être avec quelques jours de plus? Mais j'ai déjà obtenu 2 semaines, fautes de quoi je n'aurais rien pû rendre du tout, je ne vais donc pas me plaindre... :-)

Dans ce cas, je ferai sans doute partie de ceux qui attendront la partie 3D, même si elle est postée hors concours.