Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2511 connectés 

 


 Mot :   Pseudo :  
 
 Page :   1  2
Page Suivante
Auteur Sujet :

Console VS IHM

n°760257
littlesam
Serial cliqueuse ^^
Posté le 11-06-2004 à 11:50:40  profilanswer
 

Reprise du message précédent :
chui pardonnée ?

mood
Publicité
Posté le 11-06-2004 à 11:50:40  profilanswer
 

n°760258
uriel
blood pt.2
Posté le 11-06-2004 à 11:50:47  profilanswer
 

kadreg a écrit :


(configuré en mode emacs [:ddr555] )


 
moi aussi pour le Fortran :O


---------------
IVG en france
n°760261
uriel
blood pt.2
Posté le 11-06-2004 à 11:51:39  profilanswer
 

littlesam a écrit :

chui pardonnée ?


 
[:ciler] j'espere que tu sais ce que tu viens de faire...


---------------
IVG en france
n°760267
nico168
Posté le 11-06-2004 à 11:55:05  profilanswer
 

Les soft en console, c'est bien, ca me permet de faire la maintenance de mes ordis chez moi alors que je suis au boulot.
D'ailleur ca doit etre une des principales raison pour lesquels des collegues ont mis du linux chez eux.
le mieux, c'est de programmer les fonctionnalités demandés dans une appli console, pis  quand ca tourne, faire une GUI pour ceux qui le souhaites.

n°760283
the real m​oins moins
Posté le 11-06-2004 à 12:09:20  profilanswer
 

uriel a écrit :

[:ciler] j'espere que tu sais ce que tu viens de faire...

ben oui, elle vient de se donner le moyen d'avoir des réponses bcp facilement à ses questions


---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
n°760301
HelloWorld
Salut tout le monde!
Posté le 11-06-2004 à 12:24:08  profilanswer
 

Je suppose que vous développez vos applis console depuis une console avec VI ou EDIT ?
Et là vous postez vos réponses depuis Lynx ?
La réponse est simple, c'est comme pour tout : ça dépend.
Un exemple ne prouve rien.
La console a son intérrêt, le GUI aussi.
Moi j'ai tendance à d'abord développer mon noyau en console, puis à le rendre utilisable avec une GUI.


---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite
n°760304
uriel
blood pt.2
Posté le 11-06-2004 à 12:25:48  profilanswer
 

[:kiki] tout ce qu'on dit depuis tout a l'heure, c'est que ca depend des besoins!
on va pas faire une GUI pour le plaisir d'avoir a cliquer sur un bouton pour lancer un programme.


Message édité par uriel le 11-06-2004 à 12:25:58

---------------
IVG en france
n°760314
Moktar1er
No one replies...
Posté le 11-06-2004 à 12:29:42  profilanswer
 

uriel a écrit :

[:kiki] tout ce qu'on dit depuis tout a l'heure, c'est que ca depend des besoins!
on va pas faire une GUI pour le plaisir d'avoir a cliquer sur un bouton pour lancer un programme.


 
et ça dépend aussi du end-user hélas...
j'ai, par exemple, développé une blbliothèque d'outils de traitement d'image, qui marchent bien en mode console.
et pourtant, je me suis cogné en plus un interfaçage car ça va être utilisé par des néophytes en info.

n°760318
the real m​oins moins
Posté le 11-06-2004 à 12:30:54  profilanswer
 

moktar1er a écrit :

et ça dépend aussi du end-user hélas...
j'ai, par exemple, développé une blbliothèque d'outils de traitement d'image, qui marchent bien en mode console.
et pourtant, je me suis cogné en plus un interfaçage car ça va être utilisé par des néophytes en info.

oui ben ça entre aussi dans la catégorie besoins ça [:dawa]


Message édité par the real moins moins le 11-06-2004 à 12:32:02

---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
n°760320
uriel
blood pt.2
Posté le 11-06-2004 à 12:31:20  profilanswer
 

moktar1er a écrit :

et ça dépend aussi du end-user hélas...


 
ca vient dans les besoins  :jap:


