Discussion :

[feda12]

Bonjour,

je compte me présenter au défi Qt n°2.

Je programme en C++ depuis 2 ans et avec Qt depuis 1 an, je travaillerai parallèlement sur un projet personnel de gestion de bibliothèque films, séries TV, musiques etc ...
Je n'ai jamais codé avec QtQuick, ce sera donc l'occasion pour moi d'apprendre.

Je souhaiterais rendre un logiciel qui soit fluide, je ne veux pas d'un bouzin pleins de fonctionnalités qui n'avance pas. L'interface sera probablement entièrement réalisé avec Quick, bien que celui-ci comporte quelques bugs(d'après mon co-équipier).

Je pensais utiliser une distinction entre les différents corps de métier et le patient, cela se passerait via une architecture client/serveur dans lequel 2 contrôleurs distincts communiqueraient.
Ces deux mêmes contrôleurs recevraient les requêtes en provenance des différents modules que l'on pourrait installer. Ainsi cela laisse la liberté à tout développeur tiers d'importer ses propres fonctionnalités, en lui laissant le soin de créer l'interface de son module(en restant dans le thème général de l'application).

Voilà, si vous souhaitez d'avantage de précisions, n'hésitez pas.

[Invité]

J'espère que vous nous ferez rêver ! Bon défi à vous deux !

[dourouc05]

J'espère qu'ils commenceront à faire rêver les autres participants, histoire que nous n'ayons que des participations de très grande qualité !

Sinon, quels bogues dans Qt Quick ? C'est une technologie jeune, c'est vrai, mais pas forcément boguée à ce point (de toute façon, vous n'êtes pas obligés d'utiliser Qt Quick ).

[feda12]

Merci std_abdel, à vous aussi !

Elle n'est pas si boguée que ça je l'admets, mais darkrojo m'a envoyé un message via teambox précisant que cette technologie était très bonne, mais qu'il subsistait quelques bugs, je n'ai pas encore commencé à apréhender Quick, je ne peux pas en dire plus

En tout cas, je sens que la barre va être très haute pour ce défi

[dourouc05]

En tout cas, je sens que la barre va être très haute pour ce défi

Ça dépend de vous ! Et puis, si jamais on sent que la compétition ne bat pas son plein, il est toujours possible qu'un membre du jury commence un petit projet, ne fut-ce que pour stimuler et donner des idées ! Tout est prévu pour que vous atteignez vos limites... et les dépassiez, surtout !

[feda12]

Oui c'est sur.

Voici une première idée du thème de l'appli, cela a été fait par darkrojo

[dourouc05]

, c'est déjà dans la bonne voie de ce que l'on demande ! (Maintenant, il faut tester ça en vrai, mais ça ne sera pas intéressant tant qu'il n'y a rien derrière).

[feda12]

Évidemment l'interface n'est là que pour l'utilisateur

Mais je postais cela juste afin de voir si l'on se dirigeait dans la bonne voie, ce serait bête de mal débuter ^^

[dourouc05]

Il n'y a pas qu'une manière de débuter, il y en a autant que d'êtres humains sur la terre. Ça semble être comme les nouvelles interfaces de Win8 et autres, donc c'est complètement dans ce qu'on demande, mais il est possible de partir dans d'autres directions, tant que ça donne toujours une impression d'un truc qui peut aller vite (les interfaces plus modernes ne sont généralement plus des listes de menus avec des suites interminables d'options).

[feda12]

Oui, d'ailleurs je compte mélanger l'esprit Win8 et iOS. Les interfaces avec pleins de boutons et de menus sans aucune logique sont rebutantes. C'est pour cela que l'interface médical doit être simple et intuitive, il ne faudrait pas faire une formation logiciel à chaque patient qui arrive.

Sinon, je me retrouve seul, je viens d'apprendre que mon co-équipier me lâche. Je vais donc essayer de me concentrer sur le serveur dans un premier temps, utiliser un protocole "nomdumodule:commande" est-il une bonne idée ? En sachant que cela nécessiterai d'analyser la commande, ou serait-il plus judicieux d'utiliser le mécanisme de signaux/slots via le réseau(Qxt) ?

[dourouc05]

C'est pour cela que l'interface médical doit être simple et intuitive, il ne faudrait pas faire une formation logiciel à chaque patient qui arrive.

Même qu'il y a des points pour ça (côté ergonomie, par exemple), certains pourraient aussi voir que c'est dans le fonctionnement de base que de pouvoir accéder aux fonctions de base sans devoir se plonger dans la doc.

Je vais donc essayer de me concentrer sur le serveur dans un premier temps, utiliser un protocole "nomdumodule:commande" est-il une bonne idée ? En sachant que cela nécessiterai d'analyser la commande, ou serait-il plus judicieux d'utiliser le mécanisme de signaux/slots via le réseau(Qxt) ?

C'est une idée parmi tant d'autres. C'est assez proche des protocoles comme FTP (COMMANDE opérandes), c'est un style qui a fait ses preuves. Tu peux aussi voir pour transmettre tout sérialisé (XML, YAML, JSON, bencode, par exemple), ce qui te permet de mettre plus d'infos d'une manière déjà standardisée, il te suffira de brancher ce que tu reçois du réseau à un module de décodage, qui te renvoie tout ce dont tu as besoin au bon format. Ou tu peux faire d'une toute autre manière, en fait, c'est toi qui vois !

L'idéal est toujours d'utiliser quelque chose que l'on comprend, savoir comment ça fonctionne derrière le capot aide souvent à résoudre des bogues, mieux vaut écrire un gros bout de code plutôt que d'utiliser une boîte noire, on sait ce qu'il se passe, on maîtrise déjà le code.

[feda12]

