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

 
moi aussi pour le Fortran

 
j'espere que tu sais ce que tu viens de faire...

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.

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

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.

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.

oui ben ça entre aussi dans la catégorie besoins ça

 
ca vient dans les besoins  

-- et uriel> ouais c'est vrai

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 ^^'

 
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

 
Si tu voyais avec quoi je compile

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...

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

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.

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!

 

 
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.

 
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à...

 
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.

tu t'autoquote??

il complete sa réponse  

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...

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...

On en reviens toujours au meme point, le design
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)

 
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é.

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

 
Snif, c'est beau ce que tu dis

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
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.

 
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 )

 
Non mon garçon, "il suffit".
 

 
Je suis d'accord.
 

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

 
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.

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).

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

 
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'accord, cela oblige à souvent écrire des fonctions d'une ligne appelant juste une autre fonction mais le gain en clarté est considérable.
 

 
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.
 

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

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...
 

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.