/* Topic des codeurs [8] */

vv221 · Le 05/10/2015, à 15:01

grim7reaper a écrit :

@vv221 : tu as un dépôt (git, mercurial, …) avec tout tes scripts (ou au pire, une archive) ou faut les regarders un à un via cette page ?

Pas encore de dépôt git accessible publiquement, mais celui-ci est en bonne position sur ma fiche de route pour la ré-écriture à venir (aux côtés d’une doc complète).
En attendant les scripts peuvent être trouvés par ici :
http://www.dotslashplay.it/scripts/

Par ordre des plus récents au plus anciens :
_dans les répertoires 'play.it-1.13' & 'play.it-1.12' se trouvent les scripts actuellement publiés
_directement à la racine de la page donnée en lien se trouvent quelques vieux scripts qui seront portés sur le schéma 1.13 avant que je me lance dans la ré-écriture
_dans les répertoires 'fr' & 'en' se trouvent les plus vieux modèles de scripts que j’ai mis en ligne, ce sont ceux que je porte sur la version 1.13 en ce moment même

Mon objectif du moment est de tout porter sur le schéma de la version 1.13 pour avoir un unique modèle avant de lancer ma ré-écriture qui se traduira par une version 2.0.
Cette ré-écriture se fera "from scratch" pour me débarrasser de quelques lourdeurs qui se sont accumulées à mesure que j’ai étendu les fonctionnalités de la bibliothèque sur laquelle se basent les derniers scripts, et une doc sera rédigée en parallèle pour faciliter les éventuelles contributions.

-----

Je vois que tu es arrivé sur la version anglaise du wiki, celui-ci étant bilingue tu préféreras peut-être passer par la version française :
http://wiki.dotslashplay.it/fr/start

Par défaut la langue affichée dépend de la langue préférée par le navigateur web.

Elzen · Le 13/10/2015, à 14:54

Bon courage vv221

De mon côté, j'ai un nouveau truc qui me rend perplexe, pour Touhy.

Une de mes applis est un lanceur de jeux « universel »⁽¹⁾. Comprenez par là, une appli qui liste les jeux installé sur le système et permet de les lancer automatiquement en appelant le bon exécutable (directement pour les jeux natifs, ou bien en lançant Wine ou un émulateur, tout ça). Globalement, ça semble marcher plutôt bien pour l'instant, mais je voudrais rajouter quelques fonctionnalités, notamment un suivi des fenêtres pour savoir si un jeu donné a le focus ou pas.

Or, j'ai plusieurs cas pour lesquels ça ne marche pas. Le premier est celui de jeux dont la fenêtre ne fournit à X aucune information sur sa classe, le PID qui l'a lancé, etc., or ce sont ces informations sur lesquelles je me base pour faire le repérage. Si vous voulez tester, je connais au moins deux jeux des dépôts qui sont concernés : l'émulateur PCSX, et liquidwar.

Le second (que je rencontre dans certains cas de jeux Wine) est qu'il y a plusieurs processus concernés, dont un qui se termine en cours de route : wine lance un autre processus qui lance lui-même le jeu et se termine (du moins est-ce ce que j'ai compris). Le processus de base reste actif jusqu'à fermeture du jeu, mais le pid correspondant à la fenêtre, du fait que son parent immédiat se soit fermé, a comme ppid 1, ce qui ne me permet pas de faire le lien entre les deux (je procède au repérage en faisant la liste des processus enfants de celui que mon lanceur a déclenché, et en regardant si le pid associé à la fenêtre est dedans).

