jlh a écrit 55 commentaires

La fonction connect a pour prototype :
def connect(signal, callback, arg1, arg2, ....)

Essaies :
bouton1.connect("clicked", self.enter_callback, champsaisie1, champsaisie2, champsaisie3, champsaisie4, champsaisie5, champsaisie6)

Tu trouveras la documentation de pyGtk à l'adresse :
http://www.pygtk.org/pygtk2reference/index.html

Pour savoir quels plugins sont présents , il faut taper "about:plugins" dans la barre d'adresse de firefox.

Parmis les fichiers installés avec java, il doit y en avoir un qui s'appelle : libjavaplugin_oji.so
Il faut créer, dans un répertoire plugins de firefox, un lien symbolique vers ce fichier libjavaplugin_oji.so.

Il y a plusieurs répertoire plugins pour firefox. Il y en a 1 par compte utilisateur (dans /home/nom_utilisateur/.mozilla/plugins chez moi) qui contient les plugins visibles que par l'utilisateur
et 1 dans le répertoire d'installation de firefox (/usr/lib/mozilla-firefox/plugins sur ma gentoo) pour tous les utilisateurs de la machine.

A toi de voir où créer le lien en fonction de ce que tu veux.

La bibliothèque glib contient beaucoup de fonctions toutes prêtes pour gérer les chaînes de caractères et elle doit sûrement déjà être installée sur ton PC (suivant la distrib que tu utilises, il peut manquer les paquets de developpement).

voir http://developer.gnome.org/doc/API/2.0/glib/index.html/
pour la documentation de l'api (en anglais malheureusement)
notamment la partie "String utility fonction".

C'est dans la fonction connectée au signal "clicked" du bouton1 qu'il faut récupérer le contenu de chaque GtkEntry. Comme fait dans ton code actuel, un clic sur le bouton1 quitte l'application.

Quelque chose du genre :
bouton1.connect("clicked", fct_sauver_entrees)

avec :
def fct_sauver_entrees():
text1 = champsaisie1.get_text()
text2 = champsaisie2.get_text()
text3 = champsaisie3.get_text()

etc ...

Il semblerait que le device /dev/md0 soit déjà associé à un tableau de disques. Pour en être sûr, il faudrait regarder dans le fichier /proc/mdstat (avec la commande : cat /proc/mdstat) pour voir l'état du Raid sur la machine.

(Il se peut que le kernel est fait le travail tout seul après un redémarrage si les partitions utilisées pour le raid sont marquées comme étant du type "Linux raid autodetect" et que plusieurs essais aient été faits avant).

Il faut utiliser la commande mdadm --stop /dev/md0 pour "arrêter" le raid.

Je persiste ....
Il doit y avoir une ligne ressemblant à ce que j'obtiens chez moi (carte mère Gigabyte GA-K8NXP-9 avec aussi un ALC850):
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)
Subsystem: Giga-byte Technology Unknown device ae01

