Logiciel mac vers windows

[Franky Boy]

Salut tout le monde,
J'ai fait une mini appli en applescript à l'aide de XCode, et je voudrais la passer à mes amis qui sont sous Windows.

Merci

 

[PA5CAL]

Bonsoir

AppleScript est spécifique à Mac OS.

Pour faire tourner ton appli sous Windows, tu devras entièrement la réécrire dans un autre langage.

C'eût été différent si tu l'avais programmé en C, en C++ ou en Java, par exemple.

 

[p4bl0]

Bonsoir

AppleScript est spécifique à Mac OS.

Pour faire tourner ton appli sous Windows, tu devras entièrement la réécrire dans un autre langage.

C'eût été différent si tu l'avais programmé en C, en C++ ou en Java, par exemple.

Pour faire un programme équivalent à ton AppleScript, je te propose de te pencher vers Perl ou Python plutôt que C, C++ ou Java

 

[Franky Boy]

Ok tout le monde, mais détrompez moi mais, je pense qu'il est impossible de faire du Perl et du python sur XCode?

 

[p4bl0]

Ok tout le monde, mais détrompez moi mais, je pense qu'il est impossible de faire du Perl et du python sur XCode?

bah... il suffit d'un éditeur de texte quelconque, XCode peut être utilisé, mais c'est un peu lourd et il n'y a pas de support de la coloration syntaxique...

Moi j'utilise TextMate, (en plus il suffit de faire un pomme+r pour exécuter le script c'est génial).

Après tu le lance par la ligne de commande.

 

[Franky Boy]

OK, j'ai une base en python mais c'est loin et je n'ai aucune idée comment faire une interface en python

 

[PA5CAL]

Si tu veux développer des programmes à la fois pour Mac OS X et Windows, tu devras faire des choix techniques draconiens qu'il te faudra ensuite assumer, car les deux systèmes sont très différents, tant au niveau de l'interface graphique que du système de fichier ou de l'accès aux périphériques, notamment.

Cette différence a toujours constitué un frein énorme au portage sur Mac des applications développées sous Windows. C'est d'ailleurs la cause principale du monopole actuel de Microsoft (les raisons en sont économiques, puisque, pour faire simple, ça coûterait trop cher aux développeurs de "switcher").


Dès que tu touches au système, tu dois absolument utiliser des librairies ou des modules externes spécifiques à Mac OS d'une part et à Windows d'autre part. Tu dois également souvent adopter des philosophies de développement différentes.

Suivant le langage et l'outil de développement choisis, les librairies en question (quand elles existent) sont intégrées à l'unité d'exécution (interpréteur ou programme compil&#233, et des accès au système peuvent aussi parfois être envisagés au travers de composants logiciels adéquats.

Alors avant de te lancer sur une voie ou sur une autre, il faudrait que tu fasses un bilan. Demande-toi :
1) ce que tu veux faire
2) comment cela pourrait être réalisé sur l'un et l'autre des systèmes
3) et enfin seulement, quels outils sont effectivement à ta disposition pour le faire, et à quel coût (prix, temps de formation, temps de développement)

Ce n'est qu'à la fin que tu pourras voir si tu utiliseras C, Java, Python, Javascript ou tout autre langage.


Dis-toi seulement que si les programmes sont trop compliqués (trop "compromis" avec un système ou un autre), il est plus rentable de les réécrire totalement. C'est un vieux développeur (25 ans de métier) qui te l'affirme.

 

[Didier Guillion]

Bonjour,

Tout a fait d'accord avec Pa5cal.
Dans tous les cas, il toujours interessant de travailler en "goulot de bouteille" (bootleneck).
Ceci veut dire que dans ton source tu n'appelle jamais directement une fonction du systeme.
Par exemple, tu veut ouvrir une fenetre. Tu ne vas pas appeller "OpenWindow" du systeme, mais creer une fonction a toi qui s'appellera par exemple "OuvreFenetre".
Dans tes sources tu t'astreindra a toujours appeler cette fonction. Ainsi quand tu passera sous un autre systeme il te "suffira" de reecrire cette couche logicielle. A noter que ceci est applicable dans une application mais aussi d'une application a l'autre. Ton travail sera donc reinvestissable dans tes projets futurs.

Cordialement

 

[p4bl0]

je suis aussi d'accord avec PA5CAL et Didier Guillion.

Ma proposition d'utiliser Python ou Perl, c'était parce que je pensais que ton AppleScript était juste un script, sans GUI, dans ce cas il est possible de faire en python ou perl un équivalent.

