Bon aujourd'hui
J'ai un petit truc à faire, le genre qui devrait prendre 30 minutes. Mais pour m'en sortir je dois déboguer (le coup des console.log et attendre 1min+ pour compiler & redémarrer c'est pas viable, j'ai fait ça les derniers mois mais j'en peux plus).
Je veux résoudre le problème des touches flèches et ENTER qui ne marchent pas dans le débogueur chrome (ce depuis le début, seulement sur ma machine) car ce machin permettrait au moins de me faciliter un peu la vie quand le problème est du côté Javascript. Après tout j'ai beau essayer depuis des mois de m'en accomoder, c'est ultra impratique et si je ne peux pas appuyer sur ENTER pour exécuter un code javascript dans la console parfois c'est vraiment inutilisable.
J'essaie plein de trucs, genre comprendre les scancodes, voir comment est géré l'input dans la page de l'inspecteur mais c'est trop compliqué et minifié. Je pourrais aller voir le code source de Chromium Embedded Framework mais je laisse cette solution ultime pour plus tard.
J'essaie de me connecter au débogueur à partir de mon Mac sur le même network mais impossible. Le débogueur n'autorise que les connexions locales pour des raisons de sécurité.
J'apprends ce qu'il faut de ssh (mais vraiment juste ce qu'il faut) pour ouvrir un tunnel SSH et permettre de me connecter depuis le Mac au débogueur. Plein d'emmerdes, notamment le fait qu'il me dit en boucle qu'il n'a pas l'accès au port 22. Je lis consciencieusement la page man de ssh, sûr qu'il y a une erreur de syntaxe mais non. Je lis un tuto, puis un 2ème plus en détail (pour rien du tout), ensuite en tombant sur un post sur stackoverflow ça veut juste dire que mon serveur SSH n'est pas démarré. Bref sur le Mac même problème de touches qui ne marchent pas.
Je réfléchis, je me dis que si le SEUL problème est ça c'est probablement parce que mon collègue a un clavier Japonais qui aurait des scancodes différents. Je remets mon OS en Japonais et rigoureusement la même configuration clavier. Rien à faire.
Je trouve un site qui permet de comparer les scancodes tels qu'ils sont dans mon browser avec ceux de mon collègue chez qui ça marche(tm). Aucune différence.
Je me dis "bon je vais rebuilder le client pour ma machine", après tout ce sont des binaires précompilés qui étaient sur le git.
Evidemment impossible de recompiler. Il ne trouve pas gtk/gtk.h. Bien sûr, sur ma machine il y a GTK2 et GTK3 installés. Ce machin pourrait être explicite sur la version dont il a besoin. Je lis le README, aucune mention du fait même qu'il y ait besoin de GTK. Sur le site web rapidement non plus.
J'abandonne temporairement, mon collègue me dit qu'il y a des binaires précompilés de CEF. J'essaie ça. Au final je comprends que ce qu'il voulait me faire faire c'est juste utiliser l'appli d'exemple du CEF comme un autre browser pour voir si à partir de là ça marche. Je suis extrêmement dubitatif mais m'exécute.
Il se trouve que ça marche ainsi. Ca ne résoud pas vraiment LE problème mais ça me permet d'utiliser le débogueur en tous cas. Je vais mettre ça sur le compte du fait qu'on utilise une vieille version du CEF et qu'un Chrome récent ne fonctionne peut être pas avec. Après tout c'est "l'avantage" de Linux : pas de mises à jour automatiques, donc les autres dévs ne sont probablement pas à jour (mon collègue n'est que 3 versions de Chrome en retard ceci dit...).
Je voulais vérifier cette hypothèse en essayant la dernière version du client et en voyant si le problème se reproduit, mais le dernier ne trouve pas un certain .so sur mon système. J'ai la flemme, tant pis.
Bon maintenant je peux commencer ma journée, mon travail, à 5h du soir ! Si j'étais consciencieux bien sûr je devrais faire des heures supp pour compenser ça mais j'ai déjà une profonde envie de pleurer tellement je m'ennuie et n'aime pas être au milieu de la mer(de) comme ça que franchement bof.

Mais c'est vrai qu'au fond, régler son workflow, comprendre ce qu'on fait, c'est essentiel pour faire son travail. Il ne devrait pas y avoir de zone d'ombre, en tous cas dans la partie dans laquelle tu travailles.