Coucou tout le monde!
 
Actuellement, je réalise un prototype d'IHM en java pour une future application afin de pouvoir présenter aux utilisateurs finaux ce à quoi va ressembler l'application et valider les choix d'ergonomie!
 
Le problème est que l'application final est en C++ sur une plateforme Windows, et que ma boite (SSII) voudrait que je développe l'IHM final en C++ (sans tenir compte de mon avis bien sur, car ca me rebute).
Le problème est que je n'ai pas une grande maitrise du C++ (Java ok, mais le C++, à part les bases vu à l'école, ca va pas plus loin et en plus ca date de 3 ans) et surtout je n'ai aucune experience d'IHM en C++.
 
Ma question est:
-Est ce que c'est c'est réalisable de se lancer dans ce développement vu ma faible experience dans ce domaine? Ou alors ca va être un enfer à gérer en sachant que c'est une charge de 60 Hommes/jour et qu'il n'y personne pour m'épauler?
 
Autre question, d'un point de vue capitalisation d'expérience, est-ce vraiment intéressant?
Un développement sous C# présenterait plus d'intéret,non ?
 
Les avis sont les bienvenue

Si tu as l'habitude de Java je te conseille vivement le C# et la lbrairie WindowForm.
 
Si tu tiens a faire du C++ tu peux imaginer passer par MFC qui est la librairie graphique la plus intuitive...
 
Sinon as tu pensé a Qt ?  
 
Documente toi sur ces 3 librairies, mais je pense que le langage C# sera plus adapté ne serait ce que parcequ'il utilise un garbage collector ; si tu gere mal ta mémoire en c++ tu n'iras pas loin, et vu que tu n'en as fait que trés peu...
 
Bonne chance

 
c'est bien ça qui me fait peur la gestion de la mémoire    
 ( sans compter les maudits pointeurs)
En java, le garbage collector facilite tout de même la vie.
Sinon, autour de moi, on m'a déconseillé les  MFC qui sont un peu l'usine à gaz.
Mieux vaut regarder QT qui tu le soulignes ou alors l'éditeur Borland C++ pour le plugin d'ihm!
 
Pour le C#, qui se rapproche pas mal de java et avec son garbage collector, la prise en main sera plus rapide je pense qu'une remise à niveau en C++ et l'approche d'une bibliothèque graphique en C++, mais bon au niveau du caher des charges, c'est niet!
 
En sachant la charge de travail que cela represente sans assistance, ce sont de belles nuits blanches en perspective ou de bonnes prises de têtes avec le chef de projet    

 
euuuhhhhhh ......
 
intuitive n'est pas le mot que j'utiliserais pour les MFC ...

Je sais que tout le monde crache sur les MFC... Mais perso je les utilises pas mal pour tout ce qui est interface graphique de ptits logiciels pour PME... Une fois qu'on connais bien ca va vite, meme si le code derriere est pas toujours tres propre.
 
Qt est vachement facile a prendre en main, puis il propose une compatibilité interessante.
 
Mnt je pense sincerement que ce genre de soft seront bientot tous programmé en C# grace aux windows.forms

