Discussion:Implémentation selon le système d'exploitation
Le tableau mélange des éditeurs de pilotes et des logiciels genre AutoHotKey qui travaillent sur une autre couche (plus en amont si j'ai bien compris). Or on est parti du principe que l'on faisait un pilote, afin qu'il puisse in fine être inclus de manière standard. M'est avis que les autres lignes sont en trop.Orel'jan 6 mars 2008 à 08:20 (CET)
- On part bien du principe qu'on fait un pilote, mais il ne faut pas oublier qu'il y a toujours le soucis des droits d'installation. Parce que d'ici à ce que ce soit intégré de base dans Windows, il y aura toujours des gens qui ne sont pas administrateur de leur poste, et pour ces gens là il faut trouver une solution. Une solution possible étant l'utilisation d'outils tel que AutoHotkey, d'où leur présence dans le tableau. Crako 6 mars 2008 à 11:14 (CET)
- J'entends bien, mais je pointais le fait que le produit final doit être installable en tant que pilote, c'est-à-dire AHK et al d'accord, mais en tant que béquille pour ceux qui n'ont pas la main sur leur ordi, pas pour utiliser les possibilités suppérieures. Enfin c'est comme ça que je le vois.Orel'jan 7 mars 2008 à 08:44 (CET)
- Je ne connais pas bien les possibilités de AHK, c'est d'ailleurs le but de ce tableau d'éclaircir ce point. Par contre je pense que des outils comme AllChars peuvent être utiles pour des usages spécifiques, même pour une personnes qui utilise le pilote. Ça sort du cadre du projet, mais disons que ça serait plus pertinent de dire aux gens qu'on a pas voulu « polluer » notre pilote avec des trucs inutiles pour 99% des gens, et que les 1% restant peuvent utiliser soit un logiciel de table de caractères, soit un logiciel de type compose. Je préfère nettement le deuxième. Par exemple, est-ce qu'une personne qui fait de la typographie avancée au point d'utiliser régulièrement des simboles comme le double dagger trouvera vraiment contraignant d'utiliser un mécanisme type compose ? Idem pour les personnes ayant besoin de symboles mathématiques. Il faut bien garder à l'esprit que de toute façon on a jamais que 47*4 places sur le clavier, et qu'il y a beaucoup plus de symboles à caser si on suit les envies des mathématiciens espérantistes roumano-hongrois typographes :)
- Ok pour presque tout Orel'jan 7 mars 2008 à 10:56 (CET)
- Je ne connais pas bien les possibilités de AHK, c'est d'ailleurs le but de ce tableau d'éclaircir ce point. Par contre je pense que des outils comme AllChars peuvent être utiles pour des usages spécifiques, même pour une personnes qui utilise le pilote. Ça sort du cadre du projet, mais disons que ça serait plus pertinent de dire aux gens qu'on a pas voulu « polluer » notre pilote avec des trucs inutiles pour 99% des gens, et que les 1% restant peuvent utiliser soit un logiciel de table de caractères, soit un logiciel de type compose. Je préfère nettement le deuxième. Par exemple, est-ce qu'une personne qui fait de la typographie avancée au point d'utiliser régulièrement des simboles comme le double dagger trouvera vraiment contraignant d'utiliser un mécanisme type compose ? Idem pour les personnes ayant besoin de symboles mathématiques. Il faut bien garder à l'esprit que de toute façon on a jamais que 47*4 places sur le clavier, et qu'il y a beaucoup plus de symboles à caser si on suit les envies des mathématiciens espérantistes roumano-hongrois typographes :)
- J'entends bien, mais je pointais le fait que le produit final doit être installable en tant que pilote, c'est-à-dire AHK et al d'accord, mais en tant que béquille pour ceux qui n'ont pas la main sur leur ordi, pas pour utiliser les possibilités suppérieures. Enfin c'est comme ça que je le vois.Orel'jan 7 mars 2008 à 08:44 (CET)
Je viens de passer xkb en vert (de admin seul => admin/user). En effet il est possible d'utiliser une simple commande "xkbcomp xkb.conf :0" avec un fichier xkb.conf adéquat en tant qu'utilisateur pour changer son clavier, sans avoir besoin des droits admins. On peut même automatiser cette commande en début de session X11 si nécessaire (par exemple dans le .xsession). --Nbrodu 6 mars 2008 à 10:54 (CET)
- Merci, il me semblait bien avoir lu qu'on pouvait, mais je n'était pas sûr. Ça permettra sans doute d'abandonner l'outil xmodmap vu qu'il n'apporte rien par rapport à xkb Crako 6 mars 2008 à 11:14 (CET)
Des infos sur Compose avec xkb et xmodmap http://club.mandriva.com/xwiki/bin/view/KB/XKeyboardCompose?language=fr
- Il semble que GTK soit en passe de se rapprocher de xorg pour ce qui est de la gestion de compose. CF : http://blogs.gnome.org/simos/2008/03/05/testing-the-updated-im-support-in-gtk/ Avec une « table » Compose de 5000 caractères : http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=blob_plain;f=nls/en_US.UTF-8/Compose.pre
Portée
Orel'jan, peux-tu préciser ce que tu veux dire par portée ? J'aimerais remplir la case pour mac, mais je vois mal quoi y mettre actuellement. Gaëtan 7 mars 2008 à 09:26 (CET)
- J'entends par portée la longueur (c'est pas mieux) des changements qu'entraîne l'utilisation d'un de ces programmes. Un éditeur de pilote va modifier le pilote, donc chaque disposition clavier prise séparément (idéal pour ce que l'on cherche à faire). Un émulateur genre AHK va agir sur toute frappe au clavier sans distinction de la langue utilisée. Par exemple, si l'on veut émuler pour le français les guillemets "→« ou "→» suivant le contexte, l'émulateur va le faire également pour toutes les dispositions clavier, donc problème si l'utilisateur a une deuxième disposition clavier. Orel'jan 7 mars 2008 à 10:56 (CET)
Esthétique et lisibilité
Ne pourrait-on pas mettre des traits horizontaux — au moins entre les différents types de systèmes d’exploitation — afin de rendre ce tableau plus lisible ?