et puisque j'y suis, j'utilise le driver libre radeon sur un radeon 9250 128 mo agp.
Chez moi, c'est pilote libre + ATI radeon 7000 en 16 bits par pixel, et ça marche plutôt pas mal.
Il y a des bugs génants, comme celui de la video que tu as évoqué, ou l'applet de gestion des espaces de travail qui ne fonctionne pas.
Mais sinon, c'est tout à fait utilisable, un poil moins rapide peut-être pour le redimensionnement des fenêtres, mais ça utilise moins de cpu pour le déplacement.
Ils ont embauché quelqu'un des chez SEB pour le design de l'engin, non ? Ça ressemble à une friteuse...
Les proportions sont curieuses. Comme apparemment on peut y brancher clavier et écran, j'aurai plutôt vu quelque chose de plat pouvant servir de pied à l'écran.
...je trouve débile de publier des communiqués uniquement en anglais, surtout lorsque l'on est côté sur le marché boursier français, et que l'on s'adresse donc en priorité à des boursicoteurs français.
Ben justement, si tu t'adresses à des boursicoteurs français, vaut certainement mieux planquer tes origines françaises, ça ne doit pas aider à faire venir de l'argent.
En anglais, c'est plus prestige, international, toussa...
Je me demande finalement ce qui est le pire. "Orca" pour la gestion de l'accessibilité ? "Tomboy" pour la prise de note ?
Pour Orca, je ne sais pas.
Pour Tomboy, je ne suis pas sur, mais ça semble avoir un rapport avec Tintin, Tom dans la version anglaise, reporter et donc preneur de notes...
Mais, bon, aussi, est-ce que c'est vraiment important ?
C'est le nom du projet, laisse aux développeurs le plaisir de choisir le nom qu'ils veulent.
De toutes façons, dans le menu, le nom de l'application est précédé de sa fonction (navigateur web Epiphany, notes Tomboy, lecteur de nouvelles Pan), donc ça ne pose pas de problème.
Ornythorinque, pour le tableur, c'est plutôt pas mal... Il faut que je propose ça au responsable de gnumeric. :)
Pour regarder des films, c'est parfait, *a condition de très bien réencoder le film*. Il faudrait d'ailleur que je partage les options mencoder de mon script (repris sur un autre).
Quelqu'un sait d'ailleur pourquoi "tout le monde" s'entete a vouloir réencoder les films en 15 images/sec, alors que ca donnera _forcément_ un résultat pourri ? bref, j'ai changé les options, et ca donne du 24 images/sec qui donne un résultat parfait. Mais ca fait 2 mois que je dois écrire un mail a l'auteur original.
Si tu as des astuces/infos, n'hésite pas à en faire profiter tout le monde en mettant à jour le wiki de maemo:
Il y a aussi la documentation de libglade, au cas où... :)
Si tu ne l'as pas encore installé, je te conseille très vivement devhelp. C'est un outil indispensable. Et encore plus utile maintenant qu'il est accessible directement depuis glade-3.
Reste que les fichiers créés par glade contiennent les propriétés de la fenêtre utilisée par glade, inutiles donc, et qui augmentent la taille du fichier XML.
Il est apparemment possible avec glade 3 de supprimer la fenêtre englobante (avec un petit copier/supprimer/coller), mais il n'est plus possible de visualiser les widgets, ce qui limite un peu l'intérêt de la chose...
Ça, ce n'est pas une documentation. Juste une liste de fonctions avec un ptit commentaire.
Ben, si, c'est le manuel de référence. Il y a des exemples (pas assez nombreux, c'est vrai), il y un texte d'introduction pour chaque module, chaque fonction est documentée (ce qui n'est pas le cas de libgnomeprint).
Non, ce n'est pas juste une liste de fonctions qui prennent certains types en paramètres et retournent certains types.
Faut pas être de trop mauvaise foie quand même.
Je suis d'accord sur le fait qu'il faudrait un texte d'introduction expliquant l'ensemble de l'API et l'intérêt de chaque objet, et que ça peut être plus détaillé.
Juste une API similaire.
Avec cette nouvelle API, les développeurs avaient des objectifs qui les ont fait s'écarter de l'API libgnomeprint, comme le support multiplateforme.
L'API graphique de libgnomeprint est tout de même très similaire à celle de cairo.
Ceci dit, si les performances et les fonctionnalités de cairo et d'arthur sont équivalentes, alors oui ça serait vraiment super qu'on puisse converger vers une solution commune.
Même si ça n'existe pas, c'est de toutes façons pas très dur à implémenter. Ça viendra vite si quelqu'un est intéressé...
Une autre question, est-ce que c'est dépendant de Qt, ou bien est-ce que les dépendances sont plus légères, comme cairo ? (fontconfig et libpng si je me souviens bien).
Merci d'avoir laissé tomber la bibliothèque vieillissante libgnomeprint.
Merci d'avoir fait le choix d'utiliser cairo pour le support de l'impression.
Merci, car grace à ce choix, aucun des logiciels ayant besoin d'une possibilité d'impression n'aura besoin de réimplémenter une couche d'abstraction pour l'affichage et l'impression.
Merci enfin de laisser les râleurs raler, sachant que libgnomeprint est toujours là et est toujours utilisable.
Enfin, quoi, Colin, tu es vraiment satisfait de libgnomeprint ?
Qu'est-ce que tu voulais ?
Penses-tu vraiment qu'il était possible de faire évoluer libgnomeprint pour le mettre dans un état plus présentable ? Penses-tu vraiment qu'il y a suffisamment de ressources humaines pour ça ?
Parce que justement là ils abusent des images : même le texte est mis sous forme d'image, non sélectionnable donc...
Le texte n'est pas sous forme d'image, se sont des bouts de polices embarquées.
Mis à part le texte d'entête et de bas de page, qui sont des effectivement des images, mais seulement parce que la police est de type bitmap.
Concernant le problème de sélection, c'est effectivement un bug, qui sera peut-être corrigé dans une prochaine version de la série 1.2, si ça n'implique pas de trop gros changement.
L'objectif de cette série stable étant une bonne qualité de rendu, notamment en vue de l'utilisation par le module d'impression de gtk 2.10. Ce problème n'a donc pas été considéré comme bloquant.
Le backend image va tracer une ligne en modifiant les octets d'un espace mémoire correspondant à une image.
Le backend SVG lui, va stocker dans un fichier le code SVG qui décrit cette ligne, quelque chose du genre:
L'intérêt d'une biliothèque graphique avec backend, c'est qu'en gros, le code pour tracer ne change pas, il suffit simplement de créer la surface correspondant au type sortie souhaité (cairo_image_surface_create ou cairo_svg_surface_create dans ce cas).
Note aussi le bel exemple de politiquement correct (qui ne date pas d'hier, d'ailleurs): le grand industriel français de la défense... Moui, de la défense, bien sûr... jamais de l'attaque, hein, jamais ?
Pour la conversion de pdf vers svg, il va bientôt exister une alternative libre, grâce à la prochaine version stable de cairo ( http://cairographics.org ), et à la bibliothèque poppler ( http://poppler.freedesktop.org/ ).
poppler possède un backend cairo, qui lui même aura un backend SVG.
Il y a déjà dans le répertoire tests de la version de développement de cairo un petit utilitaire rudimentaire pdf2svg qui fait cette conversion.
Les résultats sont corrects visuellement. Par contre le fichier SVG généré n'est pas vraiment optimisé (les textes sont convertis en chemins (c'est une limitation du backend SVG de cairo), et les dégradés en couches sucessives d'objets de couleurs différentes (limitation de poppler)).
(ce la ne dépend-il que des développeur ou son-il bloqué par le format svg) ?
A la question le format SVG est-il bloquant, la réponse est oui, et non.
Oui, parce que pour être lu par autre chose qu'inkscape, il faut produire du SVG conforme. Donc pour des effets qui n'existent pas dans SVG, il faut utiliser des moyens détournés, comme la conversion de texte en chemin, ou le rendu par une image de substitution en mode point.
Non, parce que le format SVG d'inkscape inclu des champs supplémentaires qui permettent de conserver les paramètres de l'effet. Il n'y a donc en théorie aucune limite liée au format de sauvegarde.
[^] # Re: oubli
Posté par EmmanuelP . En réponse au journal compiz et aiglx dans ma sid box !. Évalué à 1.
Chez moi, c'est pilote libre + ATI radeon 7000 en 16 bits par pixel, et ça marche plutôt pas mal.
Il y a des bugs génants, comme celui de la video que tu as évoqué, ou l'applet de gestion des espaces de travail qui ne fonctionne pas.
Mais sinon, c'est tout à fait utilisable, un poil moins rapide peut-être pour le redimensionnement des fenêtres, mais ça utilise moins de cpu pour le déplacement.
# Design
Posté par EmmanuelP . En réponse au journal Neuf-Cegetel propose une ADSL-box/PC à base de Linux. Évalué à 5.
Les proportions sont curieuses. Comme apparemment on peut y brancher clavier et écran, j'aurai plutôt vu quelque chose de plat pouvant servir de pied à l'écran.
[^] # Re: EN vs FR
Posté par EmmanuelP . En réponse au journal Du carton d'Ubuntu à la braderie de Lille. Évalué à 1.
Ben justement, si tu t'adresses à des boursicoteurs français, vaut certainement mieux planquer tes origines françaises, ça ne doit pas aider à faire venir de l'argent.
En anglais, c'est plus prestige, international, toussa...
[^] # Re: Nommage des applications
Posté par EmmanuelP . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 2.
Pour Orca, je ne sais pas.
Pour Tomboy, je ne suis pas sur, mais ça semble avoir un rapport avec Tintin, Tom dans la version anglaise, reporter et donc preneur de notes...
Mais, bon, aussi, est-ce que c'est vraiment important ?
C'est le nom du projet, laisse aux développeurs le plaisir de choisir le nom qu'ils veulent.
De toutes façons, dans le menu, le nom de l'application est précédé de sa fonction (navigateur web Epiphany, notes Tomboy, lecteur de nouvelles Pan), donc ça ne pose pas de problème.
Ornythorinque, pour le tableur, c'est plutôt pas mal... Il faut que je propose ça au responsable de gnumeric. :)
[^] # Re: pour la portabilité
Posté par EmmanuelP . En réponse au journal Loi de Murphy, ou presque.. Évalué à 2.
Quelqu'un sait d'ailleur pourquoi "tout le monde" s'entete a vouloir réencoder les films en 15 images/sec, alors que ca donnera _forcément_ un résultat pourri ? bref, j'ai changé les options, et ca donne du 24 images/sec qui donne un résultat parfait. Mais ca fait 2 mois que je dois écrire un mail a l'auteur original.
Si tu as des astuces/infos, n'hésite pas à en faire profiter tout le monde en mettant à jour le wiki de maemo:
http://maemo.org/maemowiki/VideoEncoding?highlight=%28video%(...)
[^] # Re: à tester
Posté par EmmanuelP . En réponse à la dépêche Glade 3 : l'échappée belle. Évalué à 1.
Il y a aussi la documentation de libglade, au cas où... :)
Si tu ne l'as pas encore installé, je te conseille très vivement devhelp. C'est un outil indispensable. Et encore plus utile maintenant qu'il est accessible directement depuis glade-3.
[^] # Re: à tester
Posté par EmmanuelP . En réponse à la dépêche Glade 3 : l'échappée belle. Évalué à 2.
gui = glade_xml_new (filename, "mon-widget", NULL);
Reste que les fichiers créés par glade contiennent les propriétés de la fenêtre utilisée par glade, inutiles donc, et qui augmentent la taille du fichier XML.
Il est apparemment possible avec glade 3 de supprimer la fenêtre englobante (avec un petit copier/supprimer/coller), mais il n'est plus possible de visualiser les widgets, ce qui limite un peu l'intérêt de la chose...
[^] # Re: où?
Posté par EmmanuelP . En réponse au journal don de matos informatique .... Évalué à 2.
# Bindings
Posté par EmmanuelP . En réponse au journal Mono et Gnome. Évalué à 10.
- Java-gnome (Java)
- gtkmm (C++)
- pygtk (Python)
- gtk2-perl (Perl)
Maintenant il y a en plus gtk# (C#).
La belle affaire...
[^] # Re: C'est une bonne nouvelle.
Posté par EmmanuelP . En réponse au journal ODF en console \O/. Évalué à 2.
Oui, enfin, on peut remplacer un caractère par un autre avec vi, pas beaucoup plus.
[^] # Re: Et si...
Posté par EmmanuelP . En réponse au journal Geoportail : faire des liens avec GreaseMonkey. Évalué à 1.
Oui, enfin, à mon avis, si les liens directs ne sont pas possibles, c'est surement volontaire.
Et puis, une extension firefox pour faire un lien, c'est pas ce qu'il y a de plus universel non plus.
[^] # Re: podcast?
Posté par EmmanuelP . En réponse au journal Emission Utopic à Brac sur Inter. Évalué à 1.
http://radiofrance-podcast.net/podcast/rss_10120.xml
[^] # Re: Les sales gnomes..
Posté par EmmanuelP . En réponse à la dépêche Gtk 2.10 est en finale. Évalué à 3.
Ben, si, c'est le manuel de référence. Il y a des exemples (pas assez nombreux, c'est vrai), il y un texte d'introduction pour chaque module, chaque fonction est documentée (ce qui n'est pas le cas de libgnomeprint).
Non, ce n'est pas juste une liste de fonctions qui prennent certains types en paramètres et retournent certains types.
Faut pas être de trop mauvaise foie quand même.
Je suis d'accord sur le fait qu'il faudrait un texte d'introduction expliquant l'ensemble de l'API et l'intérêt de chaque objet, et que ça peut être plus détaillé.
Juste une API similaire.
Avec cette nouvelle API, les développeurs avaient des objectifs qui les ont fait s'écarter de l'API libgnomeprint, comme le support multiplateforme.
L'API graphique de libgnomeprint est tout de même très similaire à celle de cairo.
[^] # Re: GNUstep
Posté par EmmanuelP . En réponse à la dépêche Cairo 1.2 met le feu. Évalué à 4.
Un peu comme dbus, quoi.
[^] # Re: GNUstep
Posté par EmmanuelP . En réponse à la dépêche Cairo 1.2 met le feu. Évalué à 1.
Je n'en ai pas trouvé trace là: http://doc.trolltech.com/4.2/qt4-arthur.html
Même si ça n'existe pas, c'est de toutes façons pas très dur à implémenter. Ça viendra vite si quelqu'un est intéressé...
Une autre question, est-ce que c'est dépendant de Qt, ou bien est-ce que les dépendances sont plus légères, comme cairo ? (fontconfig et libpng si je me souviens bien).
[^] # Re: Les sales gnomes..
Posté par EmmanuelP . En réponse à la dépêche Gtk 2.10 est en finale. Évalué à 9.
Ben oui, merci.
Merci d'être reparti sur de bonnes bases.
Merci d'avoir laissé tomber la bibliothèque vieillissante libgnomeprint.
Merci d'avoir fait le choix d'utiliser cairo pour le support de l'impression.
Merci, car grace à ce choix, aucun des logiciels ayant besoin d'une possibilité d'impression n'aura besoin de réimplémenter une couche d'abstraction pour l'affichage et l'impression.
Merci de fournir une documentation de qualité, dès la première version (Euh, dit, Colin, tu es allé voir là: http://developer.gnome.org/doc/API/2.0/gtk/Printing.html ).
Merci enfin de laisser les râleurs raler, sachant que libgnomeprint est toujours là et est toujours utilisable.
Enfin, quoi, Colin, tu es vraiment satisfait de libgnomeprint ?
Qu'est-ce que tu voulais ?
Penses-tu vraiment qu'il était possible de faire évoluer libgnomeprint pour le mettre dans un état plus présentable ? Penses-tu vraiment qu'il y a suffisamment de ressources humaines pour ça ?
[^] # Re: PDF généré : gestion du texte...
Posté par EmmanuelP . En réponse à la dépêche Cairo 1.2 met le feu. Évalué à 4.
Effectivement, acrobat reader semble afficher deux fois chaque caractère, ce qui ruine l'anti-crénelage.
http://emmanuel.pacaud.free.fr/screenshots/cairo/cairo-pdf.p(...)
Si tu déplace le contenu de la fenêtre avec l'outils main, l'affichage devient correct.
http://emmanuel.pacaud.free.fr/screenshots/cairo/cairo-pdf-a(...)
Reste à savoir si c'est un bug de cairo ou d'acrobat reader...
[^] # Re: PDF généré : gestion du texte...
Posté par EmmanuelP . En réponse à la dépêche Cairo 1.2 met le feu. Évalué à 2.
Oui.
Parce que justement là ils abusent des images : même le texte est mis sous forme d'image, non sélectionnable donc...
Le texte n'est pas sous forme d'image, se sont des bouts de polices embarquées.
Mis à part le texte d'entête et de bas de page, qui sont des effectivement des images, mais seulement parce que la police est de type bitmap.
Concernant le problème de sélection, c'est effectivement un bug, qui sera peut-être corrigé dans une prochaine version de la série 1.2, si ça n'implique pas de trop gros changement.
L'objectif de cette série stable étant une bonne qualité de rendu, notamment en vue de l'utilisation par le module d'impression de gtk 2.10. Ce problème n'a donc pas été considéré comme bloquant.
[^] # Re: question de vocabulaire
Posté par EmmanuelP . En réponse à la dépêche Cairo 1.2 met le feu. Évalué à 1.
Le quelque chose du genre, c'est:
<path d="M x0 y0 L x1 y1"\>
[^] # Re: question de vocabulaire
Posté par EmmanuelP . En réponse à la dépêche Cairo 1.2 met le feu. Évalué à 2.
Le backend est la partie de cairo qui va effectivement traduire les appels à cairo en une action dépendant du type de sortie désiré.
Par exemple, pour les appels suivant:
cairo_move_to (cairo, x0, y0);
cairo_line_to (cairo, x1, y1);
cairo_stroke (cairo);
Le backend image va tracer une ligne en modifiant les octets d'un espace mémoire correspondant à une image.
Le backend SVG lui, va stocker dans un fichier le code SVG qui décrit cette ligne, quelque chose du genre:
L'intérêt d'une biliothèque graphique avec backend, c'est qu'en gros, le code pour tracer ne change pas, il suffit simplement de créer la surface correspondant au type sortie souhaité (cairo_image_surface_create ou cairo_svg_surface_create dans ce cas).
[^] # Re: L'ODF Alliance aussi !
Posté par EmmanuelP . En réponse à la dépêche Des multinationales soutiennent l'adoption de formats ouverts par le gouvernement français. Évalué à 8.
Ne soit pas désolé, va...
Note aussi le bel exemple de politiquement correct (qui ne date pas d'hier, d'ailleurs): le grand industriel français de la défense... Moui, de la défense, bien sûr... jamais de l'attaque, hein, jamais ?
[^] # Re: Pas encore d'assez bonne resolutions
Posté par EmmanuelP . En réponse au journal [HS] GoogleEarth, Geoportail, Mappy et vie privée. Évalué à 2.
Plein de places ? Les parkings sont bondés !
http://maps.google.fr/maps?f=q&hl=fr&q=&ie=UTF8&(...)
[^] # Re: Des liens peut-être ?
Posté par EmmanuelP . En réponse au journal KDE devient marron ?. Évalué à 1.
Quels produits ?
[^] # Re: Latex
Posté par EmmanuelP . En réponse au journal Inkscape 0.44pre0. Évalué à 1.
poppler possède un backend cairo, qui lui même aura un backend SVG.
Il y a déjà dans le répertoire tests de la version de développement de cairo un petit utilitaire rudimentaire pdf2svg qui fait cette conversion.
Les résultats sont corrects visuellement. Par contre le fichier SVG généré n'est pas vraiment optimisé (les textes sont convertis en chemins (c'est une limitation du backend SVG de cairo), et les dégradés en couches sucessives d'objets de couleurs différentes (limitation de poppler)).
[^] # Re: Merci
Posté par EmmanuelP . En réponse au journal Inkscape 0.44pre0. Évalué à 9.
A la question le format SVG est-il bloquant, la réponse est oui, et non.
Oui, parce que pour être lu par autre chose qu'inkscape, il faut produire du SVG conforme. Donc pour des effets qui n'existent pas dans SVG, il faut utiliser des moyens détournés, comme la conversion de texte en chemin, ou le rendu par une image de substitution en mode point.
Non, parce que le format SVG d'inkscape inclu des champs supplémentaires qui permettent de conserver les paramètres de l'effet. Il n'y a donc en théorie aucune limite liée au format de sauvegarde.