Mais pour une vrai appli avec une GUI etc... suis les conseils avisés de PA5CAL et Didier Guillion :zen:

 

[jeromemac]

Bonjour,

Tout a fait d'accord avec Pa5cal.
Dans tous les cas, il toujours interessant de travailler en "goulot de bouteille" (bootleneck).
Ceci veut dire que dans ton source tu n'appelle jamais directement une fonction du systeme.
Par exemple, tu veut ouvrir une fenetre. Tu ne vas pas appeller "OpenWindow" du systeme, mais creer une fonction a toi qui s'appellera par exemple "OuvreFenetre".
Dans tes sources tu t'astreindra a toujours appeler cette fonction. Ainsi quand tu passera sous un autre systeme il te "suffira" de reecrire cette couche logicielle. A noter que ceci est applicable dans une application mais aussi d'une application a l'autre. Ton travail sera donc reinvestissable dans tes projets futurs.

Cordialement

il existe pourtant des logiciels de dev, comme qtech ou lazarus, qui sont multiplateforme, et qui justement ont déja fait ce que tu viens de dire, avec un fonction toute prete "ouvre fenetre"... ça existe, mais etrangement ils ont trés peu de soutient, pourtant c'est ce qui devrait etre mis en avant, un seul logiciel, plusieur compilateur et tu as interface et code pour plusieur système...

 

[PA5CAL]

Il existe effectivement des systèmes de développement multi-plateforme. Ça existe d'ailleurs depuis belle lurette. Mais c'est une voie nécessitant un minimum d'investissement (formation), et envisageable seulement sur le court terme et pour des fonctionnalités somme toute assez limitées.

En effet, l'histoire a montré que jusque maintenant, la majorité de ces systèmes de développement a fait long feu. Du fait de l'évolution inévitable et trop rapide des différentes plateformes, la majorité des éditeurs de logiciels qui ont tenté l'aventure ont dû jeter l'éponge. Ceux qui sont restés dans la course se sont souvent restreints à présenter des fonctionnalités génériques (le plus petit dénominateur en somme), souvent limitées en nombre, ou parfois très spécifiques et à grande valeur ajoutée (base de données et intelligence artificielle, notamment).

De ce fait, les développeurs qui ont utilisé ces systèmes ont jusque maintenant été confrontés à de gros problèmes, tels que :
- la dépendance incontournable vis-à-vis des bogues de l'unité d'exécution fournie (i.e. généralement une machine virtuelle, parfois un compilateur)
- la nécessité, malgré tout, de faire quelques développements spécifiques à tel ou tel OS, quand cela est encore possible
- l'impossibilité de faire des optimisations (en vitesse de traitement notamment)
- les impasses techniques (impossibilité de réaliser) à cause de fonctionnalités non prévues par l'outil de développement, bien que permises par les OS supportés
- l'impossibilité de faire évoluer le logiciel développé dans le sens voulu, pour les mêmes raisons
- le trop grand retard, ou même carrément l'absence de portage de l'unité d'exécution à l'occasion de l'évolution d'un des OS supportés (et cela arrive très souvent)
- et finalement parfois, la disparition de l'éditeur du système de développement, combiné à l'absence d'outil compatible sur le marché.

Pour des développements professionnel coûteux qui se veulent pérennes, ça peut rapidement tourner à la catastrophe.


Il existe bien malgré tout quelques systèmes de développement multi-plateforme qui durent. Le premier qui me vient à l'esprit est Java de Sun Microsystems, qui est apparu il y a dix ans, et dont la sauce semble avoir bien pris ces derniers temps (souhaitons-lui longue vie !)... Sun est une grosse société qui a les reins solides, et les machines virtuelles Java fleurissent sur les plateformes les plus répandues (ordinateurs, PDA et téléphones mobiles, Windows, Linux, Mac OS, Solaris, etc.). Toutefois, on n'est pas pour autant à l'abri des soucis évoqués plus haut.

 

[Didier Guillion]

PA5CAL met le doigt sur un probleme très important: la pérennité des sources.
Les technologies propriétaires et/ou fermées doivent être considérées avec la plus grande circonspection.
Personnellement, j'essaie de ne jamais utiliser une ressource extérieure (librairie, couche logicielle, donnée) dont je ne maitrise pas le contenu. Ou, tout au moins, que je sois capable de réécrire si jamais elle venait a disparaitre ou à se vérouiller.
C'est vrai que l'on a l'impression de perdre du temps au début, mais il est vite récupéré les années suivantes.

Cordialement