J'ai cela aussi, c'est tout à fait normal.
Jean Bréfort a écrit 99 commentaires
-
# Normal.

-
[^] # Re: Encore vivant !

Le format ODS par défaut pose un certain nombre de problèmes, la norme ne définissant pas tout. De plus, le format gnumeric est plus simple à manier à de nombreux points de vue et de sauvegarder tout ce que Gnumeric supporte, ce qui n'est pas toujours le cas d'ODS. Maintenant si quelqu'un veut avoir ods par défaut, c'est possible en allant charcuter le fichier plugin.xml dans le répertoire du plugin openoffice : il suffit d'ajouter priority="100" après id="odf" et le tour est joué.
-
[^] # Re: Encore vivant !

Et si ! Même si cela manque un peu de sang neuf.
-
# Partitionnement manuel

Il faut choisir le partitionnement manuel. Indiquer pour chaque partition son type, son point de montage, et demander de reformater la partition / mais pas la partition /home.
-
[^] # Re: Lenteur de l'affichage

C'est beaucoup plus rapide avec un style alternatif, effectivement. Merci pour l'idée.
-
# Lenteur de l'affichage

Depuis quelques temps, l'affichage des pages de linuxfr est devenu très lent sur mon vieil ordinateur, jusqu'à secondes pour faire défiler d'une page. Combien de mémoire vive faut-il pour que cela aille bien ; sur mon portable, avec 4Go, ça roule tout seul, mais mon ordinosaure n'en a qu'un et là, quelle galère…
-
[^] # L'usage de libglade est déconseillé
libglade est dépréciée, et il est déconseillé de l'utiliser dans un nouveau projet. GTK+ a maintenant l'API nécessaire pour le remplacer : GtkBuilder.
Glade peut être utilisé pour créer les fichiers d'interface, même si tout n'est pas supporté. -
# gnumeric
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. -
# Réponses diverses
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. -
[^] # Re: -DPREFIX
euh, sans les ';'
DESF = -DPREFIX=\"$(prefix)\" -
# -DPREFIX
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). -
[^] # Re: objdump
objdump peut aussi être appliqué au programme appelant la bibliothèque et donnera la liste des symboles qu'il importe. -
# objdump
objdump avec l'option -T affiche les symboles dynamiques. -
[^] # Re: norme et implémentation
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. -
# norme et implémentation
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... -
# clavier qwerty
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. -
# canon et l'impression sous linux
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é). -
# gnumeric
Le tableur gnumeric (www.gnumeric.org) supporte les greffons écrits en Python. -
# linuxprinting.org
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 :-) -
# utiliser un lien symbolique
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é. -
[^] # Re: utilise le signal "size-allocate"
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); -
# faute de frappe ?
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 -
# utilise le signal "size-allocate"
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)
{
...
} -
# deux solutions
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 -
# commande utilisée ?
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.
