Jean Bréfort a écrit 116 commentaires

Gnumeric permet de faire un certain nombre de diagrammes, y compris de vrais histogrammes, des boîtes à moustaches et des tracés de probabilités. De plus les graphiques peuvent être directement exportés dans divers formats, dont svg, eps et pdf.

En ce qui concerne OpenFormula, c'est Andreas Guelzow qui s'occupe de son implémentation dans Gnumeric, mais évidemment, cela ne pourra être complet que lorsque la norme sera publiée. Récemment, il m'a dit que participer à deux réunions hebdomadaires pour la finalisation d'OpenFormula était particulièrement frustrant, je n'ai pas demandé de détails, donc je n'en sais pas plus.

Pour le site web, les volontaires pour le moderniser sont les bienvenus. Personne dans la petite équipe de développement de Gnumeric n'a l'intention de s'en occuper à ma connaissance.

euh, sans les ';'

DESF = -DPREFIX=\"$(prefix)\"

Le plus simple est de passer le variable sur la ligne de commande de gcc. Dans Makefile.am, on peut faire ça avec la variable DEFS :

DEFS = -DPREFIX=\";$(prefix)\";

(en fait je n'ai jamais essayé avec prefix, il vaut mieux utiliser datadir, libdir, includedir ou autre selon l'utilisation).

objdump peut aussi être appliqué au programme appelant la bibliothèque et donnera la liste des symboles qu'il importe.

objdump avec l'option -T affiche les symboles dynamiques.

Personnellement, je ne crois pas qu'un format de fichier universel soit tout simplement faisable et, de plus, je n'ai ni les compétences ni le temps pour participer à ce genre de choses.

J'interviens ici à titre personnel, et mon opinion peut différer de celles des autres membres de Gnome Office. Le principal souci avec tous les formats, ODF ou ceux de M$ est que la norme est une chose, et l'implémentation qui en est faite en est une autre. Pourquoi investir plein d'énergie pour changer de format si on va devoir mettre en place une implémentation du format qui ne serait pas forcément compatible avec celle mise en place par les autres projets, propriétaires ou non.

Pour me limiter à ce que je connais bien, les graphiques utilisés dans Gnome Office possèdent de nombreuses fonctionnalités qui nécessiteraient un nouveau vocabulaire par rapport à la norme OpenDocument. En résumé, on pourrait faire des documents conformes à la normes, mais peu compatibles avec les autres projets.

Notre choix est différent. Nous gardons nos formats simples et nous traitons tous les autres formats comme des formats externes dans lesquels nous essayons d'importer et d'exporter tout ce qui est possible.

Maintenant, l'avenir sera peut-être différent. Si quelqu'un se porte volontaire pour développer une implémentation d'ODF pour Gnome Office, pourquoi pas ? Il y aura sûrement des résistances, mais si ça fonctionne...

Le mot de passe contient peut-être des caractères comme 'a', ou 'm' qui ne sont pas à la même place sur un clavier querty que sur un azerty ?
Le mappage par défaut est querty et c'est celui-ci qui est actif à ce moment de la procédure de démarrage.

Le site de référence est http://linuxprinting.org.

Ceci dit, la S750 n'y est pas référencée. En tout état de cause, peu d'imprimantes Canon sont correctement supportées sous Linux. Canon a toujours refusé de fournir la documentation indispensable ou de développer les pilotes.

Il y a plus de chances de faire fonctionner une imprimante HP ou Epson. Voir http://linuxprinting.org/suggested.html pour plus de précisions.

Je ne vois pas de solution idéale dans le cas présent. Je peux suggérer :

1) changer d'imprimante ;
2) faire pression sur Canon ;
3) essayer avec un pilote adapté à une imprimante voisine (risqué).

Le tableur gnumeric (www.gnumeric.org) supporte les greffons écrits en Python.

Pour savoir si une imprimante est supportée, c'est le site à consulter. Le lien pour ton imprimante est :
http://linuxprinting.org/show_printer.cgi?recnum=Epson-Stylu(...)