Comme j'ai fait ça à l'aveugle et sans y connaître grand chose, il est possible (voire probable) que je sois passé à côté d'une solution plus élégante que les vrais lanceurs (du type du dock de Window Maker, par exemple) utiliseraient, mais je n'ai pas spécialement le temps d'aller fouiller dans le code source concerné dans l'immédiat (en vrai, j'ai une thèse à rédiger, aussi ). Donc si jamais quelqu'un avait des idées en l'air ou des pistes à proposer pour guider mes recherches, ça m'intéresserait

(1) Étant donné qu'en anglais, ça donne Universal Game Launcher, donc UGL, donc Ugly, cette appli s'appelle Tuco, qui est le prénom du truand/the ugly dans le célèbre western.

The Uploader · Le 17/10/2015, à 08:25

Tu peux pas recevoir cette information de la part du gestionnaire de fenêtres plutôt que de la part de X ? Sans pour autant te lier à un WM particulier ? (oui je sais c'est sûrement mission impossible mais je croyais qu'il y avait quelque standardisation...)

Elzen · Le 17/10/2015, à 13:23

Hum, je ne suis pas sûr de voir ce que le fait de demander au WM plutôt qu'à X est censé apporter dans ce cas.

En fait, je ne manipule pas directement la Xlib (pour le peu que j'ai eu à m'y pencher, c'est assez atroce), mais la bibliothèque WNCK. Je ne sais pas exactement où elle va chercher ses infos, mais pour le cas que je décris ci-dessus, les infos disponibles sont les mêmes que je demande à cette bibli, à xprop ou à un outil comme wmctrl. Donc je suppose qu'elles ne doivent pas être facilement accessibles.

(D'ailleurs, c'est un des trucs majeurs qu'il faudra que je prenne en compte quand je passerai à Python3 : il me faudra une bibliothèque de type WNCK, mais compatible avec la bibli graphique utilisée (pour les formats d'images, par exemple, ce ne serait pas glop de devoir manipuler un GdkPixbuf dans du non-GTK…). Ça va encore être joyeux, ça… )

grim7reaper · Le 21/10/2015, à 12:07

Elzen a écrit :

Le premier est celui de jeux dont la fenêtre ne fournit à X aucune information sur sa classe

Comme tu le dis, c'est l'application qui ne donne pas l'info. Il "suffirait" de proposer un patch upstream et/ou de reporter le problème.
Ça revient à créer un Atom avec MakeAtom et lui donner le bon nom (_NET_WM_PID) et la bonne valeur (le PID).

Elzen a écrit :

l'émulateur PCSX, et liquidwar

Application open-source donc l'approche du patch/rapport de bug peut avoir son effet.

Shanx · Le 21/10/2015, à 16:30

Yo
je cherche des idées de petits jeux/petits algos à faire en Python. J'en cherche plusieurs, de difficultés différentes. Pour le moment j'en ai deux hyper simples (deviner un nombre et le jeu des allumettes) et un beaucoup plus compliqué (deviner une suite de nombre générées via LCG selon une seed à trouver - idée trouvée dans un challenge CTF). Par contre j'ai rien entre les deux, et je sèche un peu. Vous avez pas une ou deux idées ?

grim7reaper · Le 21/10/2015, à 22:44

@vv221: désolé de ne pas te faire de retour, mais en ce moment j'ai pas le temps de me plonger dans du script shell :-(

@Shanx: pour les jeux, en effet tu as pas mal de choix, genre :
- le jeux du plus ou moins (trouver un nombre entre X et Y)
- Pierre-Feuille-Ciseaux
- Morpion
- Puissance 4
- Sokoban
- Jeu des allumettes
- Sudoku
- Arpège (:P)

Pour les défis algorithmiques allant de simples à compliqués, tu peux regarder des sites comme :
- Project Euler (orienté math).
- Rosalind (orienté bioinformatique, mais pas de background bio requis).
- CodinGame (orienté jeux on va dire).
- Kaggle (Data Science).
- sites genre TopCoder SphereOnline, …

Quoi que tu choisissent, hésite pas à poster ici si tu as des questions, ça fera vivre le topic

Shanx · Le 22/10/2015, à 09:51

Merci grim, y'a plein de bonnes idées.
Je serais probablement absent quelques jours, mais dès que je peux je regarde tout ça.

Elzen · Le 22/10/2015, à 10:18

@grim : ouaip, en effet, le rapport de bug/patch se tient, et je vais sans doute l'envisager dans plus ou moins longtemps.

Mais comme ce ne sont probablement pas les seules applis dans ce cas, j'aimerais bien trouver un comportement à adopter dans ce cas-là pour tenter de contourner le problème, si c'est possible (même si c'est moche, t'façon, le nom annonce la couleur :-° ).

(Dans le cas de PCSX (qui est traité à part, parce que c'est un émulateur avec son module à part entière dans Tuco), je le repère au fait que c'est une fenêtre sans aucune info avec « PCSX » comme titre ; mais pour liquidwar (qui est « seulement » un jeu géré par le module des jeux natifs), il faut un traitement plus générique).

Une heuristique du type « la première fenêtre ouverte après le lancement de l'appli est considérée comme la bonne s'il manque les infos dont j'ai besoin dedans » pourrait p't'être le faire, mais, notamment pour les jeux Wine, le chargement peut être tellement long qu'on a largement le temps d'ouvrir d'autres fenêtres en cours de route…

grim7reaper a écrit :

- Arpège (:P)

Owi !

Il faut que je re-trouve un peu de temps pour reprendre le projet de jeu, d'ailleurs. Tu as fait des modifs depuis la dernière fois qu'on en a parlé ?

@Shanx : d'une manière générale, « des trucs que tu aurais besoin de scripter », ça marche relativement pas mal (pour moi, du moins) pour faire du python. Dans l'idée, des exemples de trucs du genre que j'ai eu à faire et qui me reviennent en tête :

Un script qui lit mon fichier de menu et génère une page HTML montrant les jeux que j'ai sur mon ordi avec quelques détails⁽¹⁾
Un script qui parcours la liste de posts d'un membre à la recherche de certains motifs⁽²⁾
Un script pour récupérer plein de fichiers TSV de résultats d'expé, faire les moyennes et regénérer des TSV
Un script qui, à partir d'une série de fichiers RSS, appelle un reconnaisseur d'entités nommées, récupère les résultats, et fait des stats sur les combinaisons les plus fréquentes

(Ouais, les deux derniers exemples viennent de mon boulot)

Et +1 pour le fait de ne pas hésiter à poster ici

(1) Je préfère ne pas poser le lien dans un endroit qui sera indexé, mais demandez sur IRC si vous voulez voir ce que ça donne.
(2) Tu as dû le recevoir, c'était pour la modo, mais ça commence à dater un peu.

@tou⋅te⋅s : si jamais vous devez coder des visualisations de graphes en Java, n'hésitez pas à jeter un œil à GraphStream. Plutôt sympa à utiliser et chouette rendu, je suis en train de faire un truc de démo avec pour ma thèse, ça commence à avoir une sacrée belle tronche \o/

Elzen · Le 22/10/2015, à 23:44

Double-post, mais c'est pour la bonne cause

Celleux d'entre vous qui ont une manette connectable à leur ordinateur ont peut-être déjà eu l'occasion de jouer à des jeux qui étaient conçus pour n'être joués qu'au clavier, sans pouvoir les configurer pour utiliser leur manette. Ou bien se sont dit que ça pourrait être cool de manœuvrer une appli autre qu'un jeu à l'aide d'un tel instrument.

Je viens de coder un script qui permet d'arranger ça

C'est un truc tout bête, en fait (du moins sur le principe) : une boucle qui écoute les événements correspondants à la manette, regarde dans sa configuration si le bouton est censé correspondre à une touche, et simule l'appui sur la touche correspondante. Bien sûr, on peut avoir une configuration différente en fonction de la fenêtre active (notamment, pour désactiver le truc sur les jeux qui, eux, gèrent correctement la manette).

En pratique, c'est un peu plus moche, parce que j'ai dû mélanger GTK (avec WNCK, pour l'écoute des fenêtres), SFML (pour écouter les événements sur la manette), et Xlib (pour générer les simulations d'appuis sur les touches). Mais bon, ça marche, c'est le principal.

Il y a juste deux trucs qui, en l'état (et avant davantage de tests, bien sûr, on verra ce que ça donne à l'usage…), me semblent grandement améliorables :

Il faut réappuyer plusieurs fois sur les boutons de la manette pour répéter l'effet, laisser la touche enfoncée un certain temps ne change rien. Je suppose qu'il faudrait que je gère moi-même une boucle qui réémet l'événement périodiquement. Vous auriez une idée de la période adaptée ?
Seule la fenêtre de destination semble actuellement recevoir l'événement, ce qui signifie qu'il n'est pas possible d'utiliser la manette pour simuler des actions gérées par le gestionnaire de fenêtres, comme les classiques Alt+Tab ou Alt+F4. Je pensais pourtant avoir géré le truc comme il faut, mais non

Toute suggestion sur l'un ou l'autre de ces points serait bienvenue

Pour info, l'extrait de code correspondant :

disp = Xlib.display.Display()
screen = wnck.screen_get_default()

def perform(keydesc, pressed):
    keycode,modifiers = parse(keydesc)
    window = screen.get_active_window()
    if window is not None:
        window = _recurse_search(disp.screen().root, window.get_xid())
    if window is None:
        window = 0
    if pressed:
        event = Xlib.protocol.event.KeyPress(type=Xlib.X.KeyPress,
            detail=keycode, time=Xlib.X.CurrentTime, root=Xlib.X.NONE,
            window=window, child=Xlib.X.NONE, root_x=0, root_y=0,
            event_x=0, event_y=0, state=modifiers, same_screen=1)
    else:
        event = Xlib.protocol.event.KeyRelease(type=Xlib.X.KeyRelease,
            detail=keycode, time=Xlib.X.CurrentTime, root=Xlib.X.NONE,
            window=window, child=Xlib.X.NONE, root_x=0, root_y=0,
            event_x=0, event_y=0, state=modifiers, same_screen=1)
    disp.send_event(window, event, modifiers, True)
    disp.flush()

La doc que j'ai utilisé pour comprendre (façon de parler ><) comment tout ça marchait est là.

Elzen · Le 25/10/2015, à 13:27

Bon, bah, triple post

J'ai réglé les deux soucis sus-mentionnés en même temps, en utilisant xtest.fake_input (qui simule l'appui sur une touche du clavier) au lieu de SendEvent (qui envoie à une fenêtre un événement correspondant à l'appui de la touche), ce qui permet de faire comme si on utilisait vraiment le clavier, avec les réactions habituelles. Un inconvénient est en revanche que l'appui sur plusieurs touches simultanées (type, Ctrl+C) par ce moyen semble un peu moins bien marcher (avec SendEvent, on avait « seulement » à mettre passer le bon masque pour préciser à l'appli quelles touches modificatrices étaient censées être appuyées, ce qui faisait un seul envoi d'événement), donc j'ai restreint le truc à une stricte application au sens mathématique du terme⁽¹⁾ (un bouton de la manette = une touche du clavier).

De plus, j'ai réussi (après un bon moment à fouiller la Xlib, avec laquelle j'ai un peu de mal) à me débarrasser de la dépendance à GTK/WNCK en faisant en sorte de récupérer les infos sur la fenêtre active directement par X. Mais la manière dont je le fais me semble un peu moche, il y a probablement moyen de simplifier ça.
(De toute façon, c'était préférable, les boucles principales de GTK et SFML ayant quelques difficultés à cohabiter. Et puis, ça rend le script compatible Python3 )

Donc, le truc étant dans un état satisfaisant, c'est publié ! N'hésitez pas si vous voulez tester et que vous avez des retours à faire.

(1) Bien sûr, elle ne sera probablement pas surjective (la manette compte moins de touches que le clavier), et c'est à vous de voir si elle sera injective ou pas (vous pouvez associer deux boutons à la même touche si ça vous chante).

grim7reaper · Le 27/10/2015, à 01:21

Elzen a écrit :

Mais comme ce ne sont probablement pas les seules applis dans ce cas, j'aimerais bien trouver un comportement à adopter dans ce cas-là pour tenter de contourner le problème, si c'est possible (même si c'est moche, t'façon, le nom annonce la couleur http://smilies.xserver-x.org/smilies/fo … tling.gif).

Le problème c’est que ce que tu essayes de faire n’est pas fiable de part l'architecture de X11. Comme ça fonctionne en client-serveur, tu pourrais avoir le cas où le processus qui a créé ta fenêtre est sur une autre machine (et du coup ton PID ne va correspondre à rien, ou va correspondre à un processus de ta machine qui n’a rien à voir avec le Schmilblick).
Cela dit, si l’on restreint ton programme aux processus locaux il y’a plusieurs approches :
- se baser sur _NET_WM_PID (c’est le plus propre).
- si ton X11 le supporte, XResQueryClientIds semble être une piste.
- un hack via LD_PREALOAD (de ce genre) pour hijack XCreateWindow et faire en sorte que _NET_WM_PID existe avec une valeur utile.
Je ne recommande pas la dernière solution, c’est quand même ’achement sale…

Quelques discussions sur cette problématique :
- https://stackoverflow.com/questions/113 … process-id
- https://unix.stackexchange.com/question … x11-window
- https://unix.stackexchange.com/question … associated

Elzen a écrit :

Il faut que je re-trouve un peu de temps pour reprendre le projet de jeu, d'ailleurs. Tu as fait des modifs depuis la dernière fois qu'on en a parlé ?

Nope

Elzen a écrit :

De plus, j'ai réussi (après un bon moment à fouiller la Xlib, avec laquelle j'ai un peu de mal) à me débarrasser de la dépendance à GTK/WNCK en faisant en sorte de récupérer les infos sur la fenêtre active directement par X. Mais la manière dont je le fais me semble un peu moche, il y a probablement moyen de simplifier ça.

Pour récupére la fenêtre active, tu as essayé XGetInputFocus ?

Elzen · Le 27/10/2015, à 17:43

grim7reaper a écrit :

tu pourrais avoir le cas où le processus qui a créé ta fenêtre est sur une autre machine (et du coup ton PID ne va correspondre à rien, ou va correspondre à un processus de ta machine qui n’a rien à voir avec le Schmilblick).

Ah, oui, j'n'avais effectivement pas prévu ce cas
Je vais essayer de voir si je peux accéder à l'attribut indiquant de quelle machine l'appli vient, et faire un test dessus. Seulement, cet attribut n'est lui-même pas forcément renseigné, et a priori, si les autres ne le sont pas, il a peu de chances de l'être.

Merci pour la doc, j'y jetterai un œil quand je pourrai.

En attendant, et en creusant un peu plus, j'me suis rendu compte que, pour la fenêtre Wine qui n'était pas reconnue, mon diagnostic était mauvais : le soucis n'est pas (ou pas forcément) qu'un processus intermédiaire s'est terminé avant que la fenêtre s'ouvre, mais que le PID associé à la fenêtre a comme PPID 0 Je n'savais pas que c'était possible.

Donc pour l'instant, j'ai rajouté une heuristique : si le PID de la fenêtre n'est pas renseigné ou que le PPID correspondant est 0 ou 1, je fais une comparaison entre le nom que j'ai de mon côté pour l'appli et (la classe si dispo, sinon) le titre de la fenêtre, en passant tout en minuscule et en virant les espaces (par exemple, la fenêtre de liquidwar s'appelle chez moi « Liquid War 5.6.4 ». En passant ça en minuscule et en virant les espaces, ça donne donc « liquidwar5.6.4 », ce qui contient « liquidwar », donc je considère que c'est la même appli).

Évidemment, ç'n'est pas parfait, mais ça limite déjà une partie de la casse.

grim7reaper a écrit :

Pour récupére la fenêtre active, tu as essayé XGetInputFocus ?

Oui, mais je n'avais pas réussi en passant par là.

En fait, cette fonction renvoie la “fenêtre” associée au composant qui a le focus, et pas à la fenêtre au sens utilisateur du terme. Et une “fenêtre” interne ne possède pas les informations dont j'ai besoin pour déterminer quelle configuration utiliser (classe et/ou titre). Or, quand j'avais cherché initialement, j'avais trouvé comment descendre dans l'arborescence de fenêtres, mais pas comment y remonter, d'où le fait que j'ai laissé tomber de ce côté-là.

Mais en creusant un poil plus, je viens de remarquer que le query_tree() renvoie la fenêtre parente en plus des fenêtres enfants, donc on peut remonter par là et retrouver les bonnes infos. Je suppose qu'il faudra faire une fonction récursive aussi (du moins en GTK, on peut imbriquer plusieurs composants ayant chacun une fenêtre GDK associée), mais ça a des chances d'être plus direct, donc je vais tenter de modifier le script comme ça.

Donc merci de m'avoir incité à re-regarder

grim7reaper · Le 28/10/2015, à 09:33

Elzen a écrit :

Je vais essayer de voir si je peux accéder à l'attribut indiquant de quelle machine l'appli vient, et faire un test dessus. Seulement, cet attribut n'est lui-même pas forcément renseigné, et a priori, si les autres ne le sont pas, il a peu de chances de l'être.

Si le programme est bien codé, si tu as le PID tu devrais aussi avoir cette info :

http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html a écrit :

If _NET_WM_PID is set, the ICCCM-specified property WM_CLIENT_MACHINE MUST also be set.

Après, dans la pratique…
Et évidemment, si tu n'as pas le PID il est aussi probable que tu n'aies pas WM_CLIENT_MACHINE.

Elzen a écrit :

le soucis n'est pas (ou pas forcément) qu'un processus intermédiaire s'est terminé avant que la fenêtre s'ouvre, mais que le PID associé à la fenêtre a comme PPID 0 Je n'savais pas que c'était possible.

C’est vraiment possible ça ?
Il me semblait que c'était seulement possible pour les processus kernel, pour les autres ils sont rattachés à init (donc PID 1).

Elzen · Le 28/10/2015, à 22:06

Après vérification de ma vérif, non, il semble que je me soit emmêlé les pinceaux sur le parsage de ps -f --pid X et que le processus en question ait bien 1 comme PPID. Ça m'étonnait aussi.

En revanche, après recherche rapide dans la doc, il semble que WNCK ne permette pas d'accéder à la propriété WM_CLIENT_MACHINE (ceci dit, ça fait deux messages d'affilée que je me sens un peu bête d'avoir mal vu un truc, donc il n'est pas impossible que j'ai encore loupé une info).
Si c'est avéré, ça voudra dire que :
– soit je fais un appel à la Xlib pour récupérer cette propriété, ce qui me paraîtrait un peu overkill, d'autant que, pour l'instant du moins, rien d'autre dans Tuco ne dépend directement de la Xlib,
– soit je continue d'ignorer cette propriété, sachant que les risques de conflits me semblent assez faibles.

grim7reaper · Le 29/10/2015, à 00:46

En effet, je n’ai rien vu dans WNCK à ce sujet donc ça voudrait dire qu’il faut faire appel à XGetWMClientMachine de la Xlib.
Je pense que c’est relativement sûr de poser l’hypothèse que tu n’as que des processus locaux (mais documente le clairement, ça aidera si un jour quelqu’un te remonte un bug à ce sujet).

Elzen · Le 29/10/2015, à 01:17

Yep, en effet, je vais rajouter ça.

Ceci dit, après réflexion, il se pourrait que j'ajoute une dépendance optionnelle à la Xlib dans Tuco, donc je pourrais quand même rajouter ce test au cas où (bien sûr, de telle sorte que ça ne provoque pas d'erreur si la Xlib n'est pas présente).

En fait, je m'étais dit que Tuco pourrait aussi servir à gérer des fichiers d'aides par jeu. Par exemple, pour les vieux jeux (S)NES sur lesquels il n'était pas possible d'enregistrer, mais où on devait se noter un mot de passe par niveau : je pensais donc permettre d'afficher une liste contenant tous les mots de passe du fichier.
Ceci dit, taper ces mots de passes pouvant être rébarbatif, ça pourrait être amusant de rajouter une option pour que, quand on sélectionne un mot de passe dans la liste, en supposant que le jeu soit dans le bon état, Tuco envoie tout seul une séquence d'événements X (type FakeInput, comme ce que j'ai utilisé pour joykeys) pour entrer le mot de passe dans l'émulateur.
Il faudra que j'étudie la faisabilité de la chose (parce que le système de saisie de mots de passe diffère selon les jeux, et qu'on n'a pas vraiment de manière de vérifier que tout est correct en dehors du rendu visuel auquel Tuco n'a pas accès), mais ça pourrait être une chouette fonctionnalité, et comme ça nécessiterait la Xlib, autant s'en servir aussi pour ce test-là.

