!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> Les modifications d'Unix.
  1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

Mac OS X 10.2 : Jaguar (5)




Développeurs, Développeurs, Développeurs !

Ce n'est pas un secret, que je me trouve en porte-à-faux avec de nombreux aspects de l'IUG de Mac OS X, si bien qu'il n'est pas surprenant que je recoure à plusieurs applications tierces qui améliorent celle-ci. La liste comprend TinkerTool, WindowShade X, FruitMenu, DragThing, Menuversum, et Yapsu. Certaines de ces applications utilisent des APIs non publiques et d'autres techniques qui ne sont pas "officiellement supportées" par Apple, si bien qu'on peut s'attendre à ce qu'elles se plantent après une mise à jour majeure de l'OS. Les développeurs qui utilisent des APIs qu'Apple a clairement définies comme non publiques et qui sont sujettes à des modifications (incompatibles) sans avertissement n'ont qu'eux à blâmer si leur application se plante. Pas vrai ?

De mon point de vue, les choses ne sont pas si simples. Les développeurs de certaines des applications ci-dessus sont confrontés à un choix sous Mac OS X : utiliser des APIs privées ou autres techniques "déviantes" pour implémenter leur fonctionnalité, ou abandonner complètement. Autrement dit, il y a beaucoup de caractéristiques vendables qui ne peuvent tout simplement pas être ajoutées à Mac OS X sans utiliser des techniques "illégales". Ce n'est pas comme si ces développeurs utilisaient leurs propres APIs privées, et des rustines habiles par dépit. Il y a simplement une demande pour ce genre d'applications, et ces développeurs y répondent.

Il s'est établi une trêve plutôt inconfortable entre Apple et ces développeurs. Apple, ou bien n'envisage pas, ou bien n'a pas eu le temps d'ajouter certaines fonctionnalités à Mac OS X, et ces développeurs ont trouvé un moyen de les proposer. C'est une occasion de vente pour les développeurs, mais,il y a toujours le risque qu'Apple rajoute ces caractéristiques à l'OS, en supprimant le marché tiers correspondant. Et en même temps ces développeurs doivent faire attention à détecter les modifications de Mac OS X pour s'assurer que leurs applications continuent à fonctionner.

Mais si Apple ne peut pas trouver de temps pour (ou n'envisage pas du tout d') ajouter les fonctionnalités représentées par ces applications dans Mac OS X, il semblerait que de l'intérêt bien compris d'Apple serait de fournir finalement un ensemble d'APIs officiellement supportées pour permettre aux développeurs d'étendre l'OS de façon plus propre. Ce serait dans l'intérêt de tout le monde. Les développeurs auraient une base de code plus stable et plus facile à maintenir. Apple aurait une meilleure assurance que les applications tierces ne mettraient pas en danger la stabilité des services du système partagé qu'elle modifie ou qu'elle étend. Les utilisateurs disposeraient de la fonctionnalité qu'ils attendent. Les développeurs gagneraient de quoi vivre. La plateforme Apple serait rendue plus efficace et flexible. Ce serait une situation gagnant-gagnant.

Cette stratégie est peut être en route chez Apple, mais elle n'est pas encore là. Par exemple, les applications tierces analogues au Dock sont très demandées mais il n'est pas encore possible pour un développeur indépendant de créer une application qui remplace le Dock complètement. Jusqu'à présent, personne n'a été capable de supporter des choses comme les menus du Dock, les mises à jour d'icônes d'applications et les alertes, la minimisation des fenêtres ailleurs, en utilisant des APIs publiques ou privées. Si bien que quiconque utilise une ou plusieurs des applications semblables au Dock doit aussi conserver le Dock en fonction (et éventuellement visible) ou se résigner à perdre les fonctionnalités du Dock, qu'on ne peut pas reproduire ailleurs.

Alors qu'il n'y a pas d'APIs publiques pour des applications qui remplaceraient le Dock, il y a des APIs publiques pour quelques autres extensions de l'OS. Les développeurs peuvent créer de nouveaux menus dans la partie droite de la barre de menu en utilisant l'API NSStatusBar, par exemple. Mais les items en icônes de la barre de menus d'Apple , appelés "menu extras" utilisent des APIs différentes et plus puissantes. Les menu extras fournis par Apple (par exemple le volume sonore et la résolution du moniteur) peuvent être réorganisés en les déplaçant, et ils peuvent être activés ou invalidés en les mettant dans ou hors de la barre de menus.

