hello,
Je suis de plus en plus en train de regarder ObjectiveC et Cocoa,
et je demandais si vous aviez des avis dessus en comparaison a Qt/C++ ?
Merci et a+
Version imprimable
hello,
Je suis de plus en plus en train de regarder ObjectiveC et Cocoa,
et je demandais si vous aviez des avis dessus en comparaison a Qt/C++ ?
Merci et a+
Hier, j'ai essayé plus en détails Cocoa et Objective C et ca a l'air pas mal du tout. Objective C est assez lisible meme si ca fait un peu l'effet [][[[[[]]]]].
Je n'aime pas trop l'assignation graphique des events ou des attributs. J'en avais enlevé un par hasard sans faire vraiment expres, mais bon ca doit etre l'habitude...
en fait je crois que ce qui manque le plus c'est la portabilité en fait, hier je voulais faire un petit programme, mais ... et pour linux et windows ?
... et mince !
Meme si ca me fait tres envie de decouvrir Objective C, et je pense qu'il a pas mal d'avantages, il lui manque principalement la portabilité.
et pour vous ?
en tous les cas, je sais ou Qt a puisé son inspiration maintenant ...
Je ne crois pas que le forum C++ soit le bon.Citation:
Envoyé par epsilon68
Thierry
Qt est bien plus vieux que Cocoa.
Cocoa n'existe que sous Mac OS X, normal c'est l'API native de Mac OS X pour faire des fenêtres.
Par contre, aucun problème pour utiliser Objective C où que ce soit...
non pas du tout,Citation:
Envoyé par loufoque
cocoa est en fait NextStep et est tres vieux, plus que Qt
Faut pas oublier non plus le coté licence...parce qu'il me semble que Qt ne soit pas gratuit :roll:Citation:
Envoyé par epsilon68
Bonjour,
Si, il y a une version gratuite, et même open source.Citation:
Envoyé par Mat.M
Cocoa est basé sur NextStep mais n'est pas NextStep.
... rattrapes toi comme tu peuxCitation:
Envoyé par loufoque
Objective C est quand meme vraiment un beau language,
en plus on peut le mixer avec C++ (Objective C++)
Personne n'a penser a l'utiliser ?
finalement tout le monde critique la solution de trolltech sur les signals/slots,
mais au bout du compte, pourquoi ne pas choisir un language qui possede ces facilités ?
Au final, je pense quand meme que l'atout multi-plateforme est celui qui prime, mais comme m'avait dit quelqu'un sur un autre post (Qt vs Boost) il est plus que mega important de bien separer l'UI et le code metier... on sait jamais si on a besoin d'un portage natif ....
Vos avis ?
J'ai lu un peu partout que Objective C manque de performances....
et que ObjectiveC++ est super long a compiler et point de portabilité.
Hooo la la ca refroidit pas mal tout ca !!!
Objective C++ est sans intérêt.
Objective C avec C++ ça va pas bien ensemble, c'est une mauvaise idée de les combiner à mon avis.
disons que ObjectiveC en lui-meme me seduit (les messages etc...)Citation:
Envoyé par loufoque
mais me lier a macosx .... c'est tout autre.
mon avis maintenant, faire le maximum en Qt, et puis s'il y a vraiment des trucs tres specifiques pour mac alors a ce moment utiliser objective C++ et cocoa pour la chose.
D'autre part j'ai vu des benchmarks (oui je sais c'est toujours relatif) et le retain / release est pénalisant pour certains cas.
J'aime le C++ qui permet de choisir ! son universalité et sa puissance
a+
Pour la deuxième fois, Objective C est disponible sur un grand nombre de plate-formes.
C'est dans GCC, donc a priori c'est dispo sur toutes les architectures existantes pas trop exotiques.
ObjectiveC++ tout seul ne m'avancera pas, il faut le coupler avec du gui,Citation:
Envoyé par loufoque
et dans ce cas la portabilité ... pioup disparue.
... Qt/C++ est plus universel
... mais je souhaite que ObjectiveC++ (et un toolkit multi-plateforme) se developpe dans le future. (GnuStep est a la traine et n'est pas compatible ObjectiveC++)
Par curiosité, comme je ne connais pas ce langage, quels sont les points qui semblent intéressants, comparé au C++ ?
Personellement, sous Mac, j'utilise Cocoa/Objective-C++ pour une application, et Carbon/C++ pour une autre. La premiere est uniquement Mac, la seconde est multi plateformes.
Voila en vrac mes +/- sur Cocoa/Objective-C
+ Prototyping rapide de l'UI. Avec Cocoa/Interface Builder on peut generer une GUI tres riche sans le moindre bout de code.
+ Beaucoup de fonctionalites GUI gerees par les bindings -> moins de code repetitif typique de la prog GUI. Par exemple, des trucs du genre un slider et un champ texte qui controlent la meme valeur et qui doivent donc etre synchronises impliquent typiquement du code sans interet. Avec les bindings, plus de code, ca marche tout seul (en passant aux bindings, j'ai jete la moitie de mon code GUI).
- A la maintenance, il devient difficile de savoir quels sont les bindings presents dans une GUI. Tout ca est dans des forms associes aux objet visuels et il est pas evident de s'y retrouver.
+ Objective-C est facile a utiliser et le concept de messages (sortes de methodes recherchees dans l'objet destination au moment de l'appel) est tres souple dans la mesure ou on peut envoyer des messages a n'importe quel objet qui l'ignorera s'il ne le comprend pas.
- Le revers de la medaille c'est que, quand le prog grossi, on perd le controle et comme les erreurs du genre appel d'une methode inexistante (ne serait-ce qu'a cause d'une typo), ou passage de parametres errones ne sont pas detectees au moment de la compilation (en tout cas pas toujours), on cree des bugs qui ne seront decouverts qu'au run-time (avec de la chance).
+ Si on developpe une appli grand public sous Mac, il est vraiment difficile de contourner Cocoa: les utilisateurs Mac attendent la qualite Cocoa dans leur GUI et on ne peut eviter ca que pour des applications tres verticales.
En resume:
- Si tu veux faire une application purement sous Mac et de taille moyenne, Cocoa/Objective-C est de loin la meilleure solution.
- Si tu veux du cross plateformes, le mieux est de separer completement ton noyau applicatif de ton code GUI, avec une API bien definie. Et d'implementer une version native de chaque GUI. Dans ce cas la version Mac peut etre en Cocoa (et c'est la qu'Objective-C++ devient utile: pour faire le point entre le code GUI et le code application, qui lui est en C++).
- Si tu veux faire une application pour un marche vertical ou pour une audience limitee, tu peux utiliser un toolkit cross-plateformes comme Qt (moi je prefere dans ce cas FLTK).
Juste mon avis...
Pour moi, le point le plus attirant est l'envoi de message.Citation:
Envoyé par JolyLoic
... aussi je trouve la critique ci-dessus tres tres complete. Merci beaucoup.
Par contre si on implemente la partie metier dans chaque gui de chaque plateforme, ca devient vite ingerable, et j'en ai fait l'experience a l'epoque pour un logiciel sur Mac et PC.
Pour moi ca serait plutot Qt maintenant et ses signals/slots.
et surtout bien separer la partie gui et metier au cas ou (Qt ne serait plus a la "mode")
Pourquoi ne pas prendre Qt pour du cross platform sachant que c'est fait pour du cross platform ?Citation:
Envoyé par bricerive
Et pourquoi limiter Qt à une audience limitée ???
Je n'ai pas dis ça.Citation:
Envoyé par Miles
Je parle d'un choix lié à la configuration du marché Mac (si on parle de Cocoa, on parle du Mac).
Si tu veux faire une application grand public sur un marché horizontal qui tourne sur Mac, tu n'as pas beaucoup d'autre choix que de faire du Cocoa. Pourquoi? parce que tu sera en compétition avec d'autres programmes et que, sur Mac, le design visuel est très important, et que le seul outil viable permettant d'atteindre le niveau requis de ce point de vue est Cocoa.
Par contre, dans tous les autres cas:
-Ton application ne concerne qu'un nombre limité d'utilisateurs
-Tom marché est tellement vertical que tu n'auras pas de concurrence
-Ton appli est tellement géniale que personne ne va juger la qualité de sa GUI et personne ne va jamais réussir a faire une appli concurrente ;)
-Tu te fiches de savoir si quelqu'un va payer ou meme utiliser ton appli 8O
-...
, Qt ou autres feront parfaitement l'affaire.
En tout cas, en faisant du cross platform, on touchera plus de monde qu'en utilisant que Mac.
Ensuite, sous Mac, Qt a un look&feel natif, donc à priori, pas de pb, les GUIs faites avec Qt sont quand même plus belles que pas mal d'autres toolkits, ...
Donc là, je suis :|
Autant, si le toolkit n'utilisait pas la bibliothèque native, ton argument aurait un poids certain, autant dans le cas contraire, c'est complètement biaisé.
Tout dépend du produit et du marché.Citation:
Envoyé par Miles
Par exemple, Microsoft a essayé d'utiliser cette approche pour sa version Mac d'Office. La réception du marché a été tellement catastrophique qu'ils ont jetté à la poubelle près d'un an de developpement de GUI cross plateform pour refaire une GUI native à partir de zéro.
Il ne suffit pas d'utiliser une bibliothèque native pour avoir une GUI native. C'est le piège dans lequel beaucoup de gens sans expérience de la question tombent.Citation:
Ensuite, sous Mac, Qt a un look&feel natif, donc à priori, pas de pb, les GUIs faites avec Qt sont quand même plus belles que pas mal d'autres toolkits, ...
Donc là, je suis :|
Autant, si le toolkit n'utilisait pas la bibliothèque native, ton argument aurait un poids certain, autant dans le cas contraire, c'est complètement biaisé.
Le problème est que chaque OS essaye de se différencier (en partie) par des spécificités de son interface. Et à ce petit jeu là, Apple est numéro 1. Du coup, si tu fais une GUI cross-plateforme, tu ne peux pas utiliser les différences, et, sur Mac, les utilisateurs te punissent.
C'est parce que tu vas à l'encontre de leur approche qui est: je choisis un Mac parce que c'est plus beau. Si tu leur fournit un produit qui n'est pas plus beau que sur PC, il sont déçus.
Enfin, j'essaye pas vraiment de gagner un argument: j'essaye de partager mon expérience. Si tu veux faire une appli avec QT sur Mac, libre à toi :D
Objective C a aussi l'avantage de rendre le code moins type safe, moins performant, et plus sensible aux erreurs.
Objective C ce n'est rien que du C avec une couche objet, certes plus dynamique que celle de C++.
moi je suis aussi utilisateur du mac, mais au contraire je suis content quand je retrouve les meme produits sur Windows ou linux. Exemples: Firefox, thunderbird (email), VLC (video), psi (chat) ...Citation:
Envoyé par bricerive
par contre je ne sais pas si firefox s'appuie sur une librairie multi-plateforme, je sais que c'est gtk sur linux mais sur windows et mac ?
VLC sur wxwindows et psi sur Qt
Par experience faire un produit multi-plateforme est tres dur, souvent deux developpers, qui font aussi evoluer le produit en fonction de la plateforme, ce qui conduit a des divergences. Je serais plutot d'avis de faire la meme interface et faire des compromis sur certaines plateformes. Une librairie multi-plateforme s'impose donc en fait ....
Mais je suis d'accord, le produit ne doit pas etre *moins* bon sur Mac (ou windows ou linux) sous pretexte qu'il est multi-plateforme...
Un grand merci pour partager vos experiences
a+