(Sinon, je m'étais dit que la présence d'une seule des deux propriétés dans WNCK tenait peut-être du fait qu'ils aient un mécanisme de sécurité, i.e. que leur get_pid() ne renvoie quelque chose qu'après vérification du fait qu'on était bien sur la même machine. Mais vérification établie, ce n'est pas le cas : ça me renvoie bien le PID distant d'une fenêtre lancée depuis mon serveur, qui ne correspond à rien sur la machine locale).

Elzen · Le 11/11/2015, à 20:14

Bon, j'attendais voir si quelqu'un se manifestait, mais on dirait que je vais recommencer à double-poster ^^"

Donc, l'idée sus-mentionnée me semblant intéressante, j'ai fait quelques tests : j'arrive effectivement à utiliser Tuco pour taper des mots de passe dans certains jeux (par exemple, les codes qui changent l'apparence des zombies dans Plants Versus Zombies, ça marche bien).

En revanche, Mednafen ne semble absolument pas réagir aux faux appuis sur les touches, que je tâche de les gérer moi-même (avec ou sans xtest) ou que je passe par un outil tout fait du genre xvkbd ou xdotool. Je suppose que la bibli dans laquelle c'est codé ne lit pas le clavier par X, mais directement par le noyau, ou quelque chose comme ça.