Donc pour conclure, en choissisant QT comme outil, combien de temps estimez vous nécessaire pour reassimiler les concepts en C++ ( j'ai tout oublié)  et maitriser les api graphiques?
 
Assez long,non?
 
Je vois en java, même si Swing est assez intuitif, je perds souvent pas mal de temps pour trouver la bonne méthode pour obtenir un rendu graphique particulier et gèrer les renderers sur diffèrents composants alors je me dis qu'en C++, ca va être joyeux aussi  

Avec QT tu n'as pas a te poser de question tu veut un widget ben tu l'instancie point.
Le C++ lui est pas bien dur, QT reste relativement intuitif aussi.

Pour bosser avec l'une et l'autre, je trouve QT nettement plus agreable a utiliser que MFC... mais pour des raisons qui plairont pas a filpinpin :  
 
Le defaut (pour moi) des MFC est d'etre absolument a vomir des qu'on sort de l'usage standard accessible au sein de l'environnement de developpement Microsoft, et cet environnement est pas mal castrateur... La doc est aux abonnes absents puisqu'elle est integralement orientee vers l'utilisation "standard"...
 
QT est moins integre a un outil de developpement (meme s'il y en a un, et qui marche bien d'ailleurs) et en cela ressemble plus a de la programmation classique C++.  
 
De toute facon maitriser la gestion de la memoire c'est un peu indispensable pour faire du C++, que ce soit avec QT ou avec les MFC...
 

 
Pourquoi faire le proto en java pour valider l'ergo et voir à quoi cela va ressembler , ca n'a aucun sens puisque que de toute facon tu sera obligé de choisir une autre lib graphique que swing
 

 
Ton avis tu sais .... ils s'en foute royalement (je parle avec ma propre expérience sur le sujet), donc aucune incidence sur le reste
Si tu n'a aucune experience d'IHM en c++, c un peu chaud quand meme.
La plateforme de dev? Si c le couple Windows/ visual studio , opte pour les MFC , en plus tu aura un IDE, c plutot bonnar. Si c'est autre chose, dis nous quoi  
 

 
Bon quand tu dis 60 J/h , ça veut dire en gros 3 mois. pour faire une IHM c pas stressant. maintenant il faut savoir ce qu'il y a derriere. Gros gros soucis , surtout ne pas y aller en aveugle et bien lire le cahier des charge.
 

 
Toute capitalisation d'expérience est la bienvenue , une fois que tu saura faire une IHM en C++ sous windows ça sera plutot bien pour ton CV. Le dev en C# représenterait à coup sur plus d'interet pour toi mais pas pour ton client dans la mesure ou une installation de la CLR (en gros la VM de MS) sera necessaire. Ce qui est largement plus lourd par exemple qu'une IHM en c++ avec les lib en static. Le pb serait le meme pour Java
 
 

Bon si on résume, parmi les API ou IDE à utiliser pour faire une IHM en C++,  
Je vois qu'on a le choix avec:
- MFC
- QT
- Borland C++ Builder
- Ilog Views
- Autres ?
 
Quels sont les avantages/inconvenients de chacuns:

il y a aussi wxwidgets   qui me semble bien plus abouti que QT, tres simple a utiliser, fonctionne sur tous les environnements et si tu es sous win, tu peux utiliser devc++ et le devpack wxwidgets 2.6.1, ca s'installe en 5 min telechargement compris, il n'y a alors rien a compiler.
De plus avec la quantité d'exemples fournis, tu trouveras toujours comment faire meme s'il n'y a personne pour t'expliquer, et la documentation est enorme ( en anglais, mais enorme)  

Ben moi je suis en train d'en développer une et ce sera avec GTK+2!!
 
J'avais fait pas mal de recherche et vu qu'il faut que ce soit gratuit et portable, on a fini par dire "ce sera GTK"...  

Borland C++ Builder permet de réaliser  
des interfaces graphique trés facilement.
C'est probablement l'un des plus intuitif de tous.

Je vois que les avis divergent!    
Ca va pas faciliter mon choix!
 
 
En ce qu concerne C++ Builder, quel est le prix de la licence par contre?
Y a t-il des différences de compilateur ensuite entre celui de Visual Studio et celui de Borland?
 
 
GTK+2, je connais pas, ca vaut quoi  par rapport aux autres?

Gtkmm est vraiment surper bien foutu, y a des ruses templates dedans, c'est tout simplement fantastique à utiliser (car simple, je pense notemment au manipulation de colonnes d'une treeview)
 
Avec un générateur comme glade, ça va encore plus vite

 
Tout à fait d'accord!!    
 
Par contre, je peux pas comparer aux autres car je connais pas les autres... Je sais que The Gimp est fait avec GTK, ca peut donner une idée...

ce que j'ai essayé, et mon avis:
 
MFC: un peu chiant sur certains point, mais très performant
 
C# winforms machin: moué c'est moins chiant, mais.... c'est lent, trop lent
 
C++ Builder: bon compromis, assez à très rapide, et intuitif

 
C'est un peu le défaut que l'on reproche aussi à Java et Swing, du à la machine virtuelle,non?
 
Et sinon, entre MFC, wxwidgets et C ++ Builder, qui possède la plus grande communauté/support/forum?
 
MFC semble possèder pas mal de support,non?

moi je trouve pas que .Net soit lent, du moins, n'ayant utilisé que mono et gtk#, une fois que l'appli est lancée, à part la conso mémoire un peu plus grande, c'est insoupçonnable que c'est du C# derrière ... alors qu'une daube java, ça se sent à 10km

bin ché pas dans ma boite j'ai du retoucher une appli C# faite par un gars avant moi, et le retraçage de la fenêtre et lent comme un truc java

qu'est ce que vous appellez une IHM ?

bin l'interface quoi, les fenêtres du biniou...

IHM = Interface Homme Machine!    
 
c'est la meme chose que GUI = Graphical User Interface!

ah ok c'est juste que j'ai plus l'habitude avec le terme GUI, je dormirai moins con merci

En ce qui me concerne je penses que Borland C++ builder est facile a utiliser, mais je n'ai jamais utilisé les autres

wxDevCpp : http://g.yi.org/?f=566
On peut considérer ca comme un RAD pour les wxWidgets.
C'est integrer à DevCpp...et c'est quand même utile.

je sais pas pourquoi mais j'ai jamais adopté tout ce qui est Borland
 
A part ca pour développer une GUI je suis un fan de Qt mais j'ai bien envi de tester GTK pour voir ce que ca donne