À vrai dire je demandais cela car ce serait ma première application réseau, hors pour que l'interface soit fluide, il faut que l'arrière soit rapide, donc c'est primordial, merci pour les formats de sérialisation de données, mais je me demandais si l'analyse d'une commande n'était telle pas coûteuse ? Faut-il utiliser des RegExp ?

[dourouc05]

À vrai dire je demandais cela car ce serait ma première application réseau, hors pour que l'interface soit fluide, il faut que l'arrière soit rapide, donc c'est primordial, merci pour les formats de sérialisation de données, mais je me demandais si l'analyse d'une commande n'était telle pas coûteuse ? Faut-il utiliser des RegExp ?

Fluide ne veut pas dire remettre des fibres un peu partout, il est normal qu'il y ait des latences à cause du réseau. Le parsing ne devrait pas te prendre un temps aussi énorme, s'il est un tant soit peu optimisé (non, pas besoin de descendre à l'assembleur).

Pour le parsing, tu peux voir du côté de QLALR (http://qt-quarterly.developpez.com/qq-33/qlalr/), c'est la méthode à laquelle je penserais en premier pour ce genre de choses (même si c'est probablement overkill, vu que c'est utilisé pour Qt Script, soit pour parser du JavaScript). Surtout que je n'ai jamais réussi à aimer les regex (ou l'inverse).

[Amnell]

Lors de l'envoi d'un paquet, vous allez par exemple utiliser le code suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
QByteArray b_array;
QDataStream out(&b_array, QIODevice::WriteOnly);
 
QString messageType = "Ping";
int messageContent = 1;
 
out << (quint16)0;
out << messageType ;
out << messageContent;
out.device()->seek(0);
out << (quint16)(b_array.size() - sizeof(quint16));
 
socket->write(b_array);

Dans ce cas, lors de la récupération du paquet, on poura avoir cela :

Code :

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

1
2
3
4
5
6
QDataStream in(socket);
...
 
QString messageType;
int messageContent;
in >> messageType >> messageContent;

À ce moment-là, messageType contiendra "Ping" et messageContent, "1", d'où une possibilité d'identifier les paquets sans les regexs. Après, à vous de voir comment vous envoyez les paquets, de quoi vous les constituez et comment vous les gérez.

Bon courage pour votre participation !

[feda12]

Merci beaucoup pour vos réponses, je vais travailler là-dessus, bonne chance à vous aussi

[johnlamericain]

Sinon, je me retrouve seul, je viens d'apprendre que mon co-équipier me lâche.

Une raison particulière ? Ampleur de la tâche ? Temps ?

[feda12]

Manque de motivation, il semblerait que ce ne soit pas la première fois qu'il abandonne un projet en cours de route.

[gbdivers]

il ne faudrait pas faire une formation logiciel à chaque patient qui arrive

Le sujet du défi concerne plus le personnel soignant que les patients

Je vais donc essayer de me concentrer sur le serveur dans un premier temps, utiliser un protocole "nomdumodule:commande" est-il une bonne idée ? En sachant que cela nécessiterai d'analyser la commande, ou serait-il plus judicieux d'utiliser le mécanisme de signaux/slots via le réseau(Qxt) ?

Tu peux utiliser un commande codé par un int avec un switch en réception (le plus simple et le plus court à transmettre sur le réseau ; pour la lisibilité, quelques "const int" aident bien) ou un QString avec une série de if (le coût en terme de performance est négligeable)
Tu peux utiliser un parseur (QLALR est vraiment de la très très très grosse artillerie pour faire cela) mais comme ton récepteur connait forcement le "dictionnaire" des commandes, ça me semble peu utile.
Et comme le dit Amnsell, pas besoin non plus de RegExp.

Manque de motivation, il semblerait que ce ne soit pas la première fois qu'il abandonne un projet en cours de route.

J'espère que toi, tu tiendras le coup. N'hésite pas à demander de l'aide ou à rechercher d'autres collaborateurs.

Bon courage

[LittleWhite]

Moi, la première capture de votre projet me fait rêver
(Il faut que j'aille fouetter mon coéquipier pour voir si cela avance (et peut être que dans les objets qu'il lâchera il y aura une capture ))

Ça semble être comme les nouvelles interfaces de Win8 et autres

Ce gars a surement des infos exclusive sur Win8 ... ou alors c'est le fait de ma faible connectivité que je ne suis pas au courant

Bon plus sérieusement (que je ne pourrisse pas un sujet), pour le réseau, qui est une lourde tache (comme souvent), je pense qu'il faille surtout se pencher sur la sécurité.
Pourquoi ?
Car nous sommes dans un hôpital et que je n'aimerai pas voir les infos des patients sur des réseaux grand publics.
Après, pour l'installation du réseau, il y a le classique "Commande Données" (avec un séparateur intelligent entre les deux; c'est d'ailleurs pour cela que l'idée du const int est intéréssante aussi) qui fonctionnera, sera facile à debugguer et puis facilement maitrisable.
Sinon, y a la sérialisation, qui est un mot qui vient des designeur d'application (plus que des implémenteurs) et qui, certes donne un joli truc, bien simple monPaquet >> monClasseDeDonnée mais qui reste un peu plus difficile à debugguer (notamment lors de l'analyse des paquets et autre). Et puis c'est légèrement un peu plus dur à mettre en place, mais c'est plus beau

[feda12]

Il y a eu une présentation du nouveau Win8 ....

La sécurité ? Je pensais gérer tout cela via une connexion SSL qui me semble assez sécurisé pour ne pas s'en occuper, de plus il me semble que la sécurité ne soit pas prise en compte dans le barême

Concernant le transfert de données, je vais faire des tests et vous tiendrait au courant