En revanche, j'ai testé en Java avec la classe Robot, et ça fonctionne sans problème⁽¹⁾ ; donc ça doit bien être possible de faire autrement. Mais tout ce que j'ai trouvé jusque là en Python soit est spécifique à Windows, soit passe par la Xlib…

Edit : (1) enfin, sans problème, c'est beaucoup dire : le truc est mal coordonné, et dans l'immédiat, la séquence obtenue ne ressemble pas vraiment à ce que je lui demande. Mais c'est seulement le délai d'appui/relâchement des touches qui est mal fichu, et je ne vais pas me casser la tête à régler ça dans l'immédiat, vu qu'un truc qui marche en Java n'a pas énormément d'intérêt pour Tuco.

Dernière modification par Elzen (Le 11/11/2015, à 21:16)

Dafyd · Le 07/12/2015, à 22:19

fmt.Println("Hello World!")

Je souhaite améliorer mon Python en faisant quelques trucs GUI pour un petit projet, et je voulais avoir votre avis, PyGI ou PyQt ? De base je serai parti sur PyQt parce que j'en ai fait en C++ mais apres je ne connais pas la qualité du binding Python..

Elzen · Le 08/12/2015, à 00:55

Personnellement, je dois pouvoir dire du mal des deux, mais pas assez

