gdk_beep() reste silencieuse

Bonjour à tous,

Je voudrai pouvoir distribuer un programme qui émette des bips sans que l'utilisateur soit obligé de trafiquer son système, et que cela marche aussi bien sous Linux que sous Windows/MinGW.

Il y a bien longtemps, il suffisait d'émettre le caractère ASCII 07 (BELL) pour entendre sa machine "bipper". Cela a duré quelques dizaines d'années et fonctionnait quelque soit le langage utilisé.

Mais pourquoi faire simple quand on peut faire compliqué.

Maintenant cette méthode ne fonctionne plus, j'ai cru un temps avoir trouvé la solution en utilisant la fonction gdk_beep().
Hélas, je constate qu'avec Linux Mint18, la fonction gdk_beep() reste silencieuse, de même que la commande xkbbell (https://linux.die.net/man/1/xkbbell).
Je ne suis pas le seul, voir par exemple
https://forums.linuxmint.com/viewtop...?f=90&t=260785
ou
https://unix.stackexchange.com/quest...c-speaker-beep
ou
https://askubuntu.com/questions/1990...pt-not-working

La complexité de la gestion du son sous Linux, associée à celle de Xorg (https://www.x.org/releases/current/d.../xkbproto.html) me dépasse.

Si quelqu'un a une solution simple à me proposer, je suis preneur.

Bonjour,

je pense que le haut parleur interne est désactivé par défaut sur la plupart des distributions Linux, et c'est un changement volontaire qui a quelques années.

Voici quelques arguments en faveur de cette désactivation:
https://bugs.debian.org/cgi-bin/bugr...540831;msg=101

Ce bip peut sembler utile mais est insupportable quand tu n'en veux pas et ne trouves pas comment l'empêcher.
Le module du noyau qui le pilote est explicitement blacklisté, même sur de vieilles distributions (c'est blacklisté de base sur au moins Ubuntu 14.04 que j'ai sous les yeux).
C'est à l'utilisateur de choisir s'il veut ou non entendre ton beep, ce n'est pas à ton application de l'imposer. Je pense donc que tu ne trouveras pas de méthode pour contourner cela au niveau applicatif, en tout cas aucune d'acceptable pour l'utilisateur. Je ne me vois pas installer une application qui changerait la configuration par défaut de mon système juste pour m'imposer son beep.

Pour Linux, tu peux ajouter une dépendance optionnelle sur alsa-utils et utilser l'utilitaire aplay pour jouer un son en .ogg par exemple. Là ça passe par la carte son et ça peut s'activer/désactiver facilement. Si tu veux plus portable, tu peux dépendre de gstreamer sous Linux et MinGW.

Pour ajouter une petite pierre à la réponse de liberforce tu peux ajouter la bibliothèque SDL qui te permet de manipuler le son (mais pas que) assez facilement dans ton application.

Citation:

---

C'est à l'utilisateur de choisir s'il veut ou non entendre ton beep, ce n'est pas à ton application de l'imposer.

---

En fait, dans mon programme il y a une option pour activer/désactiver le bip.

Ce n'est d'ailleurs pas très original puisque c'est pareil avec Emacs: j'ai d'ailleurs le même problème avec lui. Moi, j'aime bien quand je fais une recherche itérative et que j'arrive en fin de fichier, avoir un bip pour me l'indiquer.
D'une manière générale, avoir la possibilité de régler si on émet un bip programme par programme me semble être une bonne chose.

Je vais étudier la bibliothèque SDL, mais je n'aime pas l'idée d'avoir à rajouter une bibliothèque de plus et je me demande si elle va fonctionner sous Windows.

Citation:

---

Pour Linux, tu peux ajouter une dépendance optionnelle sur alsa-utils et utilser l'utilitaire aplay pour jouer un son en .ogg

---

Merci pour l'info, je vais aussi regarder de ce coté, mais, comme je le craignais, tout cela me semble bien compliqué.

Citation:

---

Envoyé par pvincent

...
Je vais étudier la bibliothèque SDL, mais je n'aime pas l'idée d'avoir à rajouter une bibliothèque de plus et je me demande si elle va fonctionner sous Windows.

---

Il semblerait que la SDL soit aussi fonctionnelle sous Windows.

http://alexandre-laurent.developpez....configuration/

Merci de votre aide: elle m'a permis d'affiner mes réflexions et de faire un choix: la simplicité. Au lieu d'émettre un bip, je vais afficher dans la zone réservée à l'affichage du statut de GraceGTK un message informatif.
En fait, il s'agit plus d'autonomie que de simplicité.

C'est bien connu, en vieillissant on devient conservateur et ronchon: je vais donc argumenter en m'appuyant sur une aventure de Grace (http://plasma-gate.weizmann.ac.il/Grace/), l'ancêtre de GraceGTK.

Grace naquit il y a bien longtemps dans une contrée lointaine, Portland, Oregon. En ces temps reculés, Internet était encore balbutiant et Linux n'existait pas encore: il était prudent de distribuer avec ce logiciel, la bibliothèque T1lib et les polices nécessaires pour tracer des caractères. Le nombre de polices était donc limité, mais cela ne semblait guère gênant pour le travail de Grace: tracer des courbes.

Le temps passant un "maintainer" d'une distribution Linux eu l'idée d'émanciper Grace et de lui donner accès à toutes les polices présentes sur la machine. Cela semblait une bonne idée car il suffisait d'un tout petit script d'installation pour obtenir ce résultat.

Il y a peu, il advint que Grace, se promenant au royaume de Linux dans la province de Fedora buta sur une mise à jour, et tomba lourdement sur le sol: un véritable crash. L'urgentiste appelé promptement à son secours fit alors part de sa perplexité (https://bugzilla.redhat.com/show_bug.cgi?id=1502175).: la robuste campagnarde des origines était devenu, par la faute de ce petit script à l'allure innocente, une Marie-couche-toi-là comme la Parisienne de la chanson https://fr.wikipedia.org/wiki/La_Parisienne_(chanson) , forniquant avec d'autres logiciels. Pour recouvrer la santé, Grace devait subir une opération à coeur ouvert impliquant des connaissances bien au-delà de celles de l'urgentiste. Et pendant ce temps là, le tuteur de Grace, ES, qui n'avait bien sûr pas été consulté lors de l'émancipation de sa protégée, fait la sourde oreille...http://plasma-gate.weizmann.ac.il/Gr...php?f=3&t=3285

La morale de cette histoire, c'est que, n'ayant aucune compétence dans ce domaine (fonttool, ..) je n'ai pas trop envie de mettre le doigt dans cet engrenage et que pour l'instant, je me suis contenté de rajouter les polices qui me semblait manquer dans GraceGTK sans modifier le schéma initial,

Je suis bien conscient qu'on ne peut pas vivre indéfiniment hors du temps (le passage à GTK en est un exemple), mais je n'ai aucune compétence sur fonttool et les mécanismes liés au polices de caractères dans les différents systèmes (Unix like, Windows, etc). Ma priorité c'est de passer à Cairo d'abord, puis GTK-3, ce que je ne suis toujours pas parvenu à faire à cause d'un bogue rebelle que je n'arrive pas à cerner. Mais ceci est une autre histoire qui mériterai sans doute un autre post.

Quoi qu'il en soit votre aide me permet de considérer ce post comme résolu, mais je ne trouve pas de bouton pour le signaler.

Merci pour ces informations sur le contexte, c'est très intéressant. J'ai lu le rapport de bug, et tes anciens posts sur le sujet c'est vrai qu'une application très peu maintenue devient difficile à étendre et à faire survivre. Tu as sorti le respirateur pour pouvoir essayer de donner une seconde vie à Grace, mais il y a effectivement encore beaucoup à faire (je viens de jeter un coup d'oeil au code). Au delà de l'âge du code d'origine, le fait que le code source des projets soit difficile à accéder pose un problème pour trouver des contributeurs. Grace n'a l'air de fournir qu'un FTP synchronisé avec des livraisons en tar.gz, et pour GraceGTK j'ai trouvé ton sourceforce mais qui n'héberge que des releases aussi, le gestionnaire de version intégré reste vide...

Au passage en cherchant GraceGTK je suis tombé là dessus.
https://github.com/mwh/grace-gtk

Je ne sais pas trop comment ça s'interface avec ce que tu fais mais je vois qu'il utilise du GTK+ 3.

Voilà, bon courage à toi, je pense que la route va être longue :)

EDIT: Le grace-gtk du lien semble ne pas avoir de rapport, grace semble aussi être le nom d'un langage de programmation

Merci Liberforce pour ton intérêt.

Apparemment, minigrace et grace-gtk n'ont rien à voir avec le logiciel dont il est question ici: ces neo-z ont utilisé le nom de Grace pour désigner un langage de leur cru (https://michael.homer.nz/Thesis).

J'ai pendant longtemps utilisé CVS et je suis passé à GIT assez récemment. Il y deux raisons pour lesquelles je n'ai pas encore placé de version GIT sur Sourceforge.
Le choix des noms dans Grace est assez désordonné, (j'ai lu dans le temps un commentaire sur le Net comme quoi Grace était dificile à maintenir, ce qui n'est pas faux.), ce qui m'a incité à procéder dans GraceGTK à des renommages assez intensifs qui ne sont pas encore terminés (y compris sur les noms de fichiers). Le résultat est un arbre GIT plus compliqué que le code lui même et sans grand intérêt si on n'est pas familier avec le code original de Grace. Mon idée, c'est de publier un arbre Git nouveau quand je serai suffisamment satisfait de mon code pour éviter à un nouvel entrant de perdre son temps à s'initier à des ensembles de noms plutôt disparates. De plus le passage de GTK-2 à GTK-3 risque d'induire lui aussi pas mal changements.
La deuxième raison, c'est tout simplement la flemme: installer GIT suppose ensuite d'en gérer les conséquences (commit de propositions venant de l'extérieur,...) alors que je ne suis pas habitué à cela (j'utilise l'interface Emacs git.el) et guère disposer à en devenir dépendant.

Enfin je plaide coupable: ce qui m'amuse, c'est d'ajouter de nouvelles possibilités et non de peaufiner le code.