Os 9 usb

[Vivid]

j'ai trifouille ds la doc intel-apple pour voir un peu la gestion des pseudo-opts
j'ai fouille ds les sources et je n'ai pas d'explication rationnel enfin j'ai une petite idee
mais je voudrais l'avis des asm boys

Intel connait pas.

par rapport au PPC si tu as des commentaires, n'hesite pas

 

[Céroce]

Alors les technos Apple je les prends avec une pincette de trois mètres.
Tout ce qui ne marche pas avec au moins sur deux plateformes différentes, je l'ignore.

Ah bon Didier, tu fais tes interfaces utilisateur avec QT ou WxWidget?

Le seul avantage de Carbon sur Cocoa, c'est qu'elle est compatible avec Mac OS 9. Toutefois, ça fait quand même 7 ans que MacOS X 10.0 est sorti, et le pourcentage d'utilisateurs sous Mac OS 9 doit quand même être super faible. Vue la différence de temps de développement entre les deux environnements (un facteur 10, je dirais), le choix économique est vite fait.

Didier, je conçois toutefois que vu le profil de tes utilisateurs (musiciens amateurs, pas forcément des gens qui changent de machine tous les 3 ans) et l'ancienneté du logiciel, que le re-développement avec Cocoa n'est pas économiquement intéressant. As-tu toutefois une idée du pourcentage d'utilisateurs sous OS 9 ?

 

[Didier Guillion]

Sur Mac OS 9, je dirait 10%. Mais pas mal de personnes ont Mac OS X plus un portable sur Mac OS 9 pour composer en déplacement.

Pour certaines appli, j'utilise Cocoa, mais plutot pour des Freeware. Je n'ai absolument pas confiance à la perennité des technos Apple, surtout quand elles sont fermées. J'en ai trop vu passer à la "trappe" sans préavis (MPW) ou qui ne voyaient venir aucune amélioration (AppleScript Studio).

A ma connaissance, le format des ressources NIB est toujours fermé, donc, difficilement portable sur une autre plateforme. Développer une appli sur Mac OS et Windows demanderait donc de rédéfinir entièrement les objets de l'interface ce qui est impensable quand l'appli devient un peu importante. Par exemple, mes appli ont chacune environ 300-400 boites de dialogues en 8 langues...

Note que j'ai fait des trucs en Cocoa+OBJ-C et je trouve ca pas mal du tout, bien que la syntaxe d'OBJ-C soit assez prise de tete parfois. Je prefère la verbosité d'AppleScript ou la concission du C, Java ou Perl.
J'admire ceux qui se lancent dans des applis complete Cocoa pur mais je ne prendrait pas ce risque, je veut que mes applis tournent encore dans 10 ans et puisse être adaptés facilement aux plateformes futures.


Cordialement

 

[Luc G]

J'ai essayé une appli avec les technos Apple 100%, il y a quelques années. AppleScript Studio, Obj-C, C. Elle s'appelle Galerie.
Mortalité, Apple est toujours incapable de fournir un déboggeur pour ce genre d'appli.

Je rebondis sur ton message : tu confirmes que c'est toujours le souk pour déboguer sous applescript studio avec xcode 3 si tu l'as essayé ?

J'ai quelques velléités de reprendre une ou deux petites applis hypercard vu que ça devient dur pour les faire touner sur macintel ! (et plus si affinités ) sous applescript studio. Pour faire l'interface, c'est assez sympa pour mes besoins, pour le langage idem quand la vitesse ne joue pas (pour les procédures gourmandes, des petites externes de calcul en pascal sous hypercard, je pense faire du C bête malgré mon allergie malheureuse mais incontournable à la syntaxe C). J'espère que l'absence de débogueur ne me perturbera pas trop vu mes besoins. Ceci dit, ça relève plus du jeu et d'une velléité (j'aime bien ce mot ) de rester un minimum branché sur la programmation que d'un besoin crucial.

C'est vrai que notre Steve a une fâcheuse tendance à jeter le bébé avec l'eau du bain plus souvent qu'à son tour.

Ceci dit, Galerie est toujours un régal et ne m'a pas posé de problème pour l'instant même avec Léopard et iphoto 7 (ilife 8).

 

[Didier Guillion]

C'est toujours le Souk. Je n'arrive toujours pas a faire fonctionner le déboggeur sous AppleScript.
La moindre correction qui se ferait en 5 mn, Hop ! point d'arret, Boum ! les variables,Zou! on corrige devient une prise de tete de demi-journée avec truffage du code du Log.

Une discussion houleuse sur le forum Apple d'AppleScript a eut lieu à ce sujet. J'ai pas tout compris mais grosso modo, les devs demandaient à Apple s'ils continuaient à vouloir faire progresser ou non.


Cordialement

 

[Céroce]

J'ai cru qu'avec l'arrivée d'Automator sous OS 10.4, ils amélioreraient un peu AppleScript, mais en effet, tout cela semble bien à l'abandon (et pourtant, toutes les applis utilisant les bindings Cocoa profitent automatiquement d'AppleScript).

 

[Luc G]

c'est vrai que devoir coller des log partout, c'est plus que pénible.
À croire que Apple, qui voulait faire sauter applescript lors de la préparation d'OSX et était revenu sur ses pas au dernier moment, n'a pas abandonné l'idée, sinon de le supprimer, du moins d'en dégoûter les gens …

Et pourtant, avec Hypercard dans le temps ou avec un bon applescript studio, il y a de quoi permettre à plein de gens de faire des petits trucs en programmation, certes différents des grosses applis pro mais très utiles. Je pense à tout ce qui est éducation et à plein de petites niches dans le domaine pro (par exemple, parce que je connais un peu ce domaine, le traitement de données de mesure).

Reste plus qu'à espérer que le balancier reparte un peu du bon côté (je pense que l'iphone a bouffé beaucoup de ressources R&D chez Apple depuis un bon moment).