Je connais très peu le monde Qt, mais j'ai trouvé assez désagréable les quelques fois où j'ai essayé de m'y mettre (principalement, j'ai l'impression que la logique fonctionne « à l'envers », du genre passer le parent à l'enfant à sa création, c'est simplement aberrant pour moi oO (ce qui tendrait à laisser penser que, si tu veux principalement faire des petits trucs et améliorer ton Python, et que tu es déjà habitué au Qt, c'est peut-être préférable d'y rester))

De l'autre côté, je commence à avoir une assez bonne pratique de PyGTK, mais GTK3 a tendance à me refroidir un peu. Principalement pour des raisons autres que le code (je n'ai toujours pas réussi à me faire un thème qui fonctionne comme je veux, donc c'est moche chez moi, donc j'évite) ; mais il y a quelques aspects qui me chiffonnent. Le fait que ce soit un binding générique en fait partie, encore que, après un import que je trouve assez moche, c'est plutôt bien fichu à l'utilisation ; mais il y a quelques options qui ont l'air d'avoir disparu (comme le fait de pouvoir aligner des onglets des deux côtés de la barre d'onglets, dont j'avais spécifiquement besoin sur le dernier programme que j'ai tenté d'écrire avec PyGI, ce qui fait que je suis revenu à PyGTK).

