[Les geekologues] Présentation de notre participation

Version imprimable

04/06/2011, 15h53
Invité

[Les geekologues] Présentation de notre participation

Salut !

Pour cette deuxième édition du défi Qt, j'ai formé l'équipe des geekologues, elle est composé des membres suivant :
- std_abdel, lycéen, développeur autodidacte ;
- LittleWhite, étudiant, développeur ;
- Nass, étudiant, graphiste.

L'application mobile pour hopitaux futuristes que nous espérons concevoir, présentera une interface qui sera à la fois accentué sur le design et sur l'ergonomie. C'est Nass qui se chargera de dessiner l'interface, et moi qui l'intégrerai via QtQuick.

Le programme présentera une architecture décentralisé : c'est-à-dire à la fois serveur et client, et intégrera pour stocker les informations nécéssaires, un gestionnaire de base de donnée rapide et léger : SQLite. Je m'en chargerai également.

LittleWhite quand à lui se chargera d'intégrer un système de modules, où chaque modules devra remplir une fonction. Certains modules seront bien évidemment intégrer par défaut. L'affichage d'éléctrocardiogramme et la vue 3D d'un organne sont deux exemples de modules que nous comptons implémenter. Nous comptons dans ce cas faire également appel aux bibliothèques OpenGL et OpenCV.

Rien n'est encore sûr, les rôles peuvent encore changer et les fonctionnalités aussi. Nous espérons (et il y a interet) que vous proposerez mieux. :zen:
05/06/2011, 11h06
dourouc05

Citation:

Envoyé par std_abdel

L'application mobile pour hopitaux futuristes que nous espérons concevoir, présentera une interface qui sera à la fois accentué sur le design et sur l'ergonomie. C'est Nass qui se chargera de dessiner l'interface, et moi qui l'intégrerai via QtQuick.

Ce n'est pas vraiment comme ça que c'est prévu : le designer fait tout avec Qt Quick, il peut même exporter ses interfaces en fichiers QML. Lui fait les fichiers QML, tu les adaptes un peu pour coller ta logique derrière, faire autre chose est contraire aux principes de Qt Quick.

Sinon, je veux bien vous proposer quelque chose à faire, mais vous avez déjà la liste et rien à commenter dans le coin :aie: !

Ah, si : j'aime bien votre nom d'équipe !
05/06/2011, 11h48
Invité

Citation:

Envoyé par dourouc05

Ce n'est pas vraiment comme ça que c'est prévu : le designer fait tout avec Qt Quick, il peut même exporter ses interfaces en fichiers QML. Lui fait les fichiers QML, tu les adaptes un peu pour coller ta logique derrière, faire autre chose est contraire aux principes de Qt Quick.

J'imagine... Le soucis c'est que Nass devrait alors apprendre à se servir de QtQuick, cela ne devrait pas être trop difficile étant donné qu'il sait déjà se servir du html/css... Je vois ça avec lui, mais au pire il peut toujours me fournir un modèle, et à moi de faire le sale boulot... même si c'est contraire aux traditions. :aie:

N'hésitez surtout pas si vous avez une quelconque remarque, suggestion, ou autre ! :ccool:
05/06/2011, 11h51
dourouc05

Il peut passer par Photoshop, qu'il connaît très probablement. N'oublie pas non plus l'éditeur visuel dans Qt Creator, on ne doit pas pondre une seule ligne de code pour faire une interface de cette manière-là.

Et puis, le but est aussi d'apprendre quelque chose, sinon ce n'est pas très utile de participer au défi ;) !
06/06/2011, 18h00
LittleWhite

Bonjour,

Je suis de l'avis de dourouc05 pour la partie QtQuick. Notre designer n'a pas vraiment besoin de voir le code, il peut tout faire dans le designer qui est proposer dans QtCreator.

(On remarquera que notre équipe est toujours dans la réflexion :D)