Tout cela a changé avec l'arrivée de Jaguar, mais pas parce que les APIs ont changé. Si cela avait été le cas, les développeurs tiers auraient mis à jour leurs applications pour qu'elles fonctionnent avec les nouvelles APIs, tout comme ils s'étaient résignés à utiliser des APIs privées au début.

Mais, ce qui s'est réellement passé avec Jaguar, c'est qu'Apple a rajouté du code pour exclure par la force tout menu extra non Apple. Les autres portions de l'API n'ont pas changé. Mais quand un menu extra est chargé, il est comparé à une liste de menus extras "connus" d'Apple. Si le menu extra n'est pas dans cette liste, il ne peut pas se charger.

Il est facile de rire des contorsions trempées de sueur de Steve Ballmer quand il déclame " Développeurs, développeurs, développeurs !", mais Microsoft a clairement compris quelque chose avec laquelle Apple se débat. Il est du meilleur intérêt du vendeur d'une plateforme d'encourager le développement sur cette plateforme. Dans le cas d'Apple, cela ne veut pas dire qu'il faut se mettre en quatre pour rendre chaque service élémentaire du système, ou chaque élément de l'IU disponible grâce à une API publique. Cela représente évidemment beaucoup de travail, et ce n'est pas prioritaire pour un OS en cours de lancement. Mais en même temps, si des développeurs tiers veulent se mettre sur un marché qui suppose que certaines fonctionnalités attendues soient rajoutées sans être supportées, ils doivent alors s'attendre aux conséquences de leurs décisions sur la maintenance.

Mais qu'Apple sorte de son chemin, -faciliter réellement l'effort des développeurs-, en stoppant ces développeurs tiers, et en n'étant toujours pas capable de fournir une alternative, est d'une folie incroyable. Développeurs, développeurs, développeurs ! Pour Apple, cela ressemble peut-être à une déclaration ridicule !

Je n'ai pas encore entendu de justification convaincante à ce comportement d'Apple dans cette situation. La ligne officielle est d'abord que ces APIs n'ont jamais été publiques, et que les développeurs tiers doivent utiliser l'API NSStatusBar plus limitée. Ce raisonnement peut justifier toute modification de l'API menu extras qui entraînerait la faillite de menus extras tiers. Mais cela ne justifie pas de passer du temps de développement uniquement pour gêner les développeurs tiers, sans modification légitime de l'API.

Mais la plupart des utilisateurs ne sont pas aussi prudents quand il s'agit de blâmer. Quand n'importe quelle application se plante pour n'importe quelle raison, cela a pour effet potentiel un mauvais jugement sur Apple. Et ce n'est pas comme s'il y avait une kyrielle de menus extras bogués et susceptibles de se planter qui justifie cette offensive contre Apple. J'ai précédemment utilisé le mot "théoriquement" pour décrire la crainte des menus extras tiers, parce que je n'ai jamais vu un menu extra, quel qu'il soit, se planter, à part le cas où tout le serveur de l'IU du système se plante.

D'un autre côté, j'ai observé plein de plantages complets de l'IU, et un paquet de kernel panics qui n'ont rien à voir avec les menus extras. Il est clair que les menus extras ne font pas partie des défauts de stabilité de Mac OS X.

La restriction des menus extra tiers ne donne pas seulement une mauvaise image d'Apple, c'est aussi une attitude futile. Le blocage a été contourné de plusieurs façons différentes avant même la sortie de Jaguar. Si bien que ce blocage a non seulement été incapable de bloquer les développeurs tiers, il a aussi conduit à un peu plus de code tiers non supporté tournant sous Mac OS X.

Personne ne veut que ce genre de choses tourne en une bataille rangée entre Apple et ses développeurs. En tant qu'utilisateur, je veux seulement que mon logiciel fonctionne. A une ou deux exceptions près, toutes mes améliorations tierces fonctionnent maintenant sur Jaguar en dépit des efforts d'Apple pour s'y opposer. Cela n'est pas une relation saine, et il faut faire quelque chose.

J'espère qu'Apple a compris maintenant qu'elle ne peut pas simplement espérer supprimer les désirs ne n'importe quelle partie de sa base d'utilisateurs. Même si le marché est faible, un vendeur de logiciels, quelque part, essaiera de le satisfaire. C'est une bonne chose. C'est le signe d'une plateforme en bonne santé. C'est quelque chose qui devrait être encouragé par Apple. Et si cela ne peut pas être encouragé dans l'immédiat, à cause de ressources qui doivent être mobilisées sur des choses plus importantes, je ne pense pas que ce soit trop, que de demander à Apple de s'interdire de dépenser un effort supplémentaire pour nuire volontairement à des développeurs tiers qui cherchent à couvrir ce marché. Na !