Ce qui fait qu'en ce qui me concerne, je cherche une autre bibli graphique ^^
Mais dans ton cas, J'pense que PyQt doit aller. Il a plutôt bonne réputation, à ma connaissance.

Sinon, concernant le soucis clavier évoqué au post précédent, à essayer de bidouiller un peu avec différentes biblis que j'ai pu trouver sur le sujet, je me suis dit que j'allais tenter de faire un clavier virtuel, pour le fun. J'ai trois trucs (partiellement) implémentés pour le moment : Xlib/Xtest, uinput (qui ne marche pas mieux que le précédent, à vue de nez ), et un truc passant par JPype pour utiliser le code Java. Autant dire que c'est encore problématique.

Dafyd · Le 08/12/2015, à 14:46

Merci bien pour cet avis éclairé !

Moi ce que je reprochais à Qt, c'est son aspect framework immense, qui fais tout et n'importe quoi, au point que le code ne ressemble plus que de loin à du C++.. Ca compile même pas sans le prépropesseur MOC de Qt d'ailleurs... GTK à l'air plus KISS du coup.
Du coup je suppose que PyGI est peut-etre plus... ciblé que PyQt non ?

Elzen · Le 08/12/2015, à 15:14

Hum. PyGTK, oui. PyGI, c'est plus discutable

