xine a un support complet pour les plug-ins de post-effect maintenant. Il est vrai que l'accent n'est pour le moment mis que sur l'aspect player, mais l'aspect édition de flux est peu à peu mise en place et sera sans doute le prochain milepost une fois la version 1.0 de la lib finalisée.
Apparemment, leur API est stable et propre, ce qui fait, qu'entre autres, Rythmbox cité plus haut a pour le moment migré de Gstreamer à xine.
Et xine a déjà un support très important d'interfaces : gnome, gtk, X11, KDE, etc.
Je ne serais donc pas surpris que ce projet coiffe les autres au poteau au final.
Ceci étant dit, il faut rappeler que tous ces projets interragissent beaucoup et que des portions de xine viennent de mplayer et réciproquement, et tous puisent alègrement sur un projet comme ffmpeg. Quelque soit l'API qui s'imposera au final, la contribution des autres projets restera très important et méritera d'être signalée.

Cordialement,

[ Répondre ]

Ces précisions sont très intéressantes (en particulier celles concernant les TT que je ne savais pas).
Cela dit, en quoi est-ce en contradiction avec ce que j'ai dit dans le message précédent?

Richard Van Den Boom

[ Répondre ]

Sous Windows, quand les fontes italique ou gras sont dispos, les logiciels les utilisent par défaut. La déclinaison ne se fait que si les fontes ne sont pas disponibles.
Je ne sais pas sous Linux si les traitements de textes supportent cela.

Richard Van Den Boom

[ Répondre ]

> Ah ? Là, c'est des fontes vectorielles, donc faite pour l'impression.

Je ne comprends pas ce que tu veux dire. Aussi bien les fontes TrueType que les fontes Type 1 sont vectorielles et sont utilisées depuis belle lurette pour l'affichage, en plus de l'impression. Sur mon KDE, toutes mes fontes par défaut sont ainsi en Garamond Type 1.
En l'occurrence, il s'agit surtout, d'après ce que j'ai compris, d'un jeu de caractères étudié pour s'afficher correctement à l'écran et y être bien lisible, ce qui implique surement des contraintes particulières d'empattement, de proportions, etc.

Richard Van Den Boom

[ Répondre ]

Non car pour se linker sur une librairie GPL, le programme doit aussi être GPL, y compris ton "champignon". C'est pour éviter ce problème, je pense, qui devait empêcher entre autres les programmes distribués sous autres licenses libres d'utiliser des librairies GPL, que la LGPL (Library GPL) a été créée. Donc tu peux compiler XFree avec la glibc qui est sous LGPL, mais tu n'aurais pas le droit avec une librairie C sous license GPL (vu que XFree est sous X11). Corrigez-moi si je me trompe. Cordialement,

[ Répondre ]

Ce qui est intéressant, c'est qu'ils ont apparemment écrit une librairie permettant de s'affranchir (au moins pour KHTML et KJS) de QT et de KDE. Serait-elle assez large pour permettre d'autres ports d'applis KDE vers des systèmes équipés ni de QT ni de KDE?
Et du coup, pourquoi ne pas concevoir qu'Apple porte beaucoup plus d'applis KDE dans le futur, haut hasard KOffice? Ne sont-ils pas soit disant en train de développer une suite légère et performante censée à terme concurrencer Office sur leur plateforme? Et plutôt que de se casser la tête à repartir à zéro, pourquoi ne pas plutot prendre ces applis KDE toutes faites et cohérentes, quitte à les améliorer un peu?
Moi qui pourtant ai une vrai dent contre Apple, s'ils se décident à procéder ainsi en contribuant en retour à l'amélioration de KDE, je serais alors prêts à revoir mon opinion sur eux et à leur accorder un statut similaire à IBM (ce qui veut dire ce que ca veut dire...).

Cordialement,

[ Répondre ]

C'est d'autant plus étrange comme discussion que bon nombre de librairies du libre sont distribuées en LGPL et non en GPL. Or, la différence principale est justement que les codes propriétaires peuvent se linker en dynamique dessus sans pour autant révéler leur source.
Donc, je ne vois pas bien l'intérêt de son propos. Chaque développeur de librairie libre a le choix d'imposer son utilisation par des logiciels libres uniquement ou par tout le monde. Il est tout de même la seule personne à pouvoir faire ce choix, non?

