UIKit for Mac Development
muqaddar
Administrateur
Un projet brillant ?
http://chameleonproject.org/
Pour ceux qui ne veulent pas pas porter leur soft sur Mac, ça peut être une solution idéale.
A tester. J'ai juste fait un run d'un projet démo.
http://chameleonproject.org/
Pour ceux qui ne veulent pas pas porter leur soft sur Mac, ça peut être une solution idéale.
A tester. J'ai juste fait un run d'un projet démo.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Et puis avec Lion qui arrive.. Je dis rien, mais y'a pas mal de changements surtout au niveau des TableView..
J'étais sûr que t'allais décoller au quart de tour.
Moi je dis, en attendant de développer une version spécifique Mac, ça peut toujours être utile.
Les projets comme ça ça montre typiquement que y'en a certains qui pensent encore qu'une application sur ordi de bureau et une appli sur iPhone ou sur iPad ont la même ergonomie et le même design...
Déjà que c'est pas toujours évident de faire comprendre à certains qu'une appli iPhone et une appli Android n'ont déjà pas du tout la même ergonomie...
En attendant un développement spécial Mac, ça peut être une bonne solution, y compris pour des entreprises. Quand t'as par exemple une appli iPad et une appli PC, si tu veux une appli Mac... mais que t'as pas les ressources pour le faire. C'est un exemple.
Et moi j'exige le moins bien, le vite fait, et le mal fait. :P
Ton argument me paraà®t très pertinent.
Du point de vue de l'utilisateur, il vaut mieux un produit moyen maintenant qu'un produit parfait dans deux ans.
Les logiciels servent à répondre à des besoins après tout !
ça ne m'empêche pas de penser que les IHM portées telles quelles d'iOS à Mac OS sont une abomination. Utiliser un tel outil de conversion dans un univers très concurrentiel (par exemple, un client Twitter) me semble un calcul risqué.
Y'a des tas de choses qui devraient être communes entre UIKit et AppKit.
Je ne connais pas encore bien le SDK Mac mais j'ai l'impression que le SDK iOS est plus abouti dans la simplicité et le pragmatisme.
J'aimerais bien qu'Apple fasse le back to Mac pour l'API.
Il n'y a pas que UIKit, il y a des framework qui n'existent carrément pas sous Mac (comme le MapKit par exemple, c'est certainement pas l'API la plus utile pour des applis desktop mais moi j'aimerais bien l'avoir).
C'est souvent vrai. D'ailleurs, ils pourraient commencer par déclarer les propriétés.
Apple a évité de refaire les mêmes bêtises sur Cocoa Touch que sur Cocoa Mac. Le meilleur exemple est le système de coordonnées qui a son origine dans le coin supérieur gauche sur UIKit, alors qu'elle était dans le coin inférieur gauche sur AppKit. ça n'a l'air de rien, mais ce truc nous pourrit la vie depuis dix ans.
Du coup il y a plein de classes qui définissent leur delegate sous la forme de protocoles informels (catégories de NSObject) ce qui est plutôt crade (c'est un peu un hack pour contourner le pb qu'il y avait de ne pas avoir de @protocol avec @optional), plein de classes où on aimerait bien utiliser les @property et la syntaxe pointée pour accéder à des propriétés des instances au lieu de devoir utiliser les getters... et ça ça me manque quand je retourne sous OSX !
Au moins qd ils ont commencé iOS, on était déjà à ObjC 2.0 et plus 1.0 donc les @protocol @optional et les @property existaient déjà et ils sont directement partis sur les bonnes bases, il faudrait qu'ils refassent une passe un peu partout sous OSX pour remonter ces bienfaits dans le SDK OSX.
Ils le font déjà un peu pour le delegate de certaines classes qui étaient sous forme de protocoles informels et sont passés depuis en protocoles formels, ce qui est bien plus propre et permet au compilo de signaler s'il y a des incohérences, mais c'est pas encore partout
C'est source de plantage en plus car aucune vérification effectuée par le compilateur (il peut pas de toute façon pour ces cas-là ) !
Mais le code que tu crées toi pour OSX tu peux déjà utiliser les @protocol @optional et les @property.
Et depuis plusieurs versions de OSX Apple fait progressivement passer des protocoles informels (implémentés sous la forme de catégories de NSObject donc) en protocoles formels de façon tout à fait transparente. Sauf qu'ils prennent leur temps...
Par exemple NSApplicationDelegate est un protocole formel depuis 10.6 alors qu'il était informel avant.
De même pour NSTableViewDelegate, NSXMLParserDelegate et d'autres encore.
et je suis du même avis ... vouloir tout mettre dans le même sac c'est se suicider à feu lent... car le résultat, est que l'on n'a que le pire de chaque monde ...
de même ce qui pensent qu'une simple récompilation pour un hypothétique mac avec ARM fera l'affaire !!
Et pourquoi pas ? Après tout, on compile déjà les applis pour x86 et PowerPC, qu'est-ce qui empêche de le faire pour ARM ?
Est-ce qu'il s'agit simplement de nouveau portage vers iOS (type CoreImage) ou bien y'a t-il eu des portages dans l'autre sens dans Lion ?
(je n'ai pas la licence dev Mac ::))