À côté de la bibliothèque graphique GTK, il y a énormément de trucs aussi. Citons entre autres gstreamer, un énorme machin pour tout ce qui est lecture audio/vidéo ; WNCK, une chouette bibliothèque permettant d'interagir avec X de manière événementielle⁽¹⁾, ou encore les trucs dans la glib qui permettent entre autres de connaître et de lancer le logiciel par défaut associé à un type de fichier, tout ça.

Disons que, « from gi.repository import Gtk » doit être à peu près l'équivalent de « from PyQt import QtGui »

(Par contre, chaque composant est installable et gérable séparément, je ne suis pas sûr que ce soit le cas pour Qt)

(1) Très pratique pour faire un environnement graphique, c'est d'ailleurs l'un des trucs pour lesquels je ne sais pas comment je ferai quand j'aurai changé de bibli graphique pour Touhy, si je finis par le faire…

Dafyd · Le 08/12/2015, à 15:28

Bah Touhy est écrit en PyGTK, c'est à dire le binding Python 2 de Gtk2 non ? Et par dessus ça tu à utilisé wnck, Xlib, etc..
PyGI c'est le binding GObject Introspection, donc en gros de Gtk3 + pleins de trucs c'est bien ça ?
Donc si tu switch Touhy en GTK3, tu auras wnck avec PyGI, au lieu de l'avoir dans un module à part si j'ai bien compris.

