Convertir un pdf en cbr

#!/bin/sh
 
mkdir "`basename \"$1\" .pdf`"
cp "$1" "`basename \"$1\" .pdf`/bd.pdf"
cd "`basename \"$1\" .pdf`"
pdftohtml -nodrm bd.pdf
 
for f in *.jpg
do 
    convert -compress JPEG2000 -quality 75 -verbose $f out.jpg; 
    cp out.jpg $f; 
done
rm *.html *.pdf out.jpg; 
 
rar a "../`basename \"$1\" .pdf`.cbr" *; 
cd ..; 
rm -rf "`basename \"$1\" .pdf`"

Il faut que pdftohtml, imagemagick et rar soient installés pour que le script fonctionne.
Sur un système à base de Debian :

sudo apt-get install poppler-utils imagemagick rar

Réaliser un montage à la DropBox pour Hubic sur linux

Avertissement :

  • Je n’ai pas d’action chez OVH et ne suis lié à eux en aucune manière.
  • La méthode donnée ici expose vos logins/mots de passe hubic dans un fichier en clair et monte votre compte hubic pour tous les utilisateurs.Ne suivez les instructions ci-dessous que si vous savez ce que vous faites.

Hubic est la solution de stoquage d’OVH.

Elle offre 25Go gratuits et des options payantes très compétitives.

Cela est parafait mais présente tout de même un problème : leur client linux est une horreur.

Si, comme moi, vous voulez auto-synchronizer vos 25Go sur votre système de fichier, à la manière d’un Dropbox ou d’UbuntuOne, voici la manière dont je procède :

L’astuce est de monter un répertoire webdav en utilisant davfs2, et de synchroniser votre répertoire davfs avec le système de fichiers local.

Grâce à l’analyse de GR sur les messages transités par le client hubic, j’ai légèrement modifié son script pour qu’il fasse le montage lui-même.

Étape 1 : Installer davfs2

sudo apt-get install davfs2

Étape 2 : Monter le répertoire webdav

Télécharger le script de montage sur github.

sudo mkdir /mnt/hubicdav
sudo chmown user /mnt/hubicdav
sudo chmod +x hubic.py

Vous pouvez alors tester votre montage.

sudo python hubic.py yourhubiclogin yourhubicpassword /mnt/hubicdav

Si tout va bien, vous devriez retrouver vos fichiers montés sur hubic dans le répertoire /mnt/hubicdav/

Si c’est le cas, on peut automatiser le montage au démarrage de la machine :

sudo cp hubic.py /usr/local/bin/
sudo vim /etc/init.d/hubic

Dans ce fichier, lancez-juste le montage :

#!/bin/sh
 
python /usr/local/bin/hubic.py yourhubiclogin yourhubicpassword /mnt/hubicdav

Sauvegardez le fichier et appliquez quelques précautions :

sudo chmod 600 /etc/init.d/hubic
sudo update-rc.d hubic defaults

Étape 3 : Synchroniser votre montage webdav avec le système de fichiers local

Nous utiliserons unison mais d’autres outils peuvent mieux convenir à vos besoins (lsyncd, rsync etc.)

mkdir ~/hubic
sudo apt-get install unison
vim ~/.unison/hubic.prf

Voici le contenu de mon fichier hubic.prf :

root = /mnt/hubicdav/
root = /home/user/hubic

ignore = Path .Trash-*
ignore = Path lost+found

Testez votre fichier de config hubic :

unison hubic

Au premier lancement, unison va afficher différents messages d’alertes. Répondez juste aux questions posées.

Enfin, il reste à automatiser la synchronisation.

Un exemple d’entrée dans la crontab pour un lancement toutes les 30 minutes.

*/30 * * * *   unison -batch -auto hubic

Ma configuration x264

Pour l’instant, voici la configuration x264 que j’utilise pour ripper mes DVDs et avec laquelle j’obtiens les melleurs résultats :

ref=2:me=umh:b-adapt=2:weightb=0:vbv-maxrate=9500:vbv-bufsize=9500:subme=9:trellis=2:psy-rd=1|0.1

J’utilise un CRF20.

handbrake x264 settings for DVD rip

[Edit]: Une aide précieuse sur les options du codec x/h264 : https://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping

Injecter JQuery – bookmarklet

Si vous voulez injecter jQuery dans une pages, vous pouvez utiliser le bookmarlet suivant.

Il vous suffit de glisser/déposer le lien suivant vers votre barre de raccourcis : Injecter jQuery.