Après, dans la théorie, je voyais juste le programme qui proposé une "Vue" des choses à afficher (que ce soit les infos 3D, les ECG, les scans ou autre infos sur le patient). Comme cela, le QtQuick (et l'interface) pouvait utiliser (ou non) ces infos et que cette dernière pouvait (devait) être dynamique à souhait. Ma dernière réflexion sur la matière c'était porté sur le moyen de mettre les données C++ disponible pour QtQuick (et comment faire en sorte que la partie QtQuick puisse porter des exigences sur les données necessaires et dire "ah non, je peux pas me charger vous n'avez pas ce que je veux".)
Enfin bref, y a encore du travail à faire dans le design de notre application. Nous en sommes qu'au tout début :)

Sinon, tout de même, je tiens à dire que pour la partie 3D, j'ai un peu commencé et notamment, j'utilise le récent tuto de gbdivers :ccool:
(Notez que je développe cette partie comme un module et que pour le moment ce n'est pas intégré dans le projet. Logiquement, une fois "prêt" nous aurons plus qu'à le copier dans le projet principal, et hop, c'est utilisable). (J'aime bien rêver d'une programmation parfaite :lun:)
11/06/2011, 18h23
LittleWhite

1 pièce(s) jointe(s)

Donc, je travaillais tranquillement sur la partie 3D (notamment lecture des fichiers .trian) et affichage (voir la pièce jointe).
Il me reste quelques problèmes et fonctionnalités à régler, mais bon, y a une base visible.
Je pose une question à cet endroit sur les données 3D utilisables et disponibles -> http://www.developpez.net/forums/d10...l/#post6051489
11/06/2011, 21h30
dourouc05

:ccool:, déjà un bon début !
15/06/2011, 18h06
LittleWhite

1 pièce(s) jointe(s)

Voilà une nouvelle capture avec une mise en place très minimale des lumières :) (ça fait un peu gore au final comme application :aie:)

Donc je continue, plus ou moins lentement à amélioré le code de mon module 3D avant de passer à autre chose.
15/06/2011, 18h10
dourouc05

Citation:

Envoyé par LittleWhite

(ça fait un peu gore au final comme application :aie:)

Pas encore, le sang n'est pas partout... mais ça ne saurait tarder, vu que tu prévois probablement une petite application où il faut circuler dans les vaisseaux pour bousiller tous les méchants virus, histoire de vérifier que le chirurgien est bien réveillé avant l'opération !
03/09/2011, 23h24
Invité

Les principales branches du projets : réseau, fonctionnalités, base de donnée, documentation, etc... sont quasiment terminés. Il ne nous reste plus désormais qu'à unifier les codes (qui partent un peu dans tout les sens) puis peaufiner l'interface. Ces derniers jours vont êtres tendus et décisif !

Compte rendu, après apocalypse.

Bon, la documentation n'est pas fini. J'avais oublié de citer les systèmes utilisées et surement un autre truc ... vu que je n'ai pas relu les requis.
Il reste les fichier de SVN dans le fichier que nous avons envoyé ...

Après, à cause d'un ajout de ligne de dernière minutes, pour une compilation Windows, le bug est arrivé (Bon, je m'en doutais trop fortement).
La copie de fichier avec QMake est assez pénible. Elle n'est pas multiplateforme pour deux sous.
Le code est le suivant:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 windows { QMAKE_POST_LINK += "$(COPY) ..\\lib\\* $(DESTDIR) &" QMAKE_POST_LINK += "$(COPY_DIR) ..\\ModulesSystem\\Module\\plugins .\\debug\\plugins &" QMAKE_POST_LINK += "$(COPY_DIR) ..\\ModulesSystem\\Module\\data .\\debug\\data &" QMAKE_POST_LINK += "$(COPY_DIR) ..\\ModulesSystem\\Module\\plugins .\\release\\plugins &" QMAKE_POST_LINK += "$(COPY_DIR) ..\\data .\\release\\data" } !windows { QMAKE_POST_LINK += "$(COPY) ../lib/* . &" QMAKE_POST_LINK += "$(COPY_DIR) ../ModulesSystem/Module/plugins ./ &" QMAKE_POST_LINK += "$(COPY_DIR) ../../medcenter/data ./" }
Pour copier le contenu d'un dossier, et de dossier.
C'est plus que moche. J'aurais voulu utiliser DESTDIR, mais pas moyen de modifier la variable dans le QMAKE_POST_LINK (logique dans un sens).
Du coup, on se retrouve même avec le problème des "\" "/" ... car copy sous Windows, ne gérera pas les dossiers avec les "/" et GNU/Linux non plus lors des "\\" (du moins, sur mon test sur un LinuxJS :aie: (utile ce truc :roll:)).