La bonne nouvelle c'est que ça marche mostly).

Pour la fonction scanner :
http://www.sane-project.org/sane-mfgs.html#Z-EPSON

La aussi, ça devrait fonctionner correctement :-)

La solution la plus évidente consiste à créer un lien symbolique dans /var/www vers un répertoire /home/compte :
ln -sf /home/compte /var/www/compte

Cependant, il faut faire très attention aux problèmes de droits d'accès, pour être certain que l'utilisateur ne peut pas accéder au répertoire supérieur (lcd .. remonte vers la véritable racine, donc ici /home pour autant que je sache). Je ne suis pas un spécialiste, donc je reste prudent, mais je suspecte un problème de sécurité.

Je pense que tu dois utiliser une GtkHBox avec une hauteur fixe que tu mets dans une GtkVBox.
Le code ci-dessous a été généré par glade et tu dois pouvoir t'en inspirer :

window1 = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_set_title (GTK_WINDOW (window1), _("window1"));

vbox1 = gtk_vbox_new (FALSE, 0);
gtk_widget_show (vbox1);
gtk_container_add (GTK_CONTAINER (window1), vbox1);

hbox1 = gtk_hbox_new (FALSE, 0);
gtk_widget_show (hbox1);
gtk_box_pack_start (GTK_BOX (vbox1), hbox1, FALSE, FALSE, 0);
gtk_widget_set_size_request (hbox1, -1, 73);

dans le premier cas, tu assignes une valeur à $chaine, mais tu testes $chainelu alors que dans le second, il manque quelques points-virgules.

Chez moi le code suivant fonctionne (sous bash) :
#!/bin/sh
read ligne
chaine=`expr substr "${ligne}" 1 6`
case "$chaine" in
"APPEND")
echo "---------append--------------" ;;
"01 ELE")
echo "---------01 ele--------------" ;;
"END")
echo "-------------end--------------" ;;
*)
echo "$ligne";;
esac

Pour ce genre de choses, j'utilise le signal "size-allocate" avec un callback de signature :

void size_allocate_cb (GtkWidget *widget, GtkAllocation *alloc, gpointer data)
{
...
}

La première essayer de chercher ce qui ne va pas dans configure, la seconde, plus simple, est de faire un rapport de bogue sur http://bugs.gentoo.org

C'est très étrange, je ne constate pas ce genre de problème.

Deux causes possibles me viennent à l'esprit :
- un problème dans ton code source;
- un problème avec la ligne de commande utilisée pour compiler.

Sans plus de détails sur les deux, difficile d'avoir une idée quand on n'a pas rencontré le même problème.

Pour autant que je sache, il faut dire à grub où il doit trouver le kernel avant la commande setup. Par exemple :

grub>root (hd0,5)
grub>kernel (hd0,5)/boot/vmlinuz (le noyau n'est pas forcément là)
grub>setup (hd0)

Quel(s) est(sont) le(s) message(s) d'erreur(s) ?

normalement, tu devrais taper :
tar xzvf unison-2.13.1.tar.gz
L'option Z correspond, si ma mémoire est bonne à des fichiers en tar.Z.

Ensuite,
.configure
make
sudo make install

En effet,le répertoire d'installation par défaut est /usr/local et normalement, l'utilisateur lambda n'a pas le droit d'écriture sur ce répertoire.

Oops, je voulais dire 3490.

J'ai acheté récemment un epson perfection 3400 photo, et ça marche raisonnablement bien.

glib possède une fonction qui fait ça :

gchar** g_strsplit (const gchar *string,
const gchar *delimiter,
gint max_tokens);

Tu peux regarder le code correspondant dans glib/gstrfuncs.c

dans la doc de grub-install, il y a un exemple du type :
grub-install hd0

Tu peux peut-être utiliser l'option --force-lba ?

info grub-install te donnera plus de détails.