Ce n’est pas évident. AutoHotKey (sur lequel PKL est basé) et WinCompose utilisent tous les deux le même mécanisme d’injection de touches, ils vont donc être évalués l’un après l’autre, mais il n’y a rien dans l’API Windows pour décider lequel passe en premier. Tu as donc véritablement une chance sur deux que ça déconne bizarrement, et on ne peut rien y faire à ma connaissance.
Cela dit, je ne suis pas du tout opposé à intégrer à WinCompose des features inspirées d’autres logiciels, et j’ai toutes les briques pour émuler parfaitement ce que fait PKL. Fais-moi signe si tu penses que ça peut valoir le coup.
D’ailleurs, à l’origine, WinCompose utilisait AutoHotKey, mais j’avais beaucoup trop de problèmes de performance, d’ergonomie (les applications graphiques en AHK sont calamiteuses) et surtout de compatibilité, notamment avec les applications GTK+.
[^] # Re: bépo
Posté par Sam Hocevar . En réponse à la dépêche Sortie de WinCompose 0.7.5. Évalué à 2.
Ce n’est pas évident. AutoHotKey (sur lequel PKL est basé) et WinCompose utilisent tous les deux le même mécanisme d’injection de touches, ils vont donc être évalués l’un après l’autre, mais il n’y a rien dans l’API Windows pour décider lequel passe en premier. Tu as donc véritablement une chance sur deux que ça déconne bizarrement, et on ne peut rien y faire à ma connaissance.
Cela dit, je ne suis pas du tout opposé à intégrer à WinCompose des features inspirées d’autres logiciels, et j’ai toutes les briques pour émuler parfaitement ce que fait PKL. Fais-moi signe si tu penses que ça peut valoir le coup.
D’ailleurs, à l’origine, WinCompose utilisait AutoHotKey, mais j’avais beaucoup trop de problèmes de performance, d’ergonomie (les applications graphiques en AHK sont calamiteuses) et surtout de compatibilité, notamment avec les applications GTK+.