NB: jQuery est injecté sans utiliser le mode de compatibilité (taper « jQuery » à la place de « $ » est trop pénible pour moi).

Une fois jQuery injecté, vous pouvez commencer à jouer avec la console de votre navigateur. Par exemple, sur google news,

$('.esc-layout-article-cell h2 a span').each(function(){ console.log($(this).text()); });

va scraper les titres des news de la page.

Installer une imprimante LBp7200Cdn sur Ubuntu 11.10 64bits


La principale source de documentation sur l’installation d’un driver de type CAPT peut être trouvée ici

J’ai suivi les instructions données sur la page ci-dessus mais sans succès. Le problème vient du fait que la version 64 bits des drivers CAPT 2.3 ne fonctionne pas sous Ubuntu 11.10.

Après avoir bataillé plusieurs heures à créer des liens symboliques vers les librairies 64 bits et me rendre compte qu’AppArmor bloquait les drivers, j’ai finalement trouvé une solution bien plus simple.
Cette solution, c’est d’utiliser les drivers 2.2 du dépôt de Michael Grutz.

$ sudo add-apt-repository ppa:michael-gruz/canon

Le dépôt n’inclue pas de version pour oneiric. Il vous faut éditer votre fichier /etc/apt/sources.list.d/michael-gruz-canon.list et remplacer oneiric par natty.

Ensuite :
1- Installer le pilote

$ sudo apt-get update
$ sudo apt-get install cndrvcups-common cndrvcups-capt

2 – Redémarrer Cups

$ sudo service cups restart

3 – Ajouter l’imprimante à Cups

$ sudo /usr/sbin/lpadmin -p PRINTERNAME -P /usr/share/cups/model/CNCUPSLBP7200CCAPTK.ppd -v ccp://localhost:59787 -E