---------------
IVG en france
mood
Publicité
Posté le 11-06-2004 à 12:31:20  profilanswer
 

n°760359
Moktar1er
No one replies...
Posté le 11-06-2004 à 12:50:49  profilanswer
 

-- et uriel> ouais c'est vrai [:dawa]

n°760498
littlesam
Serial cliqueuse ^^
Posté le 11-06-2004 à 14:37:29  profilanswer
 

KDevelop poubelle, console et g++ tout marche bien. Je vais faire un petit saut dans le temps, la préhistoire ça a du bon finalement ^^'

n°760502
uriel
blood pt.2
Posté le 11-06-2004 à 14:39:39  profilanswer
 

[:ddr555]
 
sinon kadreg devait tester Anjuta, je sais pas ce que ca a donne?


Message édité par uriel le 11-06-2004 à 14:40:09

---------------
IVG en france
n°760531
kadreg
profil: Utilisateur
Posté le 11-06-2004 à 14:55:11  profilanswer
 

uriel a écrit :

[:ddr555]
sinon kadreg devait tester Anjuta, je sais pas ce que ca a donne?


 
Il a pas encore fini de télécharger les dépendances [:spamafote]


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
n°760532
kadreg
profil: Utilisateur
Posté le 11-06-2004 à 14:55:34  profilanswer
 

littlesam a écrit :

KDevelop poubelle, console et g++ tout marche bien. Je vais faire un petit saut dans le temps, la préhistoire ça a du bon finalement ^^'


 
Si tu voyais avec quoi je compile [:spamafote]


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
n°765234
xterminhat​e
Si vis pacem, para bellum.
Posté le 16-06-2004 à 08:12:44  profilanswer
 

Petite expérience sous anjuta et kdevelop : je préfère kdevelop parce qu'il semble planter moins souvent sur une config donnée (la mienne) au moment de debuger. C'etait il y a longtemps...
 
De manière générale, je développe un nouveau programme avec d'abord une IHM limitée à la console, puis j'ajoute le support du réseau (telnet, http ou autres protocoles) et une IHM de type web (pages dynamiques générées par le programme). GUI MFC m'ecoeure...


---------------
Cordialement, Xterm-in'Hate...
n°765324
HelloWorld
Salut tout le monde!
Posté le 16-06-2004 à 09:57:49  profilanswer
 

xterminhate a écrit :


De manière générale, je développe un nouveau programme avec d'abord une IHM limitée à la console, puis j'ajoute le support du réseau (telnet, http ou autres protocoles) et une IHM de type web (pages dynamiques générées par le programme). GUI MFC m'ecoeure...


 
Certes. Mais une IHM en HTML, t'es vite limité...


---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite
n°766241
xterminhat​e
Si vis pacem, para bellum.
Posté le 16-06-2004 à 17:33:29  profilanswer
 

Pour ce que je fais ca suffit et l'essentiel pour moi est d'avoir un accès à distance avec le client de mon choix.


---------------
Cordialement, Xterm-in'Hate...
n°766280
mordicator
Posté le 16-06-2004 à 17:54:02  profilanswer
 

On le voit, generaliser est toujours tres dur!
Selon le type de soft, son degre d'interaction avec l'utilisateur, le profil d'utilisateur vise... une IHM se justifie ou non. D'une maniere generale, une IHM est une chose complexe a realiser. Non pas en terme de placer des boutons sur une page, les RAD sont la pour aider de ce cote. Le probleme d'une IHM c'est que si elle n'est pas bien concue, le resultat peut-etre catastrophique.
Meme si ce n'est pas encore tellement rentre dans les moeurs, concepteur d'IHM est un metier a part, pas forcement developpeur de nature.
 