Donc du coup ce serait moins galère que le switch PyGTK -> PyQt je suppose non ?

Elzen · Le 08/12/2015, à 16:16

Yep, si je passe à GTK3, le changement devrait pouvoir se faire de manière assez simple (d'ailleurs, je pourrais essayer de faire un script de conversion automatique de l'un vers l'autre, pour le fun, et voir ce que ça donnerait).

Le truc est que, comme mentionné plus haut, j'aimerais bien passer à une autre bibli graphique qui ne soit ni GTK, ni Qt. Encore faut-il la trouver ^^

Dafyd · Le 08/12/2015, à 16:48

WxWidgets est sympa aussi, et ya un binding Python. Après sinon, tu as des trucs comme FLTK ou Tk, mais bon, beaucoup plus simpliste.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2326 Le 05/10/2015, à 15:01

Re : /* Topic des codeurs [8] */

#2327 Le 13/10/2015, à 14:54

Re : /* Topic des codeurs [8] */

#2328 Le 17/10/2015, à 08:25

Re : /* Topic des codeurs [8] */

#2329 Le 17/10/2015, à 13:23

Re : /* Topic des codeurs [8] */

#2330 Le 21/10/2015, à 12:07

Re : /* Topic des codeurs [8] */

#2331 Le 21/10/2015, à 16:30

Re : /* Topic des codeurs [8] */

#2332 Le 21/10/2015, à 22:44

Re : /* Topic des codeurs [8] */

#2333 Le 22/10/2015, à 09:51

Re : /* Topic des codeurs [8] */

#2334 Le 22/10/2015, à 10:18

Re : /* Topic des codeurs [8] */

#2335 Le 22/10/2015, à 23:44

Re : /* Topic des codeurs [8] */

#2336 Le 25/10/2015, à 13:27

Re : /* Topic des codeurs [8] */

#2337 Le 27/10/2015, à 01:21

Re : /* Topic des codeurs [8] */

#2338 Le 27/10/2015, à 17:43

Re : /* Topic des codeurs [8] */

#2339 Le 28/10/2015, à 09:33

Re : /* Topic des codeurs [8] */

#2340 Le 28/10/2015, à 22:06

Re : /* Topic des codeurs [8] */

#2341 Le 29/10/2015, à 00:46

Re : /* Topic des codeurs [8] */

#2342 Le 29/10/2015, à 01:17

Re : /* Topic des codeurs [8] */

#2343 Le 11/11/2015, à 20:14

Re : /* Topic des codeurs [8] */

#2344 Le 07/12/2015, à 22:19

Re : /* Topic des codeurs [8] */

#2345 Le 08/12/2015, à 00:55

Re : /* Topic des codeurs [8] */

#2346 Le 08/12/2015, à 14:46

Re : /* Topic des codeurs [8] */

#2347 Le 08/12/2015, à 15:14

Re : /* Topic des codeurs [8] */

#2348 Le 08/12/2015, à 15:28

Re : /* Topic des codeurs [8] */

#2349 Le 08/12/2015, à 16:16

Re : /* Topic des codeurs [8] */

#2350 Le 08/12/2015, à 16:48

Re : /* Topic des codeurs [8] */

Pied de page des forums