Christophe Jacquet — Carnet — Mot-clé : Mac

Je propose depuis un certain temps une disposition de clavier pour Windows adaptée aux claviers Mac, destinée aux utilisateurs de Parallels.

A priori, le défaut de cette solution est que pour composer des caractères spéciaux, normalement produits avec Option/Alt -gauche, il faut obligatoirement utiliser Option/Alt -droite (mappée par Parallels sur la Alt-droite, aka AltGr, d'un PC). Ceci est assez perturbant quand on passe sans arrêt de Windows à MacOS.

J'ai trouvé une solution partielle à ce problème : il est possible sous Windows de remapper des touches, en ajoutant juste une entrée dans la base de registres. Je propose donc d'inverser Alt-gauche et Alt-droite. Cela permettra de composer tous les caractères exactement comme sous MacOS. Par contre, le basculement entre applications Windows devra obligatoirement se faire avec Alt-droite + Tab.

Pour mettre cette idée en œuvre :

• j'ai utilisé le petit utilitaire Windows KeyTweak qui permet d'éditer des remappings de touches et de les enregistrer dans la base de registres,
• ou bien vous pouvez directement importer mon remapping « inverseur » (fichier qui ajoute une clé à la base de registres).

Je suis intéressé par tous les retours.

J'ai mis à jour le pilote de clavier français pour Windows sous Mac, qui fait mon bonheur sous Parallels, mais doit pouvoir être utilisé dans d'autres contextes. Il dispose maintenant de sa page, et on peut télécharger le fichier source pour Windows Keyboard Layout Creator.

Deux changements :

• correction de la touche morte accent aigu (Alt-Shift-1). J'avais par erreur mis Alt-1 dans la version précédente ;
• ajout de la flèche droite « → » (qui me manquait terriblement), désormais accessible par « accent circonflexe » puis « trait d'union »^[1].

It can be a real pain to open files with various character encodings inside TeXShop. Indeed, you basically have to change TeXShop's settings each time.

Hopefully, I recently came across a little-documented feature that allows you to specify the encoding on a per-file basis: you simply add a metadata (a special TeX comment) at the top of the file to set the encoding, and TeXShop will load and save it accordingly. Use:

%!TEX encoding = IsoLatin

for ISO-8859-1 (Latin 1), or:

%!TEX encoding = UTF-8 Unicode

for UTF-8. Be sure to type exactly that, as TeXShop is case-sensitively picky!

Well, that's not bad, but it could be far better:

• why not use the same notation as used by Emacs (and others) : % -*- coding: UTF-8; -*- ?
• why not use standard coding names (iso-8859-1 or latin1 instead of ISOLatin, utf-8 instead of UTF-8 Unicode)?
• why does TeXShop need a metadata in the first place? Why can't it directly use the \usepackage[coding]{inputenc} line?

Gimp et Inkscape fonctionnent sur MacOS X, via X11. Le problème, c'est que dans la configuration par défaut, les clics ne parviennent à une fenêtre que si elle est au premier plan. Il faut donc deux clics, pour, disons, sélectionner un outil : un pour activer la boîte à outils, un pour sélectionner l'outil.

Voici le paramètre à modifier pour mettre en place une configuration plus raisonnable :

defaults write com.apple.x11 wm_click_through -bool true

Dans la série l'ergonomie discutable de MacOS X :

Pourquoi Pomme+Tab parcourt-il les applications, et non les fenêtres, indépendamment des applications ? C'est ce dernier fonctionnement qui est implémenté sur Windows (et autres), et je le trouve bien meilleur. En effet, il me semble bien plus pertinent de raisonner sur des fenêtres, qui correspondent souvent à des documents, donc des objets de l'espace mental de l'utilisateur, que sur des applications, qui sont du domaine de la machine.

Par exemple, si j'ai deux documents OOo Writer et un document OOo Calc ouverts, pourquoi puis-je facilement basculer entre le document Writer courant et le document Calc, mais pas facilement à égalité entre les trois documents ? Du point de vue utilisateur, je trouverais logique que les trois documents soient strictement au même niveau...

Lorsque Eclipse a accès au code source des classes (donc notamment des classes de la bibliothèque standard), il propose des fonctionnalités intéressantes : navigation dans le code (pour aller voir comment sont codées les API !), reprise du nom (souvent significatif) des paramètres formels (au lieu de arg1, arg2, etc.) lorsqu'on implémente une interface...

Malheureusement, cela ne fonctionne pas par défaut sur MacOS X, car le code source des classes Java n'est pas installé ! Il faut l'installer en plus. Il se trouve alors dans /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/src.jar, mais Eclipse sait le trouver tout seul.

Mon employeur m'a équipé depuis la semaine dernière d'un tout nouveau MacBook Pro. C'est à la fois la curiosité, l'attrait pour OS X, ainsi que la bonne réputation du matériel qui m'ont fait préférer un Mac sous OS X à un PC sous Linux (ou Windows). En vrac, mes premières impressions :

• l'interface est vraiment très belle. Un peu déroutante certes, mais je la trouve agréable, et on s'y fait vite. De plus, ce n'est pas du tout souris comme j'aurais pu le craindre : la plupart des fonctions ont un raccourci clavier ;
• le clavier n'est décidément pas standard, ce qui est un peu embêtant, surtout en environnement hétérogène. Ceci dit, je suis content car il y a une touche morte pour l'accent aigu :-) ;
• l'importation de mes e-mails depuis KMail vers Mail.app est relativement aisée en utilisant le script adapté. Attention, il faut supprimer les espaces dans les noms de dossiers avant de lancer ce script ;
• déception en revanche en ce qui concerne la synchronisation de mon Palm : les catégories ne sont pas conservées dans iCal. C'est pour moi rédhibitoire : j'attends de trouver une solution ;
• l'accès aux partages SMB est de qualité très moyenne : fréquents plantages du Finder, en particulier lorsque la connexion réseau disparaît. Il m'a été impossible de le tuer, même avec un kill -9 ou en éteignant la machine avec halt (il va sans dire que l'extinction de la machine par le GUI est dans ce cas inopérante) ;
• l'environnement en ligne de commande est bien fourni dans sa configuration par défaut, avec notamment emacs, ssh, cvs, etc. Par contre, Subversion manque à l'appel ! Il faut l'installer à la main.

Kit de survie

J'ai très rapidement installé les programmes suivants :

• la distribution MacTeX, qui comprend à la fois une version de teTeX, l'éditeur TeXShop et d'autres outils, notamment LaTeXiT, qui permet d'insérer des équations TeX dans tous types de documents. Tout est bien configuré par défaut : j'ai tout de suite pu compiler ma thèse sans souci pour tester l'installation ;
• l'éditeur de textes Smultron, qui n'a visiblement pas à rougir de la comparaison avec Kate ;
• comme sous d'autres plate-formes, les classiques Firefox et VLC.