Dans tous les cas, c'est une question de besoins, d'environnement, de cible et de compromis entre tout ca.
Si tu travaille exclusivement sous un os en mode graphique que tu disposes des outils qui vont bien (Win/Visual/C# par ex) et que tes interfaces se resument a 2 boutons/3 options, alors oui, tu auras surement interret a passer par une IHM, mais tu ne peux pas generaliser (genre si tu developpe un service win, ben l'IHM...)
 
Voila, rien de nouveau la dedans, comme toujours ca depends des besoins et des gouts!

n°766299
docmaboul
Posté le 16-06-2004 à 18:16:06  profilanswer
 

moktar1er a écrit :

et ça dépend aussi du end-user hélas...
j'ai, par exemple, développé une blbliothèque d'outils de traitement d'image, qui marchent bien en mode console.
et pourtant, je me suis cogné en plus un interfaçage car ça va être utilisé par des néophytes en info.


 
:jap:
 
Selon le programme, le besoin d'un ihm dépend beaucoup de l'utilisateur final. Sinon, je ne suis pas trop d'accord avec ceux qui ont l'air de dire que c'est la mort de faire une ihm. En résumé, c'est chiant, long et coûteux si on repart systématiquement de zéro, par exemple en n'ayant que les mfc et l'api win32, et donc sans passer par une bibliothèque perso, ou une du type dundas ou xtrem toolkit pro. Après, se faire soi-même ses propres contrôles, je trouve ça plutôt rigolo.


Message édité par docmaboul le 16-06-2004 à 18:17:10
n°766339
HelloWorld
Salut tout le monde!
Posté le 16-06-2004 à 19:04:54  profilanswer
 

DocMaboul a écrit :

:jap:
Sinon, je ne suis pas trop d'accord avec ceux qui ont l'air de dire que c'est la mort de faire une ihm. En résumé, c'est chiant, long et coûteux si on repart systématiquement de zéro, par exemple en n'ayant que les mfc et l'api win32, et donc sans passer par une bibliothèque perso, ou une du type dundas ou xtrem toolkit pro. Après, se faire soi-même ses propres contrôles, je trouve ça plutôt rigolo.


 
Pas d'accord. Faire une IHM de qualité c'est très dur.
Quand tu dois gérer plusieurs vues totalement différentes sur les mêmes données, ça devient très complexe. En particulier la manière de faire le pont entre le code de traitement non graphique (qui pourrait être dans une console = le coeur du système) et l'IHM est cruciale. C'est dur parce qu'un mauvais design se paye assez tard, et se paye très cher (redéveloppement de grosses parties), et tout ajout prend de plus en plus de temps. AMHA ca n'a rien à voir avec le toolkit.


---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite
n°766344
docmaboul
Posté le 16-06-2004 à 19:11:41  profilanswer
 

HelloWorld a écrit :

Pas d'accord. Faire une IHM de qualité c'est très dur.
Quand tu dois gérer plusieurs vues totalement différentes sur les mêmes données, ça devient très complexe. En particulier la manière de faire le pont entre le code de traitement non graphique (qui pourrait être dans une console = le coeur du système) et l'IHM est cruciale. C'est dur parce qu'un mauvais design se paye assez tard, et se paye très cher (redéveloppement de grosses parties), et tout ajout prend de plus en plus de temps. AMHA ca n'a rien à voir avec le toolkit.


 
Justement, tout l'intérêt du toolkit est de gérer l'interfaçage des données avec la présentation graphique et d'encapsuler tous les détails à la con. Par exemple, redévelopper l'alimentation d'un treectrl à chaque fois qu'on a une arborescence à présenter, c'est idiot. Idem pour une grid. Après, rafraîchir des vues sur les mêmes données lorsque celles-ci changent, je ne vois vraiment pas où se trouve la complexité. Encore vous auriez mentionné le multi-thread, pourquoi pas (et bien que ce ne soit pas non plus la mer à boire), mais là...

n°766364
docmaboul
Posté le 16-06-2004 à 19:25:06  profilanswer
 

DocMaboul a écrit :

Justement, tout l'intérêt du toolkit est de gérer l'interfaçage des données avec la présentation graphique et d'encapsuler tous les détails à la con. Par exemple, redévelopper l'alimentation d'un treectrl à chaque fois qu'on a une arborescence à présenter, c'est idiot. Idem pour une grid. Après, rafraîchir des vues sur les mêmes données lorsque celles-ci changent, je ne vois vraiment pas où se trouve la complexité. Encore vous auriez mentionné le multi-thread, pourquoi pas (et bien que ce ne soit pas non plus la mer à boire), mais là...


 
A quoi que si, je comprends comment cela peut devenir complexe. Si vous avez pondu un design pourri où le code des contrôles, des fenêtres, des objets graphiques est bâtard et fait autre chose que gérer de l'affichage graphique et recevoir les inputs, effectivement, ça peut devenir compliqué de gérer un bordel immonde. Idem pour la partie non graphique du code. Mais c'est quelque peu tautologique toute cette histoire.

n°766366
uriel
blood pt.2
Posté le 16-06-2004 à 19:26:08  profilanswer
 

[:meganne] tu t'autoquote??


---------------
IVG en france
n°766369
lorill
Posté le 16-06-2004 à 19:28:17  profilanswer
 

uriel a écrit :

[:meganne] tu t'autoquote??

il complete sa réponse  [:sinclaire]

n°766384
HelloWorld
Salut tout le monde!
Posté le 16-06-2004 à 19:43:23  profilanswer
 

Je ne parle pas de raffraichir les vues.
Je parle de créer une architecture permettant de greffer le plus facilement possible une vue sur n'importe quelle donnée, existante et future.
Pas facile de définir une interface d'accès aux données qui soit toujours satisfaisante par la suite. Des fois un nouveau type de données n'est pas manipulable de la même manière, des fois l'ajout d'une nouvelle option de visualisation nécessite une info non divulguée...
Tes données font évoluer ton IHM et vice-versa, en fonction des désirs du client. Toute la difficulté est d'anticiper ses demandes.
Mais même raffraichir les vues ça peu être très vite balaize : pense au Undo/Redo...


---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite
n°766386
HelloWorld
Salut tout le monde!
Posté le 16-06-2004 à 19:46:50  profilanswer
 

DocMaboul a écrit :

A quoi que si, je comprends comment cela peut devenir complexe. Si vous avez pondu un design pourri où le code des contrôles, des fenêtres, des objets graphiques est bâtard et fait autre chose que gérer de l'affichage graphique et recevoir les inputs, effectivement, ça peut devenir compliqué de gérer un bordel immonde. Idem pour la partie non graphique du code. Mais c'est quelque peu tautologique toute cette histoire.


Ton design peut être très bien fait, tout marche bien.
Et un jour t'as un client qui te dit "moi je veux l'undo/redo".
Si tu as 10 fenêtres à gérer, je te laisse immaginer la somme de travail pour ajouter seulement 2 petits boutons à l'IHM...


---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite
n°766387
mordicator
Posté le 16-06-2004 à 19:50:15  profilanswer
 

On en reviens toujours au meme point, le design :D
Que ce soit au niveau fonctionnel, au niveau des donnees ou au niveau de la presentation, ca devient vite important de savoir ou on met les pieds.
Mais sans entrer dans les details techniques d'une IHM, ne serait-ce qu'au niveau de son ergonomie ca n'est pas a la portee de tout le monde! (encore une fois, a relativiser selon le projet)

n°766393
docmaboul
Posté le 16-06-2004 à 20:08:09  profilanswer
 

HelloWorld a écrit :

Ton design peut être très bien fait, tout marche bien.
Et un jour t'as un client qui te dit "moi je veux l'undo/redo".
Si tu as 10 fenêtres à gérer, je te laisse immaginer la somme de travail pour ajouter seulement 2 petits boutons à l'IHM...


 
il suffit de:
- se faire une classe mère qui va stocker les actions effectuées, déclarer quelques virtuelles à la mords-moi-le-noeud du type CanRedo/CanUndo/Redo/Undo.  
- dériver la classe mère en implémentant les virtuelles selon le besoin, les données, les fenêtres, les contrôles, la couleur de la mer
- aller dans les wrappers qui font le lien entre le code non-graphique et le code graphique pour ajouter les appels aux classes dérivées
- ajouter des appels sur la classe mère dans le bousin qui gère le framework pour gérer activation/désactivation/action des deux boutons
 
le seul truc marrant dans l'histoire, c'est de gérer dynamiquement la validité des actions mémorisées.
Et je ne vois toujours pas où se trouve la difficulté.

n°766396
docmaboul
Posté le 16-06-2004 à 20:11:44  profilanswer
 

mordicator a écrit :

On en reviens toujours au meme point, le design :D
Que ce soit au niveau fonctionnel, au niveau des donnees ou au niveau de la presentation, ca devient vite important de savoir ou on met les pieds.
Mais sans entrer dans les details techniques d'une IHM, ne serait-ce qu'au niveau de son ergonomie ca n'est pas a la portee de tout le monde! (encore une fois, a relativiser selon le projet)


 
Qui se conçoit bien s'énonce clairement, et le code pour le faire vient aisément :D

n°766501
mordicator
Posté le 16-06-2004 à 21:39:14  profilanswer
 

DocMaboul a écrit :

Qui se conçoit bien s'énonce clairement, et le code pour le faire vient aisément :D


 
Snif, c'est beau ce que tu dis :D

n°766642
HelloWorld
Salut tout le monde!
Posté le 17-06-2004 à 01:19:49  profilanswer
 

DocMaboul a écrit :

il suffit de:


Y'a qu'a, faut qu'on...
Evidemment, quand ça fait partie du cahier des charges initial c'est plus facile.
Mais apres 1 an de développement, te prendre ça dans la gueule ça parrait moins évident : faut reprendre tout le code écrit jusque là, les faire hériter de ta classe mère, ...
Toute la difficulté est de réaliser son programme afin de minimiser l'impact des fonctionnalités futures.  
Au passage y'a un pattern spécial pour le Undo/Redo.
 
Autre exemple bateau :sweat:
tu as 4/5 vues, genre 1/2 graphique, une grid de valeurs, des propriétés (moyenne, min, max,...). Bref un truc bateau.
Le client Petcouilles se plaint : "on voudrait pouvoir zoomer sur le graphique et limiter l'étude à l'intervale zoomé".
Il y a fort à parier qu'implémenter le zoom sur le graphique (c'est là que le toolkit intervient) sera plus rapide que d'adapter le code pour que toutes les autres vues et le modèle en interne soient capables de gérer le zoom.


