Je n'arrive pas à sortir du mode plein écran avec esc ! et CTRL-Pomme-Démarrage c'est un peu lourd [...] - pouvoir faire défiler les images en plein écran avec les flèches du clavier ou un clic de la souris.
Le clavier ne marche plus en mode plein écran ?! Mince, alors ça marchait avant. Pfff. Zyva, tu modifies le code à gauche et y marche plus à droite. Bon, je me remets au boulot.
+ Chacha
[edit] Tiens, chez moi ça marche ?! Tu peux me donner plus de détails, stp ? Je suis surpris que ça puisse changer d'une machine à l'autre.
Je reviens sur ce fil de discussion car apparemment il y a un vrai problème. Je m'explique : chez moi, j'ai développé Quicky pour qu'on puisse naviguer avec les flèches haut/bas/gauche/droite du clavier, en plein écran ou en mode fenêtré. Et chez, moi ça marche très bien.
Mpergand dit que chez lui, non, et amnesic dit "mais si". Donc apparemment il y a une différence de comportement d'un machine à l'autre ; j'ai un copain qui m'a dit avoir observé la même chose : chez lui, les touches au clavier ne marchent pas.
La première chose qui vient à l'esprit, c'est que j'ai fait une bêtise et utilisé des codes de touches "hardware dependent". Pourtant, je ne suis pas allé chercher un truc très compliqué : j'ai surchargé keyDown dans ma NSView, qui est initialFirstResponder. Et dans le keyDown, je testais le "keycode" que la doc précise "hardware independant".
Voyant que ça ne marchait pas chez mon copain, j'ai plutôt utilisé la méthode "characters" du NSEvent. Bien sûr, ça marche toujours chez moi, mais toujours pas chez lui; en plein écran comme en fenêtré. Précision : les touches bipes.
y'a-t-il une subtilité qui m'échappe complètement ? Comment ce peut-ce qu'on puisse avoir deux comportements sur le même système d'exploitation (nous avons panther tous les deux) ? Je n'ai absolument pas tripatouillé les NSEvent, j'utilise les méthodes de base, je ne m'attends donc pas à rencontrer ce genre de problème...
Je pensais que ça pouvais venir du clavier de mon iBook, mais j'ai fait des tests sur Powermac et les keycodes sont les mêmes;
Effectivement, on est bien hardware-independent avec keycode
Il se pourrait aussi que, pour une raison inconnue, la vue ne soit plus firstResponder ?
J'y avais pensé aussi, et j'ai rajouté un makeFirstResponder lors du passage en plein écran, suchargé acceptsFirstResponder et resignFirstResponder resp. à YES et NO, mais nib, que dalle, ça n'a rien changé. Je suis sûr que le problème tient à pas grand chose, mais alors où.... De toutes manières, je vous tiendrai au courant.
Pour le clavier, la différence de comportement provient certainement de l'activation de l'accès complet à l'interface (ca se regle dans je-ne-sais-plus-quel-prepane).
Pour le clavier, la différence de comportement provient certainement de l'activation de l'accès complet à l'interface (ca se regle dans je-ne-sais-plus-quel-prepane).
Salut Bru, J'adore tes interventions, il en émane comme un souffle divin. Effectivement, je viens de désactiver mon "'accès complet au clavier" du prefpane "Clavier et souris", et les touches ne marchent plus dans Quicky. D'après mes logs, tout devient simple : le performKeyEquivalent est appelé, mais pas le keyDown. Une solution serait alors de surcharger le performKeyEquivalent pour qu'il appelle le keydown, mais problème : pour une raison que j'ignore, l'appui sur *une* touche déclenche *quatre* performKeyEquivalent. d'ailleurs c'est bizarre, si "l'accès complet au clavier" est activé, le "performKeyEquivalent" n'est appelé "que" *deux* fois, avec le "keyDown" entre les deux. La solution qui me vient à l'esprit, c'est de gérer une petite variable pour n'exécuter keyDown qu'une seule fois, même s'il est appelé 4 fois de suite. N'y aurait-il pas une solution plus propre ?
En fait, les concepts de key-window, first-responder et autres délices doivent absolument être implantés dans un ordre stricte. Après quoi, la gestion des événements clavier devient un délice.
Tu peux aussi gérer tes événements clavier en utilisant non les key-events, mais plutôt les actions associées. Par exemple tu peux utiliser moveRight: au lieu de gérer l'événement keydown touche fléche droite. Cela te permet d'avoir un niveau d'abstraction vis à vis du clavier encore plus fin (par exemple, en standard Apple, "pagehome" a un autre équivalent : pomme-flèche haut, donc 2 touches pour la même action).
Plus propre ? En fait, les concepts de key-window, first-responder et autres délices doivent absolument être implantés dans un ordre stricte. Après quoi, la gestion des événements clavier devient un délice.
En fait je vais poser une question bête, mais "où est-ce que tu as appris ça" ? Le coup du moveRight, je ne l'avais jamais vu nulle part, dans aucun bouquin ni dans la doc des événements clavier ! C'est un peu frustrant de passer à côté de solutions simples quand on a ce genre de problèmes.
Tu peux aussi gérer tes événements clavier en utilisant non les key-events, mais plutôt les actions associées. Par exemple tu peux utiliser moveRight: au lieu de gérer l'événement keydown touche fléche droite. Cela te permet d'avoir un niveau d'abstraction vis à vis du clavier encore plus fin (par exemple, en standard Apple, "pagehome" a un autre équivalent : pomme-flèche haut, donc 2 touches pour la même action).
Ok, je viens de regarder la doc, moveRight, moveUp existent, etc. Mais je ne comprends pas très bien ce que c'est . Chaque touche du clavier déclenche une action ? Quel est le comportement par défaut ? Si j'intercepte les keydown, l'action est-elle déclenchée quand même ? En bref : où sont les explications dans la doc apple ?
Sinon, et bien merci, Bru
+ Chacha
[edit] Bon, moveRight est appelé uniquement quand l'accès complet au clavier est activé. Donc j'ai surchargé performKeyEquivalent pour le cas où l'accès complet est désactivé. Mais pas de bol, performKeyEquivalent est alors appelé deux fois. Et si je réactive l'accès complet, la présence du performKeyEquivalent empêche le moveRight d'être appelé, tandis que performKeyEquivalent est toujours appelé deux fois. Qué pasa ? [/edit]
Ok, je viens de regarder la doc, moveRight, moveUp existent, etc. Mais je ne comprends pas très bien ce que c'est . Chaque touche du clavier déclenche une action ? Quel est le comportement par défaut ? Si j'intercepte les keydown, l'action est-elle déclenchée quand même ? En bref : où sont les explications dans la doc apple ?
C'est drôle de voir que les gens manipulent les événements touche sans jamais savoir comment marche la gestion du clavier sous OSX (et donc sans jamais avoir jeté un coup d'oeil au text input manager).
L'utilisation de keyDown: c'est du bas niveau. Mais tu peux laisser le système gérer les événements clavier et ne traiter en retour que les appels aux méthodes de haut niveau déclenchés par ces événements clavier.
Pour autoriser ça, il te suffit de surcharger la keydown: de ta vue personnalisée et à l'intérieur de cette méthode, d'appeller la méthode interpretKeyEvents de NSResponder. Ceci autorise le système à "associer" ces événements clavier à une "action" qui va être appelée sur ta vue. L'association touche<->action se réalise à l'aide d'un plist qui doit se trouver quelque part dans le système (mais qui est personnalisable je crois me souvenir).
Je vais essayer de me souvenir de tout ce que tu dois faire.
Je suppose que tu as une vue personnalisée dans laquelle tu dois traiter certaines actions clavier, non ?
Dans cette custom view, tu dois surcharger la méthode acceptsFirstResponder pour qu'elle renvoie YES (tu acceptes les événements clavier).
Dès cet instant, tu dois alors surcharger keyDown: afin d'effectuer les actions que tu veux faire en fonction des touches, ou mieux, de laisser le système décider de l'action à déclencher en passant l'événement à la méthode interpretKeyEvents: que tu appelles comme ceci :
J'ai retrouvé le plist qui associe touches et actions : c'est StandardKeyBinding.dict, et doit se trouver dans les resources du framework de l'application kit (chemin System/Library/Frameworks/AppKit.framework).
Toutes les actions possibles sont présentes (mais non implémentées) dans la classe NSResponder.
Je me souviens d'une bidouille dans ce fichier qui permettait de réactiver le couper/copier/coller dans OSX à partir des touches F1, F2 et F3 comme sous OS9.
C'est drôle de voir que les gens manipulent les événements touche sans jamais savoir comment marche la gestion du clavier sous OSX (et donc sans jamais avoir jeté un coup d'oeil au text input manager).
En même temps, "text input" pour la détection de l'appui sur une touche, ça ne me paraà®t pas très naturel. Pour moi, le text input découle des événements clavier, pas l'inverse. D'où le fait que je n'ai pas exploré cette documentation.
Je suppose que tu as une vue personnalisée dans laquelle tu dois traiter certaines actions clavier, non ? Dans cette custom view, tu dois surcharger la méthode acceptsFirstResponder pour qu'elle renvoie YES (tu acceptes les événements clavier). Dès cet instant, tu dois alors surcharger keyDown: afin d'effectuer les actions que tu veux faire en fonction des touches, ou mieux, de laisser le système décider de l'action à déclencher en passant l'événement à la méthode interpretKeyEvents:
Oui mais non; quand mon "accès au clavier complet" est désactivé, le keydown n'est jamais appelé. Ce n'est pas normal, c'est ça ?
En fait je vais poser une question bête, mais "où est-ce que tu as appris ça" ?
J'ai une sale manie. En fait, non, j'ai 2 manies.
1 - je ne peux m'empêcher de lire TOUTE la doc Apple régulièrement, même sur des sujets que je n'ai jamais abordé (et que je n'aborderais jamais). Si ya un truc qui m'interloque, alors je créé un nouveau projet Xcode, et je teste, je triture. Comme ça, dès que j'ai besoin d'un truc, j'arrive à me rappeler quand et où je l'ai lu dans la doc...
2 - à chaque révision de X, je suis à l'affût de tout ce qui a été changé et je compare avec l'ancienne version, ce qui me permet de savoir à peu près ce qui est nouveau, puis projet Xcode, et test, et etc...
La dernière fois, sur mon mac, j'ai nettoyé jusqu'à une 200aine de projets dans ce style (certains sont devenus des TRUKéASTUCES)...
Et croyez moi, cette doc Apple (que certains villipendent sans vergogne) est vachement bien foutue.
dans le windowControllerDidLoadNib de mon document. Et bien maintenant ça marche (keydown est appelé). Et si je l'enlève, ça marche pas. (keydow n'est plus appelé). Et si je le remets, ça remarche.
Je suis content, mais je trouve ça un peu sournois. Ainsi, le initialFirstResponder n'est pas suffisant. Ce n'est pas bizarre, ça ?
Petite appli bien sympa, ça se rapproche de plus en plus de ce que je cherchais depuis que j'ai switché .
J'ai juste quelques petites suggestions pour qu'elle satisfasse tous mes besoins (mais ça n'engage que moi):
- un menu/raccourci pour supprimer une photo à la volée (bien pratique lorsque l'on vient d'uploader un bon paquet de photos de son numérique et qu'on souhaite faire un premier tri
- en mode plein écran un zoom basé sur la largeur de l'image serait vraiment sympa (surtout pour la lecture de BD/Manga mais ça implique de rajouter d'autres commandes pour faire défiler l'image)
- le summun, ça serait de pouvoir faire une sauvegarde sans perte après rotation de l'image (toujours via un raccourci clavier)
- et dernier point: ne pratiquement rien rajouter d'autre, car c'est le côté pratique/rapide/léger de l'appli qui me séduit le plus, la transformer en usine à gaz par l'ajout de trop de fonctionnalité serait vraiment dommage.
Ah oui une dernière chose, c'est vraiment sympa de voir sa photo dans la doc
Je viens juste de m'apercevoir d'un petit bug( ???): je n'arrive pas à définir quicky come programme par défaut pour lire les jpg (je n'est pas essayé avec les autres formats).
Je viens juste de m'apercevoir d'un petit bug( ???): je n'arrive pas à définir quicky come programme par défaut pour lire les jpg (je n'est pas essayé avec les autres formats).
Tiens, je me demande d'où ça vient... Vu que là , c'est OS X qui gère. Sinon, petite question, djiwhy, es-tu Le (c'est-à -dire Mon) Djiwhy ? Ou est-ce un hasard de pseudo ?
J'ai retrouvé le plist qui associe touches et actions : c'est StandardKeyBinding.dict, et doit se trouver dans les resources du framework de l'application kit (chemin System/Library/Frameworks/AppKit.framework).
Toutes les actions possibles sont présentes (mais non implémentées) dans la classe NSResponder.
Je me souviens d'une bidouille dans ce fichier qui permettait de réactiver le couper/copier/coller dans OSX à partir des touches F1, F2 et F3 comme sous OS9.
Et bien par exemple le sweat que je porte sur la photo, je l'ai ramené de mon stage de 3ème année aux US.
->Chacha, c'est vraiment n'importe quoi
Pour revenir au sujet principal du forum, c'est quand qu'elle arrive ta nouvelle version de Quicky ? (Faut bien que je trouve un outil sympa pour visionner l'intégrale de Calvin & Hobbes). Tu penses rajouter quoi en fin de compte comme nouvelles fonctionnalités ? Et puis si tu pouvais rajouter le pomme+F en plus du Echap pour sortir du mode plein écran, il me semble que ça serait + logique, enfin moi ce que j'en dis...
Et bien par exemple le sweat que je porte sur la photo, je l'ai ramené de mon stage de 3ème année aux US.
->Chacha, c'est vraiment n'importe quoi
C'est bon, c'est bien toi! ;-)
Pour revenir au sujet principal du forum, c'est quand qu'elle arrive ta nouvelle version de Quicky ?
Dès que Jérôme a fini de pinailler
Tu penses rajouter quoi en fin de compte comme nouvelles fonctionnalités ?
Je ne pense rien rajouter, sinon ça nécessiterait un nouveau beta-test. De plus, je ne saurais pas quoi rajouter. Je trouve qu'actuellement, le programme répond bien à "léger et rapide".
Et puis si tu pouvais rajouter le pomme+F en plus du Echap pour sortir du mode plein écran, il me semble que ça serait + logique, enfin moi ce que j'en dis...
Réponses
Le clavier ne marche plus en mode plein écran ?! Mince, alors ça marchait avant. Pfff. Zyva, tu modifies le code à gauche et y marche plus à droite. Bon, je me remets au boulot.
+
Chacha
[edit]
Tiens, chez moi ça marche ?! Tu peux me donner plus de détails, stp ?
Je suis surpris que ça puisse changer d'une machine à l'autre.
Bon je profite du beau temps, alors bon week-end à tous !
Nickel, mais quand même, c'est bizarre chez mpergand
Mpergand dit que chez lui, non, et amnesic dit "mais si". Donc apparemment il y a une différence de comportement d'un machine à l'autre ; j'ai un copain qui m'a dit avoir observé la même chose : chez lui, les touches au clavier ne marchent pas.
La première chose qui vient à l'esprit, c'est que j'ai fait une bêtise et utilisé des codes de touches "hardware dependent". Pourtant, je ne suis pas allé chercher un truc très compliqué : j'ai surchargé keyDown dans ma NSView, qui est initialFirstResponder. Et dans le keyDown, je testais le "keycode" que la doc précise "hardware independant".
Voyant que ça ne marchait pas chez mon copain, j'ai plutôt utilisé la méthode "characters" du NSEvent. Bien sûr, ça marche toujours chez moi, mais toujours pas chez lui; en plein écran comme en fenêtré. Précision : les touches bipes.
y'a-t-il une subtilité qui m'échappe complètement ? Comment ce peut-ce qu'on puisse avoir deux comportements sur le même système d'exploitation (nous avons panther tous les deux) ? Je n'ai absolument pas tripatouillé les NSEvent, j'utilise les méthodes de base, je ne m'attends donc pas à rencontrer ce genre de problème...
+
Chacha
Je pensais que ça pouvais venir du clavier de mon iBook, mais j'ai fait des tests sur Powermac et les keycodes sont les mêmes;
esc = 53
^Â Â = 126
<Â Â = 123
v  = 125
>Â Â = 124
???
Il se pourrait aussi que, pour une raison inconnue, la vue ne soit plus firstResponder ?
Effectivement, on est bien hardware-independent avec keycode
J'y avais pensé aussi, et j'ai rajouté un makeFirstResponder lors du passage en plein écran, suchargé acceptsFirstResponder et resignFirstResponder resp. à YES et NO, mais nib, que dalle, ça n'a rien changé.
Je suis sûr que le problème tient à pas grand chose, mais alors où.... De toutes manières, je vous tiendrai au courant.
.
Salut Bru,
J'adore tes interventions, il en émane comme un souffle divin. Effectivement, je viens de désactiver mon "'accès complet au clavier" du prefpane "Clavier et souris", et les touches ne marchent plus dans Quicky.
D'après mes logs, tout devient simple : le performKeyEquivalent est appelé, mais pas le keyDown.
Une solution serait alors de surcharger le performKeyEquivalent pour qu'il appelle le keydown, mais problème : pour une raison que j'ignore, l'appui sur *une* touche déclenche *quatre* performKeyEquivalent. d'ailleurs c'est bizarre, si "l'accès complet au clavier" est activé, le "performKeyEquivalent" n'est appelé "que" *deux* fois, avec le "keyDown" entre les deux.
La solution qui me vient à l'esprit, c'est de gérer une petite variable pour n'exécuter keyDown qu'une seule fois, même s'il est appelé 4 fois de suite. N'y aurait-il pas une solution plus propre ?
Chacha
Certes oui.
En fait, les concepts de key-window, first-responder et autres délices doivent absolument être implantés dans un ordre stricte. Après quoi, la gestion des événements clavier devient un délice.
Tu peux aussi gérer tes événements clavier en utilisant non les key-events, mais plutôt les actions associées. Par exemple tu peux utiliser moveRight: au lieu de gérer l'événement keydown touche fléche droite. Cela te permet d'avoir un niveau d'abstraction vis à vis du clavier encore plus fin (par exemple, en standard Apple, "pagehome" a un autre équivalent : pomme-flèche haut, donc 2 touches pour la même action).
.
En fait je vais poser une question bête, mais "où est-ce que tu as appris ça" ? Le coup du moveRight, je ne l'avais jamais vu nulle part, dans aucun bouquin ni dans la doc des événements clavier ! C'est un peu frustrant de passer à côté de solutions simples quand on a ce genre de problèmes.
Ok, je viens de regarder la doc, moveRight, moveUp existent, etc. Mais je ne comprends pas très bien ce que c'est . Chaque touche du clavier déclenche une action ? Quel est le comportement par défaut ? Si j'intercepte les keydown, l'action est-elle déclenchée quand même ?
En bref : où sont les explications dans la doc apple ?
Sinon, et bien merci, Bru
+
Chacha
[edit]
Bon, moveRight est appelé uniquement quand l'accès complet au clavier est activé. Donc j'ai surchargé performKeyEquivalent pour le cas où l'accès complet est désactivé. Mais pas de bol, performKeyEquivalent est alors appelé deux fois. Et si je réactive l'accès complet, la présence du performKeyEquivalent empêche le moveRight d'être appelé, tandis que performKeyEquivalent est toujours appelé deux fois. Qué pasa ?
[/edit]
C'est drôle de voir que les gens manipulent les événements touche sans jamais savoir comment marche la gestion du clavier sous OSX (et donc sans jamais avoir jeté un coup d'oeil au text input manager).
L'utilisation de keyDown: c'est du bas niveau. Mais tu peux laisser le système gérer les événements clavier et ne traiter en retour que les appels aux méthodes de haut niveau déclenchés par ces événements clavier.
Pour autoriser ça, il te suffit de surcharger la keydown: de ta vue personnalisée et à l'intérieur de cette méthode, d'appeller la méthode interpretKeyEvents de NSResponder. Ceci autorise le système à "associer" ces événements clavier à une "action" qui va être appelée sur ta vue. L'association touche<->action se réalise à l'aide d'un plist qui doit se trouver quelque part dans le système (mais qui est personnalisable je crois me souvenir).
.
Je suppose que tu as une vue personnalisée dans laquelle tu dois traiter certaines actions clavier, non ?
Dans cette custom view, tu dois surcharger la méthode acceptsFirstResponder pour qu'elle renvoie YES (tu acceptes les événements clavier).
Dès cet instant, tu dois alors surcharger keyDown: afin d'effectuer les actions que tu veux faire en fonction des touches, ou mieux, de laisser le système décider de l'action à déclencher en passant l'événement à la méthode interpretKeyEvents: que tu appelles comme ceci :
[tt][super interpretKeyEvents:[NSArray arrayWithObject:theEvent]];[/tt]
Enfin, il ne te reste plus qu'à implémenter les méthodes d'actions dans ta classe pour réaliser le travail que tu veux !
.
Toutes les actions possibles sont présentes (mais non implémentées) dans la classe NSResponder.
Je me souviens d'une bidouille dans ce fichier qui permettait de réactiver le couper/copier/coller dans OSX à partir des touches F1, F2 et F3 comme sous OS9.
.
En même temps, "text input" pour la détection de l'appui sur une touche, ça ne me paraà®t pas très naturel. Pour moi, le text input découle des événements clavier, pas l'inverse. D'où le fait que je n'ai pas exploré cette documentation.
Oui mais non; quand mon "accès au clavier complet" est désactivé, le keydown n'est jamais appelé. Ce n'est pas normal, c'est ça ?
J'ai une sale manie. En fait, non, j'ai 2 manies.
1 - je ne peux m'empêcher de lire TOUTE la doc Apple régulièrement, même sur des sujets que je n'ai jamais abordé (et que je n'aborderais jamais). Si ya un truc qui m'interloque, alors je créé un nouveau projet Xcode, et je teste, je triture. Comme ça, dès que j'ai besoin d'un truc, j'arrive à me rappeler quand et où je l'ai lu dans la doc...
2 - à chaque révision de X, je suis à l'affût de tout ce qui a été changé et je compare avec l'ancienne version, ce qui me permet de savoir à peu près ce qui est nouveau, puis projet Xcode, et test, et etc...
La dernière fois, sur mon mac, j'ai nettoyé jusqu'à une 200aine de projets dans ce style (certains sont devenus des TRUKéASTUCES)...
Et croyez moi, cette doc Apple (que certains villipendent sans vergogne) est vachement bien foutue.
.
Effectivement, c'est pas normal.
- Utilise tu une fenêtre standard (et non un panel) avec une barre de titre normale ?
- Cette fenêtre est elle la key window de ton appli ?
- ta vue personnalisée, est elle le first responder ?
.
Oui
Oui
Dans IB, je l'ai définie comme "initialFirstResponder"
Eh, mais attends voir...
[...]
Ok, je viens de rajouter
dans le windowControllerDidLoadNib de mon document.
Et bien maintenant ça marche (keydown est appelé). Et si je l'enlève, ça marche pas. (keydow n'est plus appelé). Et si je le remets, ça remarche.
Je suis content, mais je trouve ça un peu sournois. Ainsi, le initialFirstResponder n'est pas suffisant. Ce n'est pas bizarre, ça ?
En tous cas, merci encore.
Chacha
J'ai juste quelques petites suggestions pour qu'elle satisfasse tous mes besoins (mais ça n'engage que moi):
- un menu/raccourci pour supprimer une photo à la volée (bien pratique lorsque l'on vient d'uploader un bon paquet de photos de son numérique et qu'on souhaite faire un premier tri
- en mode plein écran un zoom basé sur la largeur de l'image serait vraiment sympa (surtout pour la lecture de BD/Manga mais ça implique de rajouter d'autres commandes pour faire défiler l'image)
- le summun, ça serait de pouvoir faire une sauvegarde sans perte après rotation de l'image (toujours via un raccourci clavier)
- et dernier point: ne pratiquement rien rajouter d'autre, car c'est le côté pratique/rapide/léger de l'appli qui me séduit le plus, la transformer en usine à gaz par l'ajout de trop de fonctionnalité serait vraiment dommage.
Ah oui une dernière chose, c'est vraiment sympa de voir sa photo dans la doc
Je ferais a peu près les memes demandes que toi sauf pour la rotation.
Tiens, je me demande d'où ça vient... Vu que là , c'est OS X qui gère.
Sinon, petite question, djiwhy, es-tu Le (c'est-à -dire Mon) Djiwhy ? Ou est-ce un hasard de pseudo ?
+
Chacha
[edit]
Boh, chez moi ça marche ?!
[/edit]
Suis encore à la bourre...
C'est de cette page que tu parles?
Ha ! prouve-le !
->Chacha, c'est vraiment n'importe quoi
Pour revenir au sujet principal du forum, c'est quand qu'elle arrive ta nouvelle version de Quicky ? (Faut bien que je trouve un outil sympa pour visionner l'intégrale de Calvin & Hobbes). Tu penses rajouter quoi en fin de compte comme nouvelles fonctionnalités ? Et puis si tu pouvais rajouter le pomme+F en plus du Echap pour sortir du mode plein écran, il me semble que ça serait + logique, enfin moi ce que j'en dis...
Voili voilà
djiwhy
C'est bon, c'est bien toi! ;-)
Dès que Jérôme a fini de pinailler
Je ne pense rien rajouter, sinon ça nécessiterait un nouveau beta-test. De plus, je ne saurais pas quoi rajouter. Je trouve qu'actuellement, le programme répond bien à "léger et rapide".
C'est une bonne idée, pas de problème.
+
Chacha