Cordialement,

[ Répondre ]

Contrairement à l'Open Source, une boite, ca a des deadlines. Si ca prend 6 mois de créer un navigateur stable avec un moteur qui rend bien 99% des sites et supporte les plug-ins Netscape, tandis qu'avec un autre qui rend bien 100% des sites, ca prend deux ans, le premier sera choisi.
Le mail initial auquel tu as réagi était un peu trollesque, j'en conviens (et pourtant je préfère de loin KDE) mais il est peut-être plus simple et plus réaliste d'admettre qu'il peut y avoir des raisons techniques, en plus de celle que tu invoques qui est envisageable, expliquant le choix d'Apple.

Cordialement,

[ Répondre ]

C'est déjà supporté dans KDE 3.1. Est-ce plus lourd maintenant, je ne sais pas.
Cela dit, il n'y a pas que la lourdeur en tant que code, mais la facilié d'implémenter un navigateur utilisant ce moteur. J'ai idée que c'est plus simple avec KHTML (qui est un module conçu pour être appelé par différentes applis dans KDE très facilement, par exemple dans KMail) qu'avec gecko et que c'est pour cela qu'il a été déjà deux fois préféré.

Cordialement,

[ Répondre ]

Avec la RC de KDE 3.1, je n'utilise pratiquement plus que Konqueror. Je dois avoir un site tous les 3 mois qui ne passe pas. Il y a bien de temps en temps encore quelques petits bugs d'affichage mais la liste se réduit très vite.
Alors pourquoi autant de fanatisme? KHTML est peut-être très simple pour un programeur à implémenter dans un navigateur, ce qui explique son choix. Je rappelle que le développeur d'AtheOS avait lui aussi choisi Konqueror et KHTML comme base de son navigateur, pas Gecko, c'est peut-être qu'il y a de bonne raison à cela et que développer un navigateur à partir de ce module est d'une simplicité déroutante.
Vous devriez vous réjouir qu'Apple contribue enfin au libre en apportant un bon nombre de correctifs à un projet open source, plutôt que de vous enfermer une fois de plus dans une querelle partisane puérile. J'avoue que cela m'étonne d'eux.

Cordialement,

[ Répondre ]

Mouais, en attendant, je préfèrerais que les développeurs de film-gimp se concentrent sur la convergence de ce projet avec gimp-1.2.3 plutot que de nous faire un portage pourri sur une plateforme que personne n'utilise dans le milieu du cinoche ou de l'animation.
Bon, personne, c'est un peu exagéré mais disons que c'est une plateforme ultraminoritaire sur ce marché comparé aux PC et aux Unix, et film-gimp serait beaucoup plus attrayant avec le support de certains outils disponibles en 1.2.3.

Cordialement,

PS : J'ai un dégoût d'Apple qui est certainement pour beaucoup dans mon commentaire peu objectif. :-)

[ Répondre ]

A comparer au 270 euros d'un AXP 2000+ et d'une carte Asustek nForce2.
A ce prix là, mieux vaut encore une carte mère Socket 370 et un processeur VIA C3 933MHz. Ca, je sais que c'est compatible avec tout et ca fonctionne sans problème sans ventilateur, avec juste un radiateur passif. Et ca me coutera 4 fois moins cher pour des performances similaires.
Dommage.

Cordialement,

[ Répondre ]

Et c'est quoi le prix de la bête?
Parceque, pour avoir les perfos d'un Duron 800Mhz, ca a intéret à être bon marché. Surtout quand tu vois le prix maintenant d'un Athlon XP 1.5Ghz. :-)

Cela dit, ca doit être bien silencieux, bien pour une set-top.

Cordialement,

[ Répondre ]

>Yep parce que les processeurs RISC n'ayant pas encore les poids des années et de la >compatibilité n'en avait pas (encore) besoin.
Je ne sais pas si on pas si c'est trop ça. Ce n'est pas tant une raison de compatibilité que de vouloir augmenter l'IPC du processeur à même fréquence. Augmenter la fréquence pose parfois des problèmes, car elle nécessite des outils de gravure de plus en plus affinés, qui ne sont pas forcément disponibles. C'est aussi ce qu'à rencontré DEC avec le 21164. Donc, pour augmenter malgré tous les performances, on augmente l'IPC. Et le OoO permet en partie d'éviter les états d'attente des processeurs superscalaires en cas d'instructions indépendantes.
Ainsi le PPro a augmenté sensiblement les performances du Pentium à même fréquence, en restant (si je me souviens bien) en gravure 0.35µ, tandis que l'Alpha 21264 a doublé celle du 21164 à même fréquence et même finesse de gravure (0.25µ là encore si je me souviens bien).