---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite
n°766674
docmaboul
Posté le 17-06-2004 à 05:24:58  profilanswer
 

mordicator a écrit :

Snif, c'est beau ce que tu dis :D


 
Au cas où, je précise que c'est une paraphrase de N. Boileau-Despréaux (dit Nicolas Boileau):
 
ce que l'on conçoit bien s'énonce clairement,
et les mots pour le dire arrivent aisément.
 
(L'Art poétique)
 
J'aime aussi beaucoup celle-ci dont on peut aussi se servir pour le code:
Avant donc que d'écrire, apprenez à penser. (ibid)
 
(avant donc que de coder, apprenez à penser :D)

n°766675
docmaboul
Posté le 17-06-2004 à 05:38:56  profilanswer
 

HelloWorld a écrit :

Y'a qu'a, faut qu'on...


 
Non mon garçon, "il suffit".
 

Citation :

Evidemment, quand ça fait partie du cahier des charges initial c'est plus facile.


 
Je suis d'accord.
 

Citation :

Mais apres 1 an de développement, te prendre ça dans la gueule ça parrait moins évident : faut reprendre tout le code écrit jusque là, les faire hériter de ta classe mère, ...
Toute la difficulté est de réaliser son programme afin de minimiser l'impact des fonctionnalités futures.  
Au passage y'a un pattern spécial pour le Undo/Redo.


 
Peut-être mais ce n'est pas un problème spécifique aux IHM.
 

Citation :

Autre exemple bateau :sweat:
tu as 4/5 vues, genre 1/2 graphique, une grid de valeurs, des propriétés (moyenne, min, max,...). Bref un truc bateau.
Le client Petcouilles se plaint : "on voudrait pouvoir zoomer sur le graphique et limiter l'étude à l'intervale zoomé".
Il y a fort à parier qu'implémenter le zoom sur le graphique (c'est là que le toolkit intervient) sera plus rapide que d'adapter le code pour que toutes les autres vues et le modèle en interne soient capables de gérer le zoom.


 
Soit un programme console tout simple servant à déplacer des fichiers (mv). Mister Petcouilles se plaint : "on voudrait pouvoir avoir un historique en local des déplacements, pouvoir faire des undo/redo, et en plus, que mv se connecte à une machine sur le réseau pour faire et des sauvegardes des fichiers déplacés et des sauvegardes de l'historique. Le nouveau mv devra aussi être capable, avant de lancer ses undo/redo, de déterminer si l'état des différents volumes concernés le permet". Dans le fond, c'est exactement la même histoire: faire une évolution.
 