Intuitive ?? C'est quoi cette blague ?
Les MFC sont une abomination sans nom qui n'a ni queue ni tête.  
A éviter coûe que coûte, sauf si tu veux exploser tes délais. (et quand je dis ça, je ne plaisante pas : je ne connais pas un seul projet MFC un tant soit peu conséquent qui n'ait pas complètement explosé les délais, une partie non négligeable du temps perdu étant due aux MFC). Laisse tomber IlogViews aussi.
Qt par contre, est un choix tout-à-fait viable pour une grosse appli, et je suppose que wxWidget et Gtkmm aussi.
Sinon, si l'appli est de taille moyenne, Lgi peut aussi être une option à considérer.

 
Je conseille aussi wxWidgets (ancien wxWindows) qui est très simple, léger (car tout est natif contrairement à QT) et très bien documenté. Par contre je n'irais pas jusqu'à dire que c'est + aboutit que QT. Mais c'est assez aboutit pour être utilisé en entreprise.
MFC c'est pas portable (si c'est pour du pur windows ok c'est pas grave) mais ça va bientôt disparaitre au profit de .NET et du C#.

Qt est tout natif maintenant il me semble

 
Attention à la licence pour Qt... sous windows y a encore des problèmes...
 
Sinon, moi j'avais aussi hésité avec Tcl/Tk mais il y a moins de choix dans les widgets qu'avec GTK  

Un collègue travaille actuellement avec GTK2 sous Win XP.
J'ai été surpris par la lenteur de l'IHM.
 
Cela provient-il de l'application (si je faisais la même en MFC ça tournerait au bas mot 10 fois plus vite) ou GTK2 est-il lent?
 
Je précise qu'après avoir fait un profile de son application sous Visual (LOL), il apparaît que l'appli passe 60% de son temps dans le dessin/remplissage d'arcs.
 
Question: pourquoi Insure++ se bloque (ne fait plus rien mais ne consomme pas de processeur non plus) sur certaines instructions GTK?

Pour Insure++, la reponse est simple: le parser est mediocre et ne gere pas tous les cas, donc il se bloque. Ce genre d'outils ne s'en sort que sur du code C++ assez standard (unix), et se ramasse generalement des qu'il y a des macros, bcp de templates ou trop de fonctions de librairies d'IHM. Donc il ne faut instrumenter que du code qui ne soit pas du code d'IHM. Ce qui signifie qu'il faut selectionner les fichiers que tu passes a Insure. Ca oblige a separer le code d'IHM du code fonctionnel, ce qui n'est pas plus mal.
Sous windows, le seul outil que je connaisse qui marche pas trop mal est BoundsChecker.

Perso, j'utilise glowcode sur mon monstre à moi

Exit donc Insure++ parce que c'est justement l'IHM qu'il fallait vérifier (fuite de mémoire)...    
 
Je vais regarder les outils cités, merci.  

Oublie aussi Rational.
 

Ca marche bien, Glowcode ?

PErsonnes n'a déjà utilisé Ilog Views?
Curieusement, je me rappelle lorsque je passais des entretiens qu'on me demandait souvent si je connaissais Ilog Views ou non? Qu'est ce qui est si bien avec ce produit?
 
Bon sinon wxwidgets semble pas si mal alors?
 
Maintenant, concernant les MFC : est ce que ca vaut le coup de s'y plonger dedans (en sachant que c'est juste pour un projet et que je ne projette plus d'en faire par la suite), et quel est l'avenir des MFC à terme aussi?

 
Oui. Tu sais ce que j'écris et à quel point il peut être bloat, et j'ai toujours réussi à retrouver mes problèmes avec. L'autre jour, j'ai du intervenir dans un interpreteur avec glowcode (chute des perfs), et j'ai pu isoler le problème rapidement.
 
Mais je fais juste du profiling CPU et leaks, pas de profiling mémoire.
 

 
_o/
 
grosse bouse infame, pétrie de bug (j'ai le numéro du support programmé en 1 sur mon téléphone), à l'architecture fumeuse (pas la peine d'espérer une séparation Data/View chez eux). Par contre, il ont des gadgets avancés pour faire facilement de la visualization graphique ou caretographiquye, d'ou leur succès dans certaisn domaiens.

 
Ilog Views, comme dit Elianor, laisse tomber, c'est de la vieille techno dépassée et bien moisie. Les quelques trucs que ça fait existent par alleurs en open source ou dans des librairies de visualisation scientifique ou chez des concurrents. A oublier.
Si on te demande en entretien si tu connais Ilog Views, il y a de grands chances que tu fasses de la maintenance d'un existant plus que de nouveaux dev. Honnêtement, utiliser Ilog dans de nouveaux dev aujourd'hui, c'est s'assurer un gros bloatware poilu à moyen/long terme.
 
Quand aux MFC, aujourd'hui, vaut mieux se mettre à .net si tu veux faire du windows. Ca t'évitera des crises de nerfs.
 

Bon, effectivement, ça doit être un bon soft alors.