> RISC/CISC qualifie le jeu d'instruction pas leur implémentation
Autant que je sache, c'est exact.

Cordialement,

[ Répondre ]

L'exécution d'instructions dans le désordre a été introduite par le Pentium Pro dans le monde CISC, tandis qu'elle n'est apparue dans le monde RISC que bien plus tard, par exemple avec l'Alpha 21264 ou l'UltraSparc III.
Comme quoi, des innovations, il y en a eu dans les deux sens et les deux architectures ont bénéficié des avancées de l'autre.
Il faut aussi préciser que, au delà des jeux d'instructions proprement dits, les processeurs actuels du monde x86 sont des RISCs qui se cachent : en effet, tous incorporent en réalité une étape de décodage des instructions x86 en micro-instructions de type RISC, plus faciles à éxécuter dans le désordre.
Cet discussion CISC contre RISC n'a plus aucun sens de nos jours. Elle n'incorpore même pas les jeux d'instruction VLIW qui commencent à apparaitre avec les processeurs de Transmeta ou l'Itanium d'Intel.

Cordialement,

[ Répondre ]

Assez douteux, puisque le P4 et l'AXP ont parmi les meilleurs performances, sinon les meilleurs performances en SpecINT. Les seuls éventuels concurrents sont les Power d'IBM, à un prix défiant toute concurrence (vers le haut...:-)).
La vérité, c'est qu'une échelle de performance, c'est assez compliqué à trouver, surtout quand il s'agit de comparer des architectures très différentes. Il n'y a pas de formule magique, il faut se faire une idée en comparant les architectures sur les applications que l'on compte utiliser.
Personnellement, je vais sur le site www.aceshardware.com, ils y font peu de revues, mais bien documentées et les gars savent ce qu'ils testent, contrairement à la grande majorité des sites de matériel. Le forum est aussi assez intéressant car il y a plusieurs ingénieurs et informaticiens visiblement compétents qui contribuent. Evidemment, comme dans tout forum, il y a toujours des excités un peu fanatiques qui cherchent à défendre telle ou telle marque, mais globalement, on peut avoir des analyses et des informations techniques d'assez haut niveau.

Cordialement,

[ Répondre ]

C'est particulièrement sensible pour KDE. Je tourne sous Slackware et ai upgradé en Current pour tester les releases candidates de KDE3.1 compilées avec GCC 3.2. Ben, y'a une nette différence. Non seulement il a de la gueule mais est maintenant bien rapide et stable. Que du bon.

Cordialement,

[ Répondre ]

Tu proposes une alternative à une personne donnée, par rapport à ce dont elle a l'habitude, pas en général. Tu ne peux pas espérer que quelqu'un qui a pris l'habitude de travailler sous Word va considérer TeX ou même DocBook comme une "alternative".
Les systèmes comme TeX ou DocBook sont parfaits pour générer des documents techniques pouvant être fournis sous plusieurs media. Ils ne sont pas adaptés à la réalisation de mises en page complexes et avec images, tranparences comme des slides de présentation commerciale ou des magazines. Il y a de bonnes raisons qui poussent les boites de PAO à utiliser des soft WYSIWYG, comme il y a de bonnes raisons que les publications techniques utilisent plutôt les outils de type TeX ou DocBook.
Ce ne sont pas des "alternatives" mais des outils différents, ciblant des travaux différents en général, même si un petit overlap existe.

Cordialement,

[ Répondre ]

C'est ma galère permanente avec OpenOffice.
Tiens actuellement, il ne prend plus en compte le circonflexe. Si je tape ^-i ou ^-e, j'ai rien, pas de caractère. Je démarre Kword, je tape ^-e et j'ai ê.
Va comprendre, Charles.
En bref, OpenOffice, c'est pas mal, mais je pense migrer peu à peu vers KOffice.

Cordialement,

[ Répondre ]