L'application ne mettra pas en œuvre le module pour les scan, ni pour les radio. Car nous n'avons pas de sauvegarde de données de patient (certain trouvait déjà inutile de charger des données à partir de la DB), ni de radio.
Pour le mettre en oeuvre sans touché le code, il faudra éditer un patient et ajouter les données à la main. Comme les ListView en QML ne sont pas vraiment efficacement utilisées, ce ne sera pas vraiment possible. (Il faudra donner la catégorie "ScanData et RadioData" pour que le module s'active).

Les deux autres modules, provoqueront des crash. Du moins, j'ai fait un fix (surement très moche) qui n'a pas été testé (j'ose pas lancé l'application pour savoir si ça marche ou pas). Je n'avais pas eu le temps de tester pour respecter la deadline.

Heureusement, (si si, j'ai une bonne nouvelle), les modules sont vraiment modules. On peut les compiler dans un mode standalone (avec les .pro correspondant) et charger des fichiers (gbdivers ne comprenez pas pourquoi j'avais ça :aie:). Ce sont de vrai module ;). Pour peu que je rajouter un bouton "reload module", je pouvais faire un chargement dynamique.

Ah, et j'oubliais, un module s'active selon le dossier (l'operation) que l'on choisit. Mais cela n'a pas été testé non plus O_o.
D'ailleurs l'ajout de fichier, à part dans le point de vue théorique, n'a pas été testé.

Un bug marrant (oui, j'en ai des comme ça aussi), c'est que si on modifie le nom d'un patient, les autres applications connectés vont croire que c'est un nouveau dossier. Ceci est expliqué dans la doc :aie:.

Ah oui, j'oubliais, pour que l'application tourne en réseau, il faut plusieurs PC (P2P oblige). De plus il faut rajouter les adresses IP des autres PCs, soit dans un fichier (qui doit se trouver dans le dossier data et s'appeler: machines.txt). On peut aussi utiliser l'interface en mode admin pour rajouter les adresses :)

Bon, y a peut être des trucs bien ... je doute encore un peu. Les graphismes fait pas Nass sont très niquel je trouve :)
Il y a une gestion des droits (basique certes).
Il y a les modules (moi je trouvais ça bien :aie:)
Il y a un module 3D (juste parce que je suis le seul à l'avoir depuis 3 mois :aie:)
Il y a un chat :lun: développé en trois jours à peine (donc on remarquera que mon réseau est assez bien en place)
Il y a possibilité de SSL (jamais testé :cry:)

Les trucs que j'aurais aimé faire:

Un double clic dans le module 3D pour afficher plus qu'un organe. Pour les très attentifs, cela n'a pas été fait, car j'ai jamais réussi à utilise glUnProject et la collision rayon / triangle, comme je l'avais signalé sur une discussion dans le forum OpenGL.
La possibilité de dessiner sur les radio (genre, un mode pinceau) et que l'on sauvegarde ce dessin dans un fichier image. Comme ça on aurait pu annoter les radio / scan. Ça aurait été vraiment bien. Malheureusement, j'ai du m'inquiéter du réseau à ce moment.
Il faudrait plus d'information sur nos fiches. Mais les idées sont là.
Les ECG, j'aurais voulu faire un truc, qui indique la valeur, lorsque l'on passe le curseur sur la courbe. Mais bon, je ne sais pas trop comment faire, et puis je n'avais qu'une courbe à afficher :aie:
Non, j'avais plein d'idées ...

Voilà pour le moment. Je dois aussi dire que j'ai jamais compris comment utiliser les fichiers radio fournit. Ils ne semblent pas utiles :aie: