![[Logo TidBITS]](images/tblogo.gif)
Si vous avez entendu dire que les versions futures de Mac OS ne seront pas compatibles avec les logiciels actuels, ne paniquez pas : ce ne serait pas la première fois que les médias généralistes se seraient trompés au sujet d'Apple. Vous trouverez aussi dans ce numéro des nouvelles des mises à jour de Frontier et de Corel WordPerfect; Adam explique certaines des raisons qui nous ont fait interrompre la publication de DealBITS, Matt Neuburg termine son compte-rendu de QuicKeys 3.5, et nous souhaitons la bienvenue à un nouveau commanditaire de TidBITS, Aladdin Systems.
Ce numéro de TidBITS est commandité en partie par:
Copyright 1990-1996 Adam & Tonya Engst. Plus d'informations
à la fin.
Informations:
<info@tidbits.com>.
Commentaires:
<editors@tidbits.com>.
Ce numéro est traduit de l'américain par:
Coordination et mise en page par :
Thèmes:
Vous pouvez trouver ce numéro en v.o. à:
<http://www
.dartmouth.edu/pages/TidBITS/issues/TidBITS-348.html>
![[-----]](images/tbrule.gif)
Aladdin commandite TidBITS -- C'est avec grand plaisir que j'accueille notre plus récent commanditaire, Aladdin Systems, un développeur Macintosh de longue date. Aladdin se classe parmi les plus connus des petits développeurs pour Macintosh, surtout auprès du monde en ligne où son produit phare, StuffIt, est devenu le format de compression implicite. La raison de l'omniprésence du format StuffIt est simple : ce logiciel est venu au monde sous la forme d'un partagiciel et Aladdin a toujours gardé une gamme complète de produits liés à StuffIt : gratuiciel (l'indispensable StuffIt Expander), partagiciels (DropStuff et StuffIt Lite), logiciels commerciaux (StuffIt Deluxe, Aladdin Desktop Tools, CyberFinder) ou encore tout cela à la fois, comme le logiciel simple à utiliser StuffIt InstallerMaker, qui comporte toute une gamme d'options de licence.
Aladdin a toujours apporté un soutien énergique à la communauté Macintosh en ligne. Beaucoup de leurs programmes commerciaux sont accessibles pour téléchargement et essai gratuit et les prix de ces logiciels sont réduits pour les personnes qui s'enregistrent en ligne. De plus, des membres du personnel d'Aladdin participent à diverses listes de distribution se rapportant à l'Internet et au Macintosh, et consacrent leur temps, leurs talents et leur connaissances à divers projets et organisations sur le réseau.
Récemment, Aladdin a embauché un nouveau président-directeur général, John Nesheim, qui devrait aider Aladdin à gérer son expansion rapide et à élargir sa gamme de produits. Nous leur souhaitons bonne chance et somme heureux d'accepter leur soutien à TidBITS. [ACE]
Frontier 4.1 -- Dave Winer, Doug Baron, et l'équipe de UserLand ont publié la version 4.1 de Frontier, leur environnement de scénarisation adaptable à l'Internet. Frontier 4.1 présente une interface utilisateur mise à jour, qui comporte de nouveaux menus et une paire de "navigateurs" destinés à faciliter l'accès à certaines parties essentielles de la base de données d'objets, un Guide de l'utilisateur entièrement révisé, une nouvelle documentation touchant à la scénarisation d'un site Web grâce à Frontier et la possibilité d'utiliser les cartes MacBird (voir TidBITS-309), ce qui ajoute des possibilités de personnalisation de l'interface. Frontier 4.1 bénéficie aussi d'une multitude de corrections de bogues et de modifications, gracieuseté de sa très active communauté d'utilisateurs, et d'un prix imbattable : Frontier est toujours gratuit.
Pour l'instant, un logiciel de mise à jour de la version 4.0.1 à la version 4.1 (environ 2,5 Mo) est disponible, mais à l'heure où vous lirez ces lignes, la "distribution complète" de Frontier 4.1 devrait être prête. Assurez-vous de suivre les instructions d'installation (et d'avoir une copie de secours de votre fichier racine Frontier!) et de télécharger le nouveau Guide de l'utilisateur (environ 1,1 Mo). [GD]
<http://www.scripting.com/frontier/>
Mise à jour 3.5.2 de Corel WordPerfect -- Corel vient de publier un logiciel de mise à jour vers la version 3.5.2 de WordPerfect qui devrait corriger une douzaine de bogues dont certains liés à l'impression d'enveloppes. Il semble que pour l'instant le logiciel de mise à jour ne soit disponible que sur le service télématique surchargé Wildcat qui appartient à Corel; le serveur FTP n'est pas vraiment standard et un certain nombre d'utilisateurs de Macintosh ont signalé des problèmes de téléchargement et de décodage du logiciel de mise à jour qui pèse 2,5 Mo; pour ma part, je n'ai pas eu d'ennui en utilisant le mode "texte" de Fetch. [GD]
<ftp://bbs.corelus.com/WordPerfectfortheMac/wp35.hqx>
La disparition de Seymour Cray -- Ceci n'est pas strictement lié au monde du Macintosh, mais nous voulons signaler la disparition de Seymour Cray le 5 octobre 1996, des suites de blessures subies lors d'un accident d'automobile. Cray a construit en 1958 le premier superordinateur à transistors et on lui attribue généralement le concept de processeur à jeu d'instruction réduit (RISC) qui est à la base du PowerPC et d'autres microprocesseurs modernes. Même si les entreprises de Cray n'ont pas toujours réussi (Cray Research a été racheté par Silicon Graphics il y a quelques années) il restera probablement pour longtemps une des figures les plus importantes du monde du calcul à haute vitesse. [GD]
<http://www.cnn.com/TECH/9610/05/cray.obit/index.html>
par Adam C. Engst <ace@tidbits.com>
Comme nous l'avons noté dans le TidBITS-297 paru en octobre 1995, la publication de DealBITS était une sorte d'expérience. Nous voulions voir s'il était possible de repenser la façon de faire de la publicité sur Internet et d'en faire une force positive pour l'industrie. DealBITS combinait nos idéaux et notre besoin pragmatique de faire un gagne-pain de TidBITS. Bien que l'expérience fut concluante, jusqu'à un certain point, nous avons découvert que nous ne connaissions pas suffisamment le milieu de la publicité pour faire la percée que nous voulions.
Le problème de base avec DealBITS, c'est que l'énergie dépensée était trop grande par rapport aux gains. Bien que DealBITS n'ait jamais posé de problèmes de rentabilité, il ne constituait pas une utilisation rentable de notre temps, particulièrement celui de Tonya. Ce qui est peut-être plus important encore, c'est que la production bimensuelle de DealBITS n'était pas en elle-même une récompense suffisante pour l'argent rapporté. D'où notre décision de suspendre la publication de DealBITS pendant que nous repensons son concept et son exécution.
Le problème le plus important qu'avait DealBITS était qu'il ne contenait jamais assez de bonnes affaires dans un seul numéro pour en faire quelque chose d'attrayant pour TOUS les utilisateurs de Mac. Au départ, nous pensions, à tort, que le seul fait de ne charger qu'une fraction du prix d'une publicité dans une publication imprimées aurait suffit à attirer nombre de sociétés, au lieu d'avoir à vendre les avantages inhérents de DealBITS. Là nous nous sommes foutus un doigt dans l'&brkbar;il! Il se trouve que démarcher pour vendre de la publicité n'est qu'une autre forme de vente, et que les bons vendeurs sont une race à part. Si nous voulons avoir du succès dans l'avenir, nous devrons trouver un conseiller publicitaire professionnel : le genre de personne qui connaît tout le monde dans l'industrie, qui peut parler le langage des gens de communication, et surtout qui a le temps de courir après les annonceurs. Trouver les annonceurs intéressés n'est d'ailleurs que le début; après cela viennent les efforts concertés pour faire en sorte que l'annonceur fournisse le texte de son annonce et détermine les bonnes affaires à proposer.
Les bonnes affaires étaient une autre sorte de "détail" idéaliste. Chaque publicité devait en quelque sorte proposer une bonne affaire différente de ce qui était proposé ailleurs. L'idée était prometteuse, mais on s'est rendu compte après coup qu'elle éliminait aussi des annonceurs potentiels comme, et surtout, les grosses sociétés. Le problème est que les grosses sociétés ne vendent pas directement leurs produits : elles les vendent surtout par le biais de distributeurs ou d'autres canaux de distribution. Il leur est donc difficile, voire impossible, d'offrir des affaires sortant de la norme. Et sans la participation de ces grosses sociétés, DealBITS manquait de bonnes affaires sur les produits les plus importants. Ceci est une autre chose qu'on devra changer dans DealBITS; nous ne pouvons tout simplement pas nous permettre d'ignorer les grosses sociétés qui ne peuvent nous donner une bonne affaire au risque de s'aliéner leurs canaux de distribution.
Dès le début nous avons réalisé que nous avions à utiliser une automation importante pour que DealBITS soit faisable. Et, pour une large part, il en a été ainsi, mais il y avait un problème que nous avions ignoré. Il s'est avéré que beaucoup de sociétés ne fournissaient pas de publicité cohérente et bien conçue sans aide de notre part. Nous étions certainement prêts à les aider, mais il n'y avait aucun moyen d'automatiser le processus, qui nécessitait au moins une journée de travail pour Tonya à chaque numéro. Le processus d'édition via échanges s'est aussi avéré stressant lorsque les sociétés dépassaient les dates de tombée et sollicitaient un délai supplémentaire. D'un seul coup nous nous retrouvions avec des dates limites critiques deux lundis par mois lorsque DealBITS et TidBITS devaient être expédiés le même jour. Alors que nous étudions ce problème, nous avons toujours à trouver une solution. L'équation semble être binaire : soit nous n'éditons rien et utilisons la technologie (telle qu'une page Web pour soumettre une publicité qui requiert des éléments essentiels et force une taille limite), soit nous mettons la main à la pâte et continuons à tout éditer à la main.
Notre horaire de publication s'est aussi avéré problématique. Nous ne voulions pas une autre date de tombée hebdomadaire en parallèle avec TidBITS, mais un programme bi-hebdomadaire aurait perturbé à la fois la facturation et la prédiction de la date de parution d'un numéro six mois à l'avance dans le cas des réservations. Nous avons finalement décidé de publier les premier et troisième lundis de chaque mois et, bien qu'il semble cohérent, cet horaire s'est avéré déroutant pour les annonceurs, entraînant des dépassements de dates de tombée et le stress supplémentaire mentionné précédemment. Notre impression est que la solution éventuelle réside dans une publication hebdomadaire ou bi-hebdomadaire.
Le dernier problème avec DealBITS est qu'il n'a jamais atteint le nombre de lecteurs dont il avait besoin pour attirer plus d'offres et pour rendre les publicités dans DealBITS encore plus intéressantes. La liste de DealBITS approchait 8 000 à la fin, et entre 1 000 et 3 000 personnes lisaient les numéros via le Web. Nous espérons trouver des moyens pour augmenter ces nombres et il est possible que nous sollicitions des suggestions ou testions des idées via un sondage futur sur le Web.
En conclusion, je pense que DealBITS a réussi en tant que publication. Quand nous avons annoncé la suspension de cette dernière, nous avons reçu bon nombre de messages de la part de nos lecteurs, qui étaient déçu, et de nos annonceurs fidèles, qui étaient assez perturbés. Les lecteurs de DealBITS étaient de bons clients, et nos annonceurs ne voulaient pas perdre le contact avec eux. Small Dog Electronics, qui vend du matériel, des logiciels, et des ordinateurs Mac, a même mis en place sa propre liste informelle pour rester en contact avec les lecteurs de DealBITS (pour joindre cette liste, envoyez un courrier électronique à <donmayer@aol.com>). Maintenant, notre tâche avec DealBITS est de trouver une solution aux problèmes commerciaux et de fignoler les détails des autres aspects de la publication pour qu'elle puisse atteindre tous ses objectifs et ainsi permettre de supporter TidBITS.
par Geoff Duncan <geoff@tidbits.com>
La semaine dernière, un article de Tom Abate dans le San Francisco Examiner a déclenché une avalanche de spéculation, de messages d'agences de presse et de lettres plus ou moins hystériques (comme d'habitude) adressées à TidBITS. La raison? L'article du Examiner semblait annoncer que Ellen Hancock, V.-P. Technologie chez Apple, planifiait de laisser tomber la compatibilité en amont dans les prochaines versions du MacOS.
L'article cite Hancock en ces termes : "Si nous devons choisir entre la compatibilité en amont et de nouvelles fonctions, nous allons choisir les nouvelles fonctions."[TRADUCTION] L'information a été rapportée par les agences de presse puis répétée maintes et maintes fois dans les listes de distribution et dans les nouvelles Usenet, ce qui a donné lieu à la perception générale selon laquelle AUCUN logiciel existant ne tournerait sous MacOS 8.
C'est tout simplement faux, et il n'est pas difficile de comprendre pourquoi. Apple ne ferait qu'aller à sa perte si TOUS les logiciels actuels ne pouvaient tourner sous les nouvelles versions du MacOS. Ce choix serait pire que d'abandonner le MacOS en faveur d'une version de Unix ou de Microsoft Windows. Les développeurs abandonneraient la plate-forme en masse et, un fait encore plus important, les utilisateurs laisseraient tomber Apple en grimaçant de dégoût. Après tout, la raison essentielle qui explique la préférence des utilisateurs pour le Mac, c'est la gamme de logiciels. Si cette gamme ne devait plus fonctionner, le Macintosh perdrait son avantage le plus important.
Alors, qu'est-ce que Apple a dit, en réalité? Fondamentalement, rien de nouveau : les mises à jour incrémentielles du MacOS auront lieu environ tous les six mois et, à mesure que les nouvelles fonctions de Copland seront offertes (le traitement multitâche préemptif, un nouveau noyau, un nouveau système de classement, etc.), quelques programmes Mac devront être mis à jour pour tourner sous le nouveau système d'exploitation. Ce n'est rien de nouveau : Apple a déjà fait des annonces à cet égard au cours de réunions avec les développeurs en 1993, à propos de Copland. Certains types de programmes seront plus problématiques que d'autres, surtout les tableaux de bord et un grand nombre d'extensions, ainsi que les applications qui utilisent des appels système non documentés.
Par le passé, Apple a souvent fait des pieds et des maine pour s'assurer de la compatibilité des applications existantes. Même si ce n'est pas toujours possible, dans certains cas, Apple n'a pas corrigé un bogue particulier ou un comportement non documenté du système parce qu'un programme important n'aurait pu tourner si la correction avait été faite. Le seul changement dans la position d'Apple semble être que la société ne limitera plus le développement de son système d'exploitation en raison d'applications et de logiciels qui recourent à des appels système non documentés ou à d'autres pratiques de programmation problématiques ou hors normes. Apple a adopté cette stratégie auparavant à l'égard de diverses composantes du système d'exploitation (y compris le Finder, le Sound Manager, QuickDraw, etc.), et même si cela déclenche une tempête de protestations au début, le système d'exploitation doit évoluer d'une façon ou de l'autre. Il s'agit d'une méthode éprouvée et, en fait, qui est utilisée par la plupart des autres systèmes d'exploitation, y compris Unix, Windows 95, Windows NT, VMS, etc..
Certains ont spéculé que l'article du Examiner indiquait que Apple prévoyait remplacer les versions futures du MacOS par le BeOS. En autant que je sache, les discussions entre Apple et Be n'ont pas progressé, malgré de nombreuses déclarations élaborées de la part d'utilisateurs du Mac et du système Be (voir TidBITS-343). De plus, Be a déclaré (sans rien promettre) que des versions processeur et multiprocesseur du BeOS pour le Power Macintosh seraient disponibles au début de 1997.
S'il faut tirer des leçons de cet incident (et d'autres incidents semblables touchant Apple et survenus récemment), c'est que les articles techniques de nature générale à l'égard du Macintosh doivent être lus avec un grain de sel. Il ne s'agit pas nécessairement de critiquer les journalistes ou les publications puisque je ne les connais pas et que je ne souhaite pas les dénigrer. Toutefois, le processus suivi par un article de nature générale sur Apple Computer ressemble au cheminement d'un message qu'une vingtaine de personnes se chuchoteront successivement à l'oreille : la plupart du temps, le message entendu par la vingtième personne est très différent de celui soufflé par la première. Dans le cas de la presse, la chaîne comprend les journalistes, les rédacteurs, les journalistes attitrés, les correcteurs d'épreuves, les réviseurs et les correspondants, et la communauté du Macintosh est habituellement le dernier maillon de la chaîne.
par Matt Neuburg <matt@tidbits.com>
La semaine dernière dans TidBITS-347, la première partie de cet article décrivait le logiciel QuicKeys (QK) de la société CE Software, et mentionnait une nouvelle option de la version 3.5 : les déclencheurs de barres d'outils. Nous concluons ici avec une évaluation sérieuse du produit.
Contrainte de création -- Pour que QK soit utilisable, le procédé de création ou de modification d'une action QK doit être simple et pratique. En général, vous voulez consacrer votre temps à l'utilisation de votre ordinateur et pas à la configuration d'un programme qui vous permet de l'utiliser plus facilement. Beaucoup d'actions QK seront des créations impulsives et ponctuelles; si vous êtes en train de copier des images dans l'Album, vous n'automatiserez pas cette action s'il est plus rapide et facile de la faire manuellement.
Néanmoins, les premiers utilisateurs de QK ont dû composer avec les difficultés et la confusion causées par l'interface servant à la création et la modification des actions. Il existe plusieurs types d'actions QK, et le type désiré doit être choisi dans un menu hiérarchique mal structuré. Beaucoup d'actions sont créées et modifiées par le biais de boîtes de dialogue de conception douteuse qui vous mènent souvent à d'autres boîtes de dialogue, toutes modales, qui bloquent le reste de l'écran (y compris les boîtes de dialogue précédentes). (Dans la version 3.5, on peut maintenant déplacer la boîte de dialogue principale [toujours modale] et en modifier la taille, mais puisque les fenêtres situées derrière celle-ci ne sont pas mises à jour, le déplacement de cette fenêtre principale est inutile).
Une fois que vous avez créé une action QK, il n'est pas facile de savoir ce qu'elle fait à moins de l'ouvrir et de la modifier (et voilà ces boîtes de dialogue qui rappliquent!). Vous ne pouvez même pas donner un nom informatif à l'action en question. Dans certains cas, vous pouvez changer son nom, mais vous êtes limités à quelques caractères. Dans d'autres cas, c'est tout simplement impossible. Par exemple, une action qui permet de choisir l'option Fermer dans un menu et une autre qui permet de choisir la même option tout en maintenant les touches Majuscule et Option enfoncées (commande Fermer tout dans le logiciel Nisus Writer) portent le nom Fermer. Vous pouvez inclure un commentaire, mais celui-ci n'est pas affiché dans la fenêtre principale : vous devez cliquer sur l'icône de commentaire d'une action pour pouvoir le lire.
L'assemblage des actions en séquences est encore plus décourageant. Dans l'éditeur de séquences, vous ne pouvez faire glisser une action à la position désirée dans une séquence, et la façon de déplacer cette action à l'aide de la méthode du couper-coller n'est même pas intuitive. Le même problème se pose pour les actions dont le nom n'est pas informatif, et l'absence de commentaires dans l'éditeur de séquences ne fait qu'aggraver cette situation! Je ne comprends pas pourquoi CE ne jette pas un &brkbar;il aux interfaces de programmes qui permettent la création de séquences types d'actions modifiables : FileMaker Pro vient tout de suite à l'idée.
Les séquences QK n'ont jamais bénéficié d'instructions de programmation comme les boucles et les branchements; à l'exception de la possibilité de s'appeler entre elles (ou de s'appeler elle-même indéfiniment), les séquences sont linéaires. Quelques branchements conditionnels plutôt inélégants ont fait leur apparition dans la version 2.1.2 avant d'être améliorés dans la version 3.0. La version 3.5 améliore la commande "Jump" et ajoute une autre instruction de boucle, le "Batch Processor", qui permet de traiter tous les fichiers se trouvant dans un dossier en ouvrant chacun d'eux puis en leur appliquant une séquence d'actions. Notez cependant que cela ne vous aidera pas beaucoup si ce que vous voulez faire à chaque fichier ne nécessite pas son ouverture. Toutes les commandes de branchement restent limitées à ce que QK peut vérifier; elles sont inélégantes et difficiles à utiliser.
OSA, Can You CE? [jeu de mots sur les homophones OSA et "Oh say", ainsi que sur "CE" et "see", les premières paroles de l'hymne national américain]. Petite leçon d'histoire : en 1991 le Système 7 introduit les "Apple Events" qui permettent une communication entre les applications (IAC) qui savent comment les envoyer et les recevoir. En 1992, le Système 7.1 ajoute le "Open Scripting Architecture" (OSA) qui permet de créer des dialectes de macroprogrammation alternatifs opérant sur les Apple Events. Enfin, en 1993, Apple publie son propre dialecte de ce genre : AppleScript.
CE réagit à l'arrivée du Système 7 en incluant dans QK 2.1 une extension (CEIAC [pigé?]) qui permet à QK d'envoyer et de recevoir des Apple Events. Mais des Apple Events bruts sont difficiles à utiliser et une modification importante est apportée vers la mi-93 quand la version 3.0 de QK introduit trois innovations de taille :
Elle remplace CEIAC par QuicKeys Toolbox, une application sans interface tournant en arrière-plan. Cette application réagit entre autre directement à des commandes AppleScript réelles.
Elle rajoute la possibilité d'exécuter des séquences types AppleScript. Ainsi, une action QK peut être à la fois un endroit pour stocker une séquence type AppleScript et un moyen de la déclencher.
Elle inclut son propre dialecte OSA enregistrable. Une application qui exécute des séquences types OSA (telles Frontier, HyperCard ou le Script Editor d'Apple) peut désormais parler le langage de QK. Au lieu de déclencher une action ou une séquence QK précédemment définie, elle envoie à QK une séquence type pour l'action ou la séquence. Ainsi, depuis l'intérieur d'une telle application, on peut tirer parti des possibilités "d'utilisateur invisible" de QK pour lancer des séquences types à partir d'applications qui ne sont pas compatibles avec AppleScript.
Par exemple, j'avais une séquence type AppleScript qui permettait de copier de multiples images depuis QuarkXPress et de les coller dans Microsoft Word; cependant, je voulais que ces images transitent par GraphicConverter pour y faire réduire leur profondeur de bit, et GraphicConverter ne permet pas de créer des séquences types. Ma séquence type traite donc chacune des images en parlant à Quark et Word en AppleScript mais, entre les deux, elle parle le langage de QK pour pouvoir choisir des options de menus et cliquer sur des boutons dans GraphicConverter.
Malheureusement, l'intégration entre QK et les autres dialectes de macroprogrammation n'est pas très bonne, car QK n'accepte pas les variables et il est donc difficile de passer de l'information en amont et en aval.
Par exemple, quand je devais utiliser Pegasus Mail, qui ne permet pas de créer des séquences types, je voulais qu'il télécharge automatiquement vers mon disque dur chaque message de ma boîte aux lettres sur le serveur Novell et puis qu'il efface ce message du serveur. Avec QK, je pouvais sélectionner le message suivant et choisir la commande Sauvegarder, mais à ce point je me retrouvais devant une boîte de dialogue Sauvegarder vide et, QK n'acceptant pas les variables, il était impossible de lui faire entrer un nom de fichier différent pour chaque message ("Temp1", "Temp2", etc.). J'ai donc dû commander QK depuis une autre application de macroprogrammation qui pouvait générer les bons noms de fichier. J'ai choisi HyperCard. Tout fonctionna, mais c'était délicat. Durant chaque itération, HyperCard devait envoyer à QK le nom du fichier suivant; inversement, QK était conscient que tous les messages étaient effacés, (le bouton "Sauvegarder" n'était plus actif), mais il devait prévenir HyperCard d'arrêter la boucle.
Depuis que j'ai écrit cette séquence type, les choses ont bougé, mais pas QK. J'utilise maintenant PreFab Player pour de telles tâches. Player n'a pas d'interface : ce n'est pas un moyen pour l'utilisateur de déclencher directement des actions et des séquences (comme l'est QK) mais il est meilleur comme moyen pour une application de macroprogrammation de commander des applications qui ne permettent pas de créer des séquences types car les commandes qu'il génère sont de types AppleScript ou UserTalk (de Frontier). Ainsi, on peut utiliser sans coup férir les variables et les boucles de l'un ou l'autre de ces dialectes; on n'a nul besoin de transporter de l'information à travers la frontière du dialecte OSA ou de changer de dialecte du tout.
<http://www.tiac.net/prefab/player.html>
CE qui aurait pu être -- Depuis de nombreuses années QK est un vrai battant dans mon écurie Mac; j'y fait appel constamment pour modifier et automatiser le comportement de mon Mac. Un ordinateur, je le dis souvent, est fait pour programmer; ou du moins, c'est l'utilisateur qui devrait contrôler l'ordinateur et non pas l'inverse. QK m'a permis de lutter contre les opérations et les comportements malcommodes, routiniers et répétitifs de certaines applications, qui auraient fini par faire de moi l'automate à la place de l'ordinateur.
QK a longtemps fait partie des utilitaires essentiels pour le Mac. Malgré tout, CE ne semblait pas s'asseoir sur ses lauriers. Les nouvelles versions de QK semblaient toujours être un peu plus polies, un peu plus peaufinées, comme si CE cherchait, tout en continuant à plaire aux utilisateurs actuels, à attirer de nouvelles recrues par une amélioration de la convivialité. Cependant, si on fait exception de la nouvelle fonction de barre d'outils et de la commande "Batch Processor", QK 3.5 n'est finalement qu'une version de maintenance. Il est désolant de croire qu'après un silence de trois ans, CE n'a pu faire mieux que cela. Qu'est-ce que CE a pu faire d'autre entre-temps?
CE aurait pu préciser la nature et la portée de la capacité de programmation de QK. Elle aurait pu améliorer l'architecture de programmation interne de QK en ajoutant des variables et des opérateurs mathématiques, par exemple. À l'opposé, elle aurait pu intégrer davantage QK aux dialectes de macroprogrammation existants. Au lieu de cela, QK n'a pas amélioré sa position comme outil de macroprogrammation indépendant et il a été surpassé par PreFab Player en tant qu'outil de macroprogrammation dépendant de AppleScript ou de UserTalk.
CE aurait pu décider de former et d'aider l'utilisateur à l'aide de manuels améliorés. Au lieu de cela, le manuel, qui dépérit sans cesse depuis la superbe édition de la version 2.0 (écrit par le redoutable Fred Terry), est maintenant mince, laid, mal produit, incomplet et il ne donne presque pas d'information. Toute l'information imprimée a été abandonnée au profit d'une aide en ligne lente, gauche et non-pertinente en format Apple Guide.
CE aurait pu adresser la version 3.5 à un vaste auditoire mais a plutôt décidé de réduire peut-être de moitié sa base d'utilisateurs en la limitant aux machines tournant sous le Système 7.5 et suivants.
CE aurait pu augmenter les capacités de base de QK. Voici quelques suggestions :
Permettre aux branchements conditionnels de QK de "voir" et de vérifier une plus vaste gamme de fonctions d'une boîte de dialogue. PreFab Player peut voir des icônes et lire du texte statique, par exemple.
Permettre à QK de "voir" le contenu d'une liste dans une boîte de dialogue, pour qu'il puisse sélectionner un article spécifique. Voici un exemple : si vous utilisez un logiciel comme MacJanet qui vous permet de vous brancher à un serveur par le biais d'un réseau mais sans avoir à passer par le Sélecteur, vous devez faire afficher une boîte de dialogue, choisir une zone dans une liste, choisir un serveur dans une autre liste, puis cliquer sur OK et entrer vos nom et mot de passe. Les listes de zones et de serveurs en ligne changent constamment, donc vous ne pouvez automatiser cette action tant que QK est incapable de lire les listes.
Permettre à QK de capturer une image de l'écran délimitée par des coordonnés et de comparer cette image à un modèle. Cette fonction permettrait à QK de "voir" et de vérifier des fonctions d'écran graphique qu'il ne peut obtenir autrement. Tempo (un programme de macrocommande rival) et Ivy (une extension [plug-in] Virtual User) possèdent cette fonction.
Permettre la sélection d'un menu autre que celui de QK comme déclencheur. Par exemple, le programme NoDesktopCleanup de Alessandro Levi Montalcini peut intervenir lorsque vous sélectionnez n'importe quelle option d'un menu de n'importe quelle application, faire afficher une boîte de dialogue de confirmation et, si vous cliquez sur Annuler, empêcher l'option sélectionnée d'effectuer sa fonction normale. QK pourrait pousser encore plus loin cette technique en déclenchant une action ou une séquence avant, ou même au lieu, de la réponse de l'application à son propre menu. Ceci pourrait pratiquement rendre n'importe quelle application "connectable".
<ftp://mirror.aol.com/pub/info-mac/gui/no-desktop-cleanup-121.hqx>
Enfin, CE aurait pu apporter quelques vraies améliorations à l'interface de QK. La nouvelle apparence de la boîte de dialogue principale n'est qu'un écran de fumée; l'interface doit être repenser à partir de zéro.
En fin de compte -- QK est toujours aussi essentiel; je ne peut m'imaginer ce que je ferais sans lui. Les utilisateurs de QK qui font tourner le Système 7.5 ou suivant sur leurs machines voudront probablement effectuer la mise à niveau, ne serait-ce que pour profiter des corrections de bogues qui me sont inconnues. Cependant, je crois que les utilisateurs de QK, nouveaux comme anciens, méritaient que la version 3.5 soit beaucoup plus consistante qu'elle ne l'est, surtout après une retraite de trois ans.
<http://www.cesoft.com/quickeys/qkhome.html>
[Nous espérons publier dans un avenir rapproché les essais des principaux compétiteurs de QuicKeys, c.-à-d. OneClick de WestCode Software et KeyQuencer 2.0 de Binary Software. -Adam]
CE Software, Inc. -- 515/221-1801 -- 800/523-7638
Les publications non-commerciales àbut non-lucratif peuvent
reproduire des articles dans la mesure qu'ils sont attribués.
Tout autre doit nous contacter. L'exactitude de nos articles n'est
pas assurée. Caveat lector. Les noms de publications, de
produits et de sociétés peuvent être des marques
deposées.
Pour en savoir plus sur TidBITS: comment s'abonner, ou trouver des anciens numéros, et autres informations utiles, envoyez un message a: <info@tidbits.com>. Autrement, contactez-nous a: <editors@tidbits.com>.
Tous les numéros (en anglais) sont disponibles soit en
utilisant FTP soit sur le Web:
<ftp://ftp.tidbits.com/pub/tidbi
ts/issues/>
<http://www.dartmouth.
edu/pages/TidBITS/TidBITS.html>
Pour rechercher les anciens numéros avec WAIS, utilisez cet
URL avec un logiciel de navigation:
<http://wais.sensei.com.au/searc
hform.html>