Le fichier ppd donné ici correspond à la LBP7200Cdn. Si vous avez une imprimante différente, il vous faut utiliser le ppd correspondant (cf le lien donnée en début d’article ou jetez un oeil au contenu de votre répertoire /usr/share/cups/model.

4 – Lier l’imprimante Cups au démon canon

$ sudo ccpdadmin -p PRINTERNAME -o net:THE_PRINTER_IP

La commande donnée ici est pour une imprimante réseau. Si vous installez une imprimante USB, remplacez la partie net:IP par votre port d’impression usb : /dev/lp0

5 – Démarrer le démon Canon

$ sudo /etc/init.d/ccpd start

Vérifier que le démon est correctement démarré :

$ sudo /etc/init.d/ccpd status

Vous devez obtenir quelque chose comme

/usr/sbin/ccpd: 15263 15258

avec 2 processus.

Vous devriez maintenant pouvoir imprimer. Si tout s’est bien passé, vous pouvez ajouter le démon canon au démarrage de votre système :

$ sudo update-rc.d ccpd defaults 90

PS : J’arrive maintenant à miprimer à partir de mes systèmes Ubuntu. Par contre, le même procédure ne fonctionne pas sur ma distribution CrunchBang.
Tout semble se passer correctement mais les jobs d’impression tournent dans le vide.

Si quelqu’un a la solution pour une installation sous Debian Squeeze, je suis preneur.

Hotot sur CrunchBang stater


Le repository d’Ubuntu fonctionne très bien chez moi.

Ajoutez

deb http://ppa.launchpad.net/hotot-team/ppa/ubuntu maverick main

à votre /etc/apt/sources.list

Ensuite

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys A29228DD41011AE2
$ sudo apt-get update
$ sudo apt-get install hotot

Gardez vos 2 barils de Mootools, je garde mon baril de jQuery

x.tra

Alors que l’on m’assignait à un nouveau projet à mon nouveau travail, la question du choix du framework javascript à utiliser s’est posée. Mes collègues sont habitués à Mootools et notre talentueuse intégratrice HTML avait inclus du code Mootools dans son découpage.

Le choix s’est donc naturellement porté vers ce framework.

En bon mono-utilisateur de jquery que j’étais, j’ai pris la chose comme une nouvelle opportunité d’apprendre quelque chose. C’est donc avec un certain enthousiasme que je m’y suis attelé.

Après quelques semaines, je commence à avoir mon opinion sur les qualités relatives de Mootools et Jquery. Je suis encore un utilisateur novice et il est très probable que mon avis continue à évoluer.

Parce que je suis un peu feignant, cet article s’organisera comme un commentaire de celui d’Aaron Newton of Clientcide, qu’il a posté sur http://jqueryvsmootools.com/

Vous l’aurez compris en voyant le titre de mon article, mon avis diffère quelque peu du sien.

2 bons frameworks

Jquery et Mootools sont deux frameworks de qualité. Au jeu du « qui utilise quoi », si jQuery affiche une liste très impressionnante de références, Mootools affiche une liste plus réduite mais peut s’enorgueillir de quelques références prestigieuses qui suffisent à convaincre de son sérieux, comme le w3c, vimeo ou netvibes.

Je suis évidemment d’accord avec Aaron Newton sur ce point : aucun des deux n’est un mauvais choix.

The mottos say it all

En effet, les devises en disent long.

[..]Si vous allez sur le site de Jquery, voici ce qui est dit en haut page :

jQuery est une librarie rapide et compacte qui simplifie le parcours d’un document HTML, la gestion des évènements, l’animation et les interactions Ajax pour un développement web accéléré. jQuery est conçu pour changer la manière dont vous écrivez du javascript.

…et si vous allez sur celui de MooTools, voici ce que vous trouverez :

Mootools est un framework javascript compact, modulaire et Orienté-Objet, conçu pour le développeur Javascript de niveau intermédiaire à avancé. Il vous permet d’écrire du code puissant, flexible et compatible multi-navigateurs grâce à son API élégante, bien documentée et cohérente.[..]

Vous ne trouvez pas qu’une des devises se la pète un peu plus que l’autre ? Sérieusement ?…

« .. conçu pour le développeur Javascript de niveau intermédiaire à avancé.».. .

L’important ici n’est pas que cela soit vrai ou non (personnellement, je considère que Mootools est tout à fait utilisable par un débutant). Ce qui est important, c’est que l’équipe de Mootools s’adresse à ceux qui se considèrent comme des développeurs confirmés.

Aaron va même plus loin dans ce sens, en, si je résume, considérant que « si vous être intéressés par Javascript et ce qui le rend intéressant, puissant et expressif, alors [..] Mootools est le meilleur choix ».

Je suis en total désaccord avec ce dernier point. En fait, je pense même qu’au contraire, si vous aimez le javascript, vous ne voulez pas utiliser Mootools. Mais nous y reviendrons plus tard lorsque nous aborderons le modèle objet tel que Mootools le conçoit.

The Learning Curve and The Community

Effectivement, la communauté jQuery est bien plus importante que celle de Mootools. L’auteur oublie sur ce point un effet important : Plus votre communauté est importante, plus vous avez de bugs remontés, plus vous avez de développeurs pour les corriger et améliorer le code, plus vous avez de contributeurs qui développent et partagent des plugins.
Sur la stabilité, la fréquence et l’importance des releases, là encore, jQuery a une énorme avance sur Mootools.

Un example : Peut-être n’ai-je pas de chance mais à peine quelques jours après avoir commencé à utiliser Mootools, je suis tombé sur un bug gênant. Sur la version 1.3.1.1 de Mootools More, le Form validation ne fonctionne pas sur un contrôle select. Essayez simplement d’implémenter un callback sur l’évènement elementFail sur un contrôle select et vous ne recevrez jamais rien dans votre variable element.

Le bug est référencé et corrigé sur le repositorygithub : https://github.com/mootools/mootools-more/commit/358378c5b mais toujours pas dans la version officielle en téléchargement.

What Javascript is Good For

L’auteur nous offre ici une approche succinte du modèle objet prototypal utilisé par Javascript et conclut que “la mauvaise nouvelle, c’est que le Javascript pur ne rend pas ces choses puissantes ni utiles ni accessibles”.

Hein ? Pardon ?

OK, je suis d’accord ici aussi sur le fait que le modèle prototypal est très (trop) souvent méconnu des développeurs. L’excellent article de Steve Yegge sur le sujet et “Javascript, the good parts” du non moins excellent Douglas Crockford, sauront éclairer le curieux sur ces aspects peut-être méconnus de l’approche choisie par Javascript.

Mais comment peut-on décemment soutenir que le langage ne rend pas l’utilisation de ces concepts utile ou accessible ?

Voici comment déclarer un objet en javascript:

var my_object = {
	property: ‘a property’,
	method: function(){
		alert(‘Hello World’);
	}
};

Et voici comment hériter de cet objet:

var tmp = function(){ };
tmp.prototype = my_object;
var my_herited_object = new tmp();

OK, je suis un peu de mauvaise foi. Le dernier code n’est pas forcément des plus évidents. Mais en quoi Javascript le rend-il inutile ou inacessible ?

Mootools makes Javascript itself more fun

Aaron nous explique ici que Mootools s’attache à améliorer Javascript, à le rendre “tel qu’il devrait être”.

D’une part Mootools étend les prototypes des types natifs Javascript pour leur apporter des fonctionnalités manquantes.

Rappelons juste ici que les augmentations apportées à Element servent essentiellement à la traversée et à la manipulation du DOM, domaine où jQuery excelle.

Les autres “améliorations” apportées aux types natifs comme Array ou String sont certes pour au moins certaines les bienvenues, mais ne sont pas pour la plupart l’apanage de Mootools.

JQuery aussi inclue des fonctions manquantes, sans pour autant les intégrer au prototypes natifs.

Enfin, Mootools propose son fameux concept de Class.

L’auteur nous affirme que Mootools n’a pas pour but ici d’introduire un principe objet par classe classique en javascript mais de simplifier l’utilisation du modèle prototypal.

Mais bien sûr. Et la marmotte

Dans ce cas, j’ai une question simple : Pourquoi appeller un object/domaine de nom destiné à simplifier l’utilisation du modèle d’objet prototypal du nom du modèle concurrent ?

En pratique, l’utilisation des Class Mootools est clairement un mimétisme d’un modèle classique en Javascript.

En admettant que la volonté des développeurs de Mootools ait été de faciliter l’utilisation du modèle prototypal, le nom utilisé et son fonctionnement ne peuvent que conduire à la confusion chez le développeur.

J’aime Javascript pour, entre autre, son approche prototypes. C’est parce que j’aime le Javascript que je n’ai pas besoin du système de Class de Mootools.

jQuery ne fournit pas de « modèle d’héritage » pour une bonne raison: il est déjà inclus dans Javascript et fonctionne très bien.
La couche additionnelle apportée par Mootools prête à confusion et me paraît _comme il me semble elle devrait paraître à tout développeur Javascript_, contre-naturelle.

jQuery makes the DOM more fun

Encore un sophisme redondant de l’auteur. jQuery ne serait qu’une “boîte à outils” destiné uniquement à la manipulation du DOM, contrairement à un “véritable framework”, plus abstrait et noble qu’incarnerait Mootools.

Le fait est que cela est en grande partie faux.

La différence est que jQuery s’occuppe de choses utiles. Même si, grâce notamment à node.js, on commence à trouver du Javascript hors du browser, le fait est que l’énorme majorité du code Javascript est actuellement interprété par les navigateurs.

Et la manipulation du DOM est, effectivement, un point très important pour le développeur.

Mais réduire jQuery à cela est mensonger. La couche Ajax, les fonctions utilitaires dont nous avons déjà parlé ou le traitement de callbacks par lots introduit par la version 1.5. sont autant de points qui n’ont pas de rapport direct avec le DOM.

Anything You Can Do I Can Do Better

Passons ce chapitre où l’auteur tente de nous convaincre sans aucun argument que le spectre de Mootools est plus large que celui de jQuery.

J’ai déjà indiqué que je considérais la partie soit-disant spécifique à Mootools comme une surcouche inutile à Javascript.

Mootools Lets You Have It Your Way

Passons là aussi.

Je ne conçois pas qu’on veuille mimer le fonctionnement de Mootools.

Sur la manipulation du DOM, Mootools est incohérent et verbeux.
Sur l’utilisation des classes, tout ceci peut être fait de manière plus simple et plus propre en Javascript natif.

Chaining as a Design Pattern

Où l’on nous explique que l’on peut accéder aux propriétés d’un objet renvoyé par une fonction. Merci, c’est gentil, on le savait déjà.

Reusing Code with JQuery

Ici encore, on cherche à nous faire croire que parce qu’on utilise jQuery, on ne peut que se cantonner à manipuler le DOM.

Désolé Aaron, mais je crée, utilise et hérite des objets dans mon code Javascript. Et tout cela sans Mootools.

Un mot sur ce “qui rend facile pour n’importe qui d’écrire un plugin jQuery – ce ne sont que de simples fonctions”.

Rappelons juste qu’au contraire d’un langage comme PHP, en Javascript, une fonction hérite d’Object, que nous pouvons librement définir et utiliser des objets en son sein ou d’autres fonctions.
Parce que les fonctions sont aussi des clôtures, elles ont accès à l’ensemble des données accessible depuis leur domaine de définition.
Il n’y a pas de limite à la complexité possible d’une fonction. En fait, la totalité du framework jQuery (et oui, j’utilise ce terme à dessein), est défini dans une unique fonction.

Le point sur jQuery UI me semble lui -aussi hors de propos. La manière dont jQuery UI est inclus dans jQuery n’a rien n’à voir avec une quelconque limitation de jQuery. Il s’agit juste d’un choix des développeurs de jQuery UI.

Rappelons tout de même un principe essentiel : Tout ceci n’est au final que du javascript. Tout le monde est libre d’étendre ce qui lui chante de la manière qui lui plaît.

Reusing Code with Mootools

Un mot d’abord sur l’extension des prototypes natifs.

Personnellement, je suis partagé sur la question.

Evidemment, je trouve (trop) dangereux de modifier/étendre le comportement d’objets partagés par l’ensemble du contexte d’exécution et donc y-compris probablement par d’autres scripts et librairies (comme par exemple Google Analytics ou Maps).
D’un autre côté, je comprends la tentation d’avoir sous la main une méthode trim directement accessible depuis n’importe quel String.

Utiliser un prototype hérité n’est pas une solution puisqu’elle impliquerait des casts pénibles.

L’alternative, comme mon choix actuel, est l’utilisation de fonctions externes au type concerné, comme le fait jQuery avec jQuery.trim() par exemple.

Evidemment, on perd en qualité syntaxique en écrivant jQuery.trim( my_string ) plutôt que my_string.trim() mais on se protège au moins d’un codeur fou qui aurait décidé d’utiliser String.trim pour retourner l’heure courante.

Sur l’utilisation des sélecteurs CSS

Une question me tarraude : A quoi sert la fonction $ dans Mootools ?

Elle n’est qu’un alias de document.getElement ById, n’utilise pas de sélecteur CSS et introduit une confusion certaine avec $$.

Rappellons $$(‘#myid’)[0] donnera exactement le même résultat que $(‘myid’).
Est-ce que le but de $ est réellement d’économiser 4 caractères ?

J’en viens à me demander si le but réel de la présence de la fonction $ n’est pas d’entrer en conflit avec d’autres frameworks utilisant cette fonction (jQuery et Prototype).

 

Sur l’utilisation des Domaines de Nom

Terminons sur un point que je n’ai pas encore abordé et évité par Aaron Newton et qui pourtant sont une raison additionnelle majeure qui me fait ne pas aimer Mootools.
Je veux bien sûr parler de l’utilisation des domaines de nom.

Alors qu’un effort constant est mené par jQuery pour limiter son impact sur le namespace de window, se limitant en tout et pour tout à deux variables désignant le même objet: jQuery et $, on ne peut pas en dire autant de la part de Mootools.

Mootools place ses objets sans aucune pudeur dans le namespace global.

On a bien sûr les variables de sélecteurs $ et $$ mais aussi toute une floppée d’autres objets : Element, Class, Slick. Si vous utilisez Mootools More, d’autres objets seront aussi déclarés : Form, Fx etc.

Sérieusement, quel est le risque qu’un autre script utilise une variable nommée Form ?

Assez élevé si vous voulez mon avis.

Pour un framework qui destiné aux “développeurs de niveau intermédiaire à avancé”, je trouve qu’il s’agit d’une bien grosse erreur de débutant.

Conclusion

Vous l’aurez compris, je ne suis pas fan de Mootools. JQuery n’a évidemment pas besoin de moi pour continuer à être le framework dominant.

Rappellons un point qui a pu s’évanouir pendant la lecture de ce billet : Mootools n’est pas un mauvais framework.

Le simple fait que netvibes ou le w3c l’utilisent devraient suffire à s’en convaincre.

Mais le fait est que j’ai quelques points de désaccord avec Mootools et la présentation qu’en fait Aaron Newton.

Je trouve Mootools arrogant, trop buggué et pour une large part inutile, voire contre-productif.

Oui, ceci est orienté et prosélyte _je passerais mon temps autrement qu’à rédiger ce billet si je ne voulais pas être lu.
À mon sens, Mootools tente de faire sa promotion en usant de l’argument corporatiste « Mootools est pour les 31337 ; jQuery est pour les Noobs.

Je trouve cet argument faux. Et je n’aime pas le corporatisme. Les véritables 31337 sont ouverts au monde.

Vous pouvez avoir de bonnes raisons de continuer à préférer Mootools à jQuery (ou n’importe quel autre framework) mais ne tombez pas dans ce piège grossier.

PS  : Si vous voulez en apprendre plus sur Javascript, je vous invite à consulter les diverses publications de Douglas Crockford.

Inforegistre – Arnaque à la création d’entreprise

J’ai reçu ce matin ce courrier:
Inforegistre - Scam form

Aucune note explicative l’accompagnant. Le formulaire ressemble comme deux gouttes d’eau à n’importe quel autre formulaire. Une longue liste de champs pénibles à remplir. Un nom qui sonne bon la bureaucratie.
Et un chèque de 143,53€ à joindre : ..

Mais… une minute !
Regardons les petites lignes :
Inforegistre scam - bottom lines

Ce courrier est en fait une offre commerciale. Rien à voir avec une quelconque obligation administrative.
Quant à l’intérêt réel du service fourni, il est plus que douteux pour moi.

On est en face d’une belle opération de comm qui surfe sur la mode de auto-entrepreneuriat.

Alors attention si vous venez d’enregistrer votre entreprise à bien lire les petites lignes des courriers que vous recevez.

Page blanche après la mise à jour de WP Super Cache

Blank.
Aujourd’hui, j’ai mis à jour mon WordPress pour la version 3.0.

Comme d’habitude, cela s’est avéré être un moment pénible mais nécessaire.
Comme d’habitude, la mise à jour automatique a échoué.
Comme d’habitude, la version de mon plugin qtranslate a été déclarée incompatible et il a fallu tricher un peu (en le passant à « 3.0″ pour moi).

Mais, bien plus gênant, après que j’ai mis à jour WP Super Cache, et ce pour la deuxième, les visiteurs de ce blog ne se voyaient affiché qu’une page blanche.

J’avais rencontré le même problème lors de la dernière mise à jour et avais eu à bidouiller les sources mais j’espérais qu’un tel problème soit résolu sur la prochaine version. Avant que je ne soumette un patch au développeur, voici comment j’ai résolu mon problème.

Dans mon cas, le plugin mettait correctement en cache la page, générant un beau fichier html statique. Il détectait aussi tout à fait correctement que la page avait été mise en cache lors de la seconde visite et retrouvait le fichier de cache de manière correcte.

Ensuite, il faisait ça:

include( $cache_file );

Cela ne vous fait pas sourciller ? Souvenez-vous mon cache était un fichier html. Faire un include depuis php ne faisait rien d’autre que produire une Parse error.

Du coup, j’ai juste remplacé l’include par :

switch(array_pop(explode('.', $cache_file)))
{
	case 'php':
		include( $cache_file );
		break;
	default:
		readfile( $cache_file );
		break; 					
}

Sur la version que j’utilise (0.9.9.3), tout ça se passe dans le fichier wp-content/plugin/wp-cache/wp-cache-phase1.php, ligne 212.

Si vous avez activé la compression dans WP Super Cache, le code situé au dessus est très probablement faux aussi.

Bien sûr, le fix est assez sale. On ne devrait pas se fier à l’extension du fichier pour en déterminer le type mais je suis un paresseux (et un peu malade).

Une méthode plus propre serait de s’assurer au moment de la génération du cache qu’on a dans tous les cas un php valide, par exemple en rajoutant « ?> » et « <

Comment récupérer l’évènement KeypressEvent sur un Widget GTK

Keyboard in action Disons que vous vouliez par exemple changer le curseur de la souris lorsque l’utilisateur appuie sur la touche Control au dessus de votre widget. Cette tâche apparemment simple a presque failli me rendre dingue.

S’abonner à l’événement KeyPressEvent ne suffit pas.

Utiliser AddEvent pour ajouter KeyPress à la liste d’événements du widget ne suffit pas.

En fait, pour que l’évènement KeyPress soit déclenché, il faut que votre widget, tout comme un contrôle Winform, ait reçu le focus.

Donc, je passe la propriété CanFocus à true et… cela ne marche pas!

Arhgle!….

Grâce à ce lien, j’ai finalement pu retrouver toutes les étapes nécessaires :

  • Il vous faut utiliser la méthode AddEvent pour ajouter KeyPress à la liste d’événements de votre widget.
  • Il vous faut passer la propriété CanFocus à true
  • Il faut vous abonner à l’événement FocusIn et, lorsqu’il est appelé, passer la propriété HasFocus à true
  • Il faut vous abonner à l’événement FocusOut et, lorsqu’il est appelé, passer la propriété HasFocus à false
  • Sur l’évènement lors duquel vous désirez que votre widget reçoive le focus (probablement ButtonPress), il vous faut appeler la méthode GrabFocus

Seulement alors vous pourrez récupérer votre événement KeyPress.