Frédéric COIFFIER a écrit 703 commentaires

Effectivement, puisque dans le match CMake vs SCons pour KDE4, c'est finalement CMake qui est arrivé vainqueur.

J'avais utilisé SCons et je le trouvais pas trop mal pour des petits projets avec de petits besoins mais lorsqu'il faut détecter tout un tas de choses par rapport à l'environnement, ça devient moins simple.

Yep, c'est en cours dans oKular, le remplaçant de Kpdf dans KDE4 et je crois avoir vu sur un blog que ça avançait bien (pour le support d'XPS) :
http://kpdf.kde.org/okular/formats.php

C'est vrai ! C'est grâce à ses images, que je me suis penché un temps sur POV-Ray.
J'espère qu'il mettra un jour son site à jour s'il continue à utiliser POV-Ray

D'un point de vue photo-réaliste, oui, je trouve que POV-Ray donne des résultats moins impressionnants.
Autant quasiment tous les rendus de Sunflow donne des éclairages très réalistes.

Faut dire, que là, au boulot, sur un poste Windows XP, derrière un proxy, bah, l'installation du JRE vient de planter car l'installeur Sun n'arrive pas à se connecter au net pour télécharger le reste de l'installation (forcément, puisque je suis derrière un proxy).
Alors, que l'installation de Flash avec Firefox n'avait pas posé de problème (normal, puisqu'il n'y avait qu'un fichier à télécharger et que c'est Firefox qui l'a fait).

Je n'ai pas non plus de connaissances techniques en matière de moteur de rendu, mais c'est vrai que le rendu est stupéfiant quand on compare à ce qui se fait avec Blender ou Yafray (ou même POV-Ray).
D'un autre côté, les buts recherchés par ces moteurs ne sont pas les mêmes. Je voudrais bien savoir combien de temps il faut pour faire le rendu d'une telle scène...

Je confirme que OOo gère très mal le RTF puisque les fichiers RTF générés par Doxygen (le générateur de documentation GPL) ne peuvent être ouvert qu'avec Word !

Je doute qu'actuellement (en 4.1) , GCC soit vraiment capable de profiter de ces différences de jeux d'instructions. GCC est réputé pour être un bon compilateur très généraliste (beaucoup d'architectures supportées) au détriment des optimisations pour chacun d'entre eux. De plus, depuis le i386, les instructions qui sont apparues correspondent à des besoins très particuliers surtout pour le calcul multimedia. A côté de ça, les instructions existantes très utilisées ont été optimisées au maximum ce qui fait que le même code s'exécute plus vite.
Bref, je doute que GCC puisse facilement tirer parti de ces nouvelles instructions (même si l'après-4.1 devrait améliorer les choses mais sans vraiment utiliser ces instructions). Après, si on veut des optimisations Intel, il suffit d'utiliser le compilateur d'Intel qui ne compile pour les x86 !

Merci !!

Effectivement, le LiDE25 est supporté par SANE et n'est vraiment pas cher !

(Pour ceux qui passeraient ici : Tous les LiDE ne se valent pas et la plupart ne sont pas supportés comme le LiDE70)

A ce propos, il se peut que ça change...
D'après ce que j'ai compris, ce n'est pas non plus très simple d'avoir un éditeur WYSIWYG HTML. Thunderbird a repris un éditeur qui existe depuis Netscape.
Sous KDE, malheureusement, il existe peu de chose.

Mais avec Qt4, de grosses améliorations ont été apportées pour justement créer des éditeurs riches (gestion des styles avec un traitement de texte ou un éditeur HTML). Il se peut donc que Qt4 facilite la création d'un vrai éditeur HTML du niveau de celui de Thunderbird.

Donc, avant, c'était techniquement difficile et les développeurs n'en voulaient pas.
Avec KDE4, ça sera peut-être plus facile. Reste à trouver des développeurs motivés...

Personnellement, je veux juste pouvoir faire la même niveau d'édition que dans Thunderbird ! Donc, images, tableaux, styles et pouvoir répondre proprement à un mail en HTML, tout en garantissant un minimum de sécurité (empêcher les liens vers des pages externes, pas de javascript ou de trucs bizarres...)

Je n'utilise que KMail depuis plusieurs années maintenant mais... KMail a un gros manque (de mon point de vue) par rapport à Thunderbird, c'est qu'il ne permet pas d'envoyer de mail en HTML avec une vraie mise en forme, où l'on peut mettre une image, un tableau, de vrais styles, etc... De même, il n'est pas capable de répondre à un mail HTML en HTML...

Certains diront qu'un mail, c'est pas en HTML (c'est d'ailleurs pour ça que le bug traîne depuis des années, vu que c'est ce que pense les développeurs de KMail), mais quand même, c'est rudement pratique...

N'y a-t-il que moi à penser qu'utiliser glxgears pour faire du benchmark 3D est absurde ?

J'avais commencé à faire comme toi : date - nom de l'évènement.
Maintenant, avec Digikam, je crée juste un album avec le nom de l'évènement : avec Digikam, on peut associer une date à chaque album en faisant une moyenne des dates des photos et ensuite, je sélectionne un tri chronologique (ce qui au final donne le même résultat)

Effectivement, on y trouve beaucoup de chose et c'est très puissant mais une réorganisation et du ménage reste à faire.
Ça a déjà commencé dans les dernières version de KDE (depuis la 3.4 je crois ?).

J'ai toujours du mal à différencier Bureau et Apparence et thème (dans l'un, on a décoration des fenêtres et dans l'autre comportement des fenêtres).
De même, pourquoi y a t-il une section Contrôle de l'énergie qui pour moi devrait une sous-section plus globale comme Système ?

Mais je pense que l'on y gagnera avec KDE 4.

De toute façon, il n'y a pas vraiment d'alternative libre et en plus, celui-ci est multi-plateforme.

Je confirme : j'ai installé OpenSuse 10 sur un PII 350 (avec à peu près autant de RAM que toi) pour mes parents et ça tourne et ça reste utilisable. C'est un peu long au démarrage mais après pour du surf (Opera 9 qui est à priori un peu plus léger que Firefox mais Firefox tourne aussi) ou Kopete, ça passe. Ca se complique par contre pour OOo : dans ce cas, on peut se préparer un café après l'avoir lancé.

A propos d'OpenGL, est-ce que K3DSurf est utilisable avec MESA (l'implémentation logicielle d'OpenGL) ou est-ce beaucoup plus lent que la version 2D traditionnelle de K3DSurf ?
Si les performances restaient acceptables, MESA pourrait être un bon compromis pour avoir une bonne qualité d'affichage même sur les machines sans accélération 3D.

Effectivement, je trouve que c'est une excellente initiative ! Espérons que ce genre de test se répande dans la presse informatique !

C'est bizarre qu'il n'existe finalement pas de puissant éditeur XML libre (en dehors d'emacs), alors que l'utilisation d'XML est généralisée et qu'il est devenu le symbole des formats libres...
[J'entends pas éditeur, un logiciel permettant de valider le XML que l'on écrit, d'afficher sa structure pour facilement naviguer dedans et permettant de facilement le modifier]

Existe-t-il des éditeurs spécifiques à DocBook permettant d'écrire des documents facilement (disons pour un non informaticien qui a besoin de documenter un produit) ou au pire, dans le style de Kile pour LaTeX ?
Qu'utilisez-vous pour écrire vos documents DocBook ?

J'y connais rien... mais...
Et si l'algo de cryptage tournait en mode kernel sur un Linux par exemple, est-ce que le problème pourrait-être partiellement résolu ? (Je crois avoir compris avec la virtualisation matériel, il y a des failles, etc...)

Je pense que ces problèmes sont liés à ta configuration.
Sans faire de ma configuration une référence, je n'ai eu aucun plantage Flash 9 depuis que je l'ai installé... (et pourtant, j'utilise Konqueror sous Gentoo)

Qu'entends-tu par raté avec Hugin ? Aurais-tu un exemple de panoramique fait avec Hugin et Autostitch pour pouvoir voir la différence ?

Je conseille très fortement Hugin : une fois que l'on y a goûté, on ne peut plus s'en passer. Certains diront qu'il est assez difficile d'approche... N'ayant jamais rien utilisé d'autres, je peux juste dire que j'en suis très content.
Surtout, il faut penser à utiliser enblend (option dans le dernier onglet en bas !!)

Pour le tirage de photo, je les envoie chez Photoways : il parait que c'est un peu cher... Vu le résultat, j'en suis très content !
http://www.photoways.com/