!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
Mac OS X 10.2 : Jaguar (5)
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 !