Bref, à mon sens toute la "complexification" due au codage d'une ihm vient que l'on a nécessairement plus de code, plus de fonctionnalités, et toute une api à apprendre (à mon avis, il est surtout dans ce dernier point le problème) ce qui implique d'être plus rigoureux. Mais dans le fond, ces éléments n'auraient rien à voir avec une ihm, ce serait pareil. Après, il reste toujours l'événementiel mais à part si on utilise beaucoup le multi-thread pour faire des trucs de tordu, ce n'est pas très compliqué à gérer.

n°766791
HelloWorld
Salut tout le monde!
Posté le 17-06-2004 à 10:03:05  profilanswer
 

Citation :

ce n'est pas un problème spécifique aux IHM.


Je suis d'accord, mais c'est encore plus vrai avec les IHM.
Une IHM est en aval de ton model. Donc plus tu modifies ton model, plus y'a de boulo à faire sur l'IHM. C'est normal et quasi innévitable.
Mais une IHM évolue beaucoup plus vite que le modèle généralement, et il est théoriquement pas normal qu'une petite modif sur l'IHM (sans toucher au modele) prenne autant de temps qu'une modif sur le model. En pratique, c'est souvent le cas. L'Undo/Redo était un exemple : tu changes rien au modèle, mais sur une grosse appli qui n'a rien anticipé, ça peut être très long à réaliser, pour finalement quoi : 2 boutons en plus.
Malgré tout, gérer un ensemble élevé de fenêtres n'est pas aussi facile qu'on le pense. Moi j'ai tendance à penser que ceux qui disent que faire une IHM c'est pas bien compliqué n'en n'ont pas fait beaucoup (ça doit être comme tout d'ailleurs).


---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite
n°766974
Joel F
Real men use unique_ptr
Posté le 17-06-2004 à 11:43:10  profilanswer
 

HelloWorld a écrit :

Citation :

ce n'est pas un problème spécifique aux IHM.

j'ai tendance à penser que ceux qui disent que faire une IHM c'est pas bien compliqué n'en n'ont pas fait beaucoup (ça doit être comme tout d'ailleurs).


c'ets pour ca que j'en fait le - possible :|

n°767918
docmaboul
Posté le 17-06-2004 à 17:52:38  profilanswer
 

HelloWorld a écrit :

Citation :

ce n'est pas un problème spécifique aux IHM.


Je suis d'accord, mais c'est encore plus vrai avec les IHM.
Une IHM est en aval de ton model. Donc plus tu modifies ton model, plus y'a de boulo à faire sur l'IHM.


 
Normalement, si c'est bien fait, on utilise des wrappers pour que les dépendances entre la partie graphique et la partie non-graphique soient réduites au strict minimum. C'est l'application de cette règle d'or: "à chacun sa merde" :D D'accord, cela oblige à souvent écrire des fonctions d'une ligne appelant juste une autre fonction mais le gain en clarté est considérable.
 

Citation :

Mais une IHM évolue beaucoup plus vite que le modèle généralement, et il est théoriquement pas normal qu'une petite modif sur l'IHM (sans toucher au modele) prenne autant de temps qu'une modif sur le model.


 
Justement, je ne suis pas trop d'accord avec vous sur ce point. Une IHM, ça récupère des inputs et ça produit des outputs. Tout ce qui n'est pas graphique et/ou input doit être strictement décorélé de l'ihm.
 

Citation :

En pratique, c'est souvent le cas. L'Undo/Redo était un exemple : tu changes rien au modèle, mais sur une grosse appli qui n'a rien anticipé, ça peut être très long à réaliser, pour finalement quoi : 2 boutons en plus.


 
Justement, en rapport avec ce qui précède, le travail n'est pas au niveau de l'ihm (parce que dans le fond, pour le code en rapport avec l'ihm, il suffit d'ajouter deux boutons et la plomberie pour les lier à leur fonctionnalité). Si on prend l'exemple d'un éditeur de fichier C++, lorsque Mr. Petcouilles vous demande d'ajouter le bouton sur lequel est écrit en lettres d'or "compiler", ce n'est pas ajouter le bouton qui est lourd mais bien d'implémenter le compilateur.
 

Citation :

Malgré tout, gérer un ensemble élevé de fenêtres n'est pas aussi facile qu'on le pense. Moi j'ai tendance à penser que ceux qui disent que faire une IHM c'est pas bien compliqué n'en n'ont pas fait beaucoup (ça doit être comme tout d'ailleurs).


 
C'est marrant, j'ai tendance à penser l'inverse: moins on en a fait et plus on trouve ça compliqué :D
 

n°767976
HelloWorld
Salut tout le monde!
Posté le 17-06-2004 à 18:45:24  profilanswer
 

Citation :

Normalement, si c'est bien fait, on utilise des wrappers pour que les dépendances entre la partie graphique et la partie non-graphique soient réduites au strict minimum. C'est l'application de cette règle d'or: "à chacun sa merde" :D D'accord, cela oblige à souvent écrire des fonctions d'une ligne appelant juste une autre fonction mais le gain en clarté est considérable.


Tout à fait d'accord, c'est ce que j'appelais l'interface entre l'IHM et le modele. Ce que je dis, c'est que c'est tres dur de réaliser cette interface de manière à ce qu'elle évolue au minimum dans le futur...
 

Citation :

Justement, je ne suis pas trop d'accord avec vous sur ce point. Une IHM, ça récupère des inputs et ça produit des outputs. Tout ce qui n'est pas graphique et/ou input doit être strictement décorélé de l'ihm.[...]
Justement, en rapport avec ce qui précède, le travail n'est pas au niveau de l'ihm (parce que dans le fond, pour le code en rapport avec l'ihm, il suffit d'ajouter deux boutons et la plomberie pour les lier à leur fonctionnalité). Si on prend l'exemple d'un éditeur de fichier C++, lorsque Mr. Petcouilles vous demande d'ajouter le bouton sur lequel est écrit en lettres d'or "compiler", ce n'est pas ajouter le bouton qui est lourd mais bien d'implémenter le compilateur.


Moi par IHM j'entends tout.
L'Undo/Redo n'a rien à faire dans le modèle. Si on a un module de calcul sur lequel on veut greffer une IHM genre calculette, ce n'est certainement pas au module de calcul de devoir être modifié pour supporter l'undo/redo. C'est de l'autre cote du wrapper => ce que j'appelle IHM.


---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2
Page Suivante

Aller à :
Ajouter une réponse
 

Sujets relatifs
[C++] commande pour quitter un prog sous console ???Comment passer d'une IHM en TCP à une IHM en UDP
Comment mettre à jour proprement une IHM relative à un traitement.Console java dans un applet
[debutant] affichage en mode consoleEffacer l'écran en mode console [Résolu]
Pb programme de création d'IHMModélisation et IHM avec JBuilder
[C(++)/Pascal] Coder une console: pointer une chaine sur procedure ?[ C++ ] reecrire une ligne en console
Plus de sujets relatifs à : Console VS IHM


Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)