parmis la sortie de la commande lspci -v (avec un seul v c'est plus conçis).

Tu peux aussi tenter un :
modprobe snd-intel8x0
dans un terminal en root et voir le résultat.

Ou alors, on peut faire comme décrit là -> http://forum.ubuntu-fr.org/viewtopic.php?id=28784
mais c'est beaucoup plus complqué ...

Le module snd_intel8x0.ko devrait fonctionner avec cette carte son (voir sound/pci/ac97/ac97_id.h dans les sources du kernel et http://www.flaterco.com/kb/audio.html )

Cette carte réseau est aussi sur les cartes mères ASUS A8V-MX, et est reconnue sous windows comme une carte VIA-Rhine II Fast Ethernet.

Alors que la version RTL8201 (pas CL) est prise en charge par le module sis190.ko sous Linux .....Allez comprendre .....

Essaies lspci -vv (2 v pas 1 w) pour savoir sous quel nom est reconnu le RTL8201CL, ça peut aider....

En faisant comme ça, tu ne fais que sauver un pointeur (l'adresse ou est stocké le gtkliststore) mais pas le contenu. Voici un exemple, chaque ligne contient 2 colonnes (nom, prénom), à toi de l'adapter à tes besoins :

#define  COLONNE_NOM (0)
#define COLONNE_PRENOM (1)

gboolean sauver_element(GtkTreeModel *model, GtkTreePath *path, GtkTreeIter *iter, gpointer data)
{
  FILE *fp = (FILE *)data;
  gchar *nom, *prenom;

  gtk_tree_model_get(model, iter, COLONNE_NOM, &nom, COLONNE_PRENOM, &prenom, -1);

  fprintf(fp, "%s\t%s\n", nom, prenom);

  g_free(nom);
  g_free(prenom);

  return(FALSE);
} 

void sauver_liste(GtkTreeModel *list_store, const gchar *filename)
{
  FILE *fp;

  fp = fopen(filename, "w");

  if (!fp) return;

  gtk_tree_model_foreach(list_store, 
			 (GtkTreeModelForeachFunc) sauver_element,
			 fp);

  fclose(fp);
}

void charger_liste(GtkListStore *list, const gchar *filename)
{
  FILE *fp;
  GtkTreeIter iter;
  gchar nom[256], prenom[256];

  fp = fopen(filename, "r");

  if (!fp) return;

  while(!feof(fp)) {
    fscanf(fp, "%s\t%s\n", nom, prenom);

    gtk_list_store_append(list, &iter);
    gtk_list_store_set(list, &iter, 
		       COLONNE_NOM, nom,
		       COLONNE_PRENOM, prenom,
		       -1);

  }

  fclose(fp);
}

A cette adresse, tu trouveras un tutoriel (en anglais) sur l'utilisation des GtkTreeView, etc .... http://scentric.net/tutorial/treeview-tutorial.html

Il existe la librairie SDL (http://www.libsdl.org ) qui fait ça très bien et même beaucoup plus (2D, 3D, ...).

Il y a même un tutoriel en français à cette adresse :
http://tastalian.free.fr/cours.php?part=SDL&index=6
et sûrement plein d'autres ailleurs.

Pourquoi le noyau qui marche est dans le répertoire /boot (image=/boot/vmlinuz-2.6.12-1-k7) avec le ramdisk (initrd=/boot/initrd.img-2.6.12-1-k7) et pas celui qui ne marche pas (image=/vmlinuz et initrd=/initrd.img) ?

Il se pourrait aussi que les droits sur le fichier Xorg (/usr/bin/Xorg chez moi) ne soient pas corrects.
Normalement le serveur X est lancé avec les droits de l'utilisateur root même lorsque c'est un autre utilisateur qui l'execute. Pour cela, il faut que les droits de l'executable Xorg soient : -rws--x--x root root (le bit setuid est mis)
Reste plus qu'à vérifier que c'est bien le cas chez toi.

Vérifies si les polices ne se trouveraient pas dans /usr/share/X11/fonts plutôt que dans /usr/lib/X11/fonts et modifies le fichier xorg.conf en conséquence.

Je pense qu'il faut modifier ta règle en remplacant NAME="input/event5" par NAME="input/%k", comme ça tu ne modifies pas le nom du device créé par le kernel.
Et il faut que tu utilise le lien symbolique "input/touchscreen" dans ton fichier xorg.conf. Le lien symbolique sera le seul élément qui n'aura pas changé entre 2 branchements, quelque soit le nom donné au device par le kernel, le lien doit pointé vers lui.

(En même temps, je ne crois pas que le serveur X supporte le branchement à chaud de nouveaux périphériques)

La règle que je t'ai donné n'est pas bonne, elle créée un lien vers le mauvais device, /dev/ts1 est utilisé par le driver de ton écran tactile et se trouve dans /dev/input/ normalement (le NAME="%k" dans ma règle l'a déplacé dans /dev, pour qu'il apparaisse dans /dev/input il faudrait mettre NAME="input/%k")

M'enfin ça n'est pas ce device qui nous intéresse ...

Essaies : udevinfo -q path -n /dev/input/event??
Tu devrais obtenir un chemin dans le répertoire /sys , du genre
/class/input/.....

Aprés : udevinfo -ap /sys/class/le chemin obtenu précedemment
et tu devrais avoir d'autres infos pour écrire une règle pour udev, la bonne cette fois ....

Bonne chance.

/dev/touchscreen pointe bien vers /dev/input/event3 ??

Si oui , il faudrait comparer le fichier /var/log/Xorg.0.log avec /dev/input/event3
et avec /dev/touchscreen pour voir si xorg paramètre ton device de la même façon dans les 2 cas.

Essaies :
BUS=="usb", SYSFS{manufacturer}=="eGalax Inc.", SYSFS{configuration}=="USB TouchScreen", NAME="%k", SYMLINK="touchscreen"

Cette règle devrait créer un lien symbolique appelé "touchscreen" dans /dev pointant vers ton device quelque soit le nom que le kernel lui attribue au départ.

C'est plutôt dans le répertoire /sys qu'il faut chercher des infos pour créer des règles pour udev,
Mais il existe udevinfo qui vient avec le package udev.
Essaies : udevinfo -ap /sys/class/input/input3/device/
Tu devrais obtenir une liste de paramètres utilisable pour créer une règle.

Et tu pourras tester la règle que tu auras créée avec :
udevtest /sys/class/input/input3/

Pour des infos plus détaillées voir http://www.reactivated.net/writing_udev_rules.html (en anglais)

Les packages pour Mandrake ont une extension en "rpm" (comme la distribution Fedora d'ailleurs ).
Et tu trouveras sûrement les autres réponses à tes interrogations dans les archives de la partie Mandriva du forum (nouveau nom de la Mandrake) voire même dans la doc sur le site de Mandriva.

Bonne chance.

Ça ressemble à un problème de température du processeur qui bloque quand il est trop chaud. Il faudrait monitorer
la température du processeur et des autres éléments du PC et peut-être enlever la poussière qui a du s'accumuler dans le radiateur du processeur.

Je ne sais pas si c'est un bug ou pas mais j'ai regardé comment cette fonction était utilisée par la bibliothèque pango et le contenu de la variable "res" n'est pas vérifié après l'appel de cette fonction.
Ils se contentent de vérifier que le pointeur "font_pat" n'est pas nul au retour de la fonction.

Il semblerait que la variable res n'est pas modifiée par la fonction FcFontMatch.
Si on l'initialise à -1, elle reste toujours à -1 et l'assertion n'est jamais vérifiée.

Dans ton programme, la variable res est initialisée à 0 dans un cas, ce qui correspond à FcResultMatch et ça marche, et dans l'autre cas, res est initialisée à une autre valeur et ça ne marche plus.

Ça doit être lié à l'état de la pile du programme où sont stockées les variables, ou à gcc ...

Tu trouveras un paquet pour Debian à l'adresse suivante :
http://messenger.yahoo.com/messenger/download/unix.html(...)
(version 1.0.4) qui doit pouvoir s'installer sur Ubuntu (sans garantie, je n'ai pas essayé).

Une version 1.0.6 est sortie plus récemment, mais seulement pour
redhat, que tu trouveras là :
http://public.yahoo.com/~mmk/(...)
avec quelques explications (en anglais) pour transformer le rpm en un paquet deb.

Mais Yahoo messenger pour Linux n'est pas au niveau de la version
pour Windows (pas de support des webcams, etc ...) et, comme dit plus haut, Gaim ou Kopete
peuvent être utilisés à la place.