jeudi 10 avril

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Articles précédents : Articles

Liens connexes

L'annonce (334 hits)
Le but du projet (255 hits)
Un exemple de code (635 hits)
Les commentaires sur LWN (213 hits)

Dépêche modérée par

Nyco

Dépêche éditée par

Articles : Annonce du projet Phonon

Posté par patrick_g (page perso, ). Modéré le 28 avril 2006.

Après les projets Solid (intégration entre le hardware et KDE 4.0) et Plasma (nouveau design de KDE 4.0) voici le nouveau venu : Phonon.

Le but de ce nouveau projet est de créer une interface d'abstraction unifiée entre toutes les applications du futur bureau KDE d'une part et les moteurs multimédias sous-jacents d'autre part.
A l'heure actuelle KDE utilise aRts mais ce logiciel est complexe et il n'est plus maintenu par son initiateur depuis 2004 (il a expliqué dans ce document pourquoi il avait abandonné son projet).

La transition vers KDE 4.0 offre donc l'opportunité de briser la compatibilité avec aRts et d'opter pour un nouveau moteur multimédia tout neuf et rutilant… mais lequel choisir ?

Entre les supporters de Gstreamer, les zélateurs de NMM et les adorateurs de Xine le doute est permis et l'erreur interdite ! Plutôt que de prendre le risque de miser sur le mauvais cheval les développeurs de KDE 4.0 ont opté pour un mécanisme original. La solution retenue consiste donc en l'interface Phonon qui va permettre d'offrir une abstraction simple à utiliser pour les applications KDE "au-dessus" et un mécanisme de plug-in pour attacher divers moteurs multimédias "en-dessous".

L'annonce (334 hits)
Le but du projet (255 hits)
Un exemple de code (635 hits)
Les commentaires sur LWN (213 hits)

> Lire la dépêche (62 commentaires, moyenne: 3,1).

Les avantages évidents du projet Phonon sont l'indépendance envers l'infrastructure multimédia sous-jacente, la simplicité et l'unité du code des applications de KDE. Du fait de la nature multi-plateforme de KDE (une version Windows de KDE 4.0 est prévue) ces qualités sont de premières importance mais elles ne doivent pas masquer qu'il existe également des inconvénients.

Comme cela a été souligné dans les commentaires sur le net, Phonon ajoute encore une couche d'abstraction entre le hardware et l'utilisateur (on aura donc "Carte son->ALSA->Gstreamer->Phonon->Application KDE") ce qui n'est jamais bon pour la légèreté du bureau Linux et pour la facilité de correction des bugs. Un article célèbre d'un ancien développeur SGI au sujet des risques induits par ces empilements complexes de couches se trouve ici.

La réponse officielle à cette interrogation est :

Its not like Phonon is some sort of running process that has to "talk" to xine, gstreamer etc. It just layer of API in keeping with good OOP design. So, it adds a couple of extra function calls.
The ability to change multimedia backends while retaining binary compatability is a large benefit. We don't want KDE 4.x to be stuck on one multimedia system like KDE 3.x is stuck with aRts.
Traduction libre : "Ce n'est pas comme si Phonon était un processus réel qui aurait à "parler" avec xine, gstreamer, etc. C'est juste une couche d'abstraction avec une bonne conception orientée-objet. Donc cela ajoute seulement quelques appels de fonctions.
La possibilité de changer le backend multimédia tout en conservant la compatibilité binaire est un gros atout. Nous ne voulons pas que KDE 4.x se retrouve coincé avec un système multimédia comme KDE 3.x est coincé avec aRts".

D'autre part il a été souligné (sans que l'on puisse savoir à l'heure actuelle si ce risque est avéré) que l'API de Phonon (les commandes disponibles en quelque sorte) ne représenterait que le plus petit dénominateur commun à l'ensemble des commandes offertes par les moteurs multimédias sous-jacents. Il y aurait donc une perte de fonctionnalités due au passage par cette couche d'abstraction. Bien entendu, il sera toujours possible, pour des applications spécialisées, d'attaquer directement les couches basses.

En dépit de ces inconvénients, inhérents à l'ajout de couches d'abstraction, il ne faut pas perdre de vue que le portage de KDE sur différents OS sera grandement facilité par des technologies comme Solid ou Phonon, que l'écriture d'applications sera plus simple et que le bureau sera unifié et cohérent aux yeux de l'utilisateur final. C'est une perspective très alléchante qui renforce encore, s'il en était besoin, l'attente impatiente de la sortie de KDE 4.0.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Et la légéreté ?

Posté par Thomas D (page perso, ) le 28/04/2006 à 14:24. (lien). Évalué à 7.

"on aura donc "Carte son-> ALSA-> Gstreamer-> Phonon-> Application KDE") ce qui n'est jamais bon pour la légèreté du bureau Linux"

Je trouve dommage que la légereté soit sacrifiée dans le nouveau KDE 4... Jusqu'à présent cela ne se passait pas trop mal (KDE 3.5 était plus léger que le 3.4 ou le 3.3), c'est dommage car cela risque encore de renforcer le nombre d'utilisateurs qui abandonnent les bureaux "lourds" : KDE, Gnome au profit des Fluxbox et autres.

Cependant, j'imagine que ca ne doit pas etre facile de gérer tout ca et qu'il faut bien faire des choix...

Quelqu'un sait pour quand est prévu le KDE 4, s'il est déjà prévu ?

[^]Re: Et la légéreté ?

Posté par spotty () le 28/04/2006 à 14:42. (lien). Évalué à 7.
La richesse de l'OpenSource c'est sa variété, j'utilise KDE sur les workstations ou gnome mais sur un server ce sera xfce ou wmaker parce que plus léger et un server n'est pas fait pour la bureautique. Je suis pour la diversité et la liberté de choix, donc ce n'est dommage que les gens fassent d'autres choix, c'est même tant mieux :-)
- [^]Re: Et la légéreté ?
  
  Posté par Agrou () le 28/04/2006 à 15:05. (lien). Évalué à 6.
  Il me semble que l'un des objectifs de plasma est de rendre kde plus léger et rapide malgrès les innovations visuelles. Donc je ne pense pas que phonon aura une grande influence dans l'ensemble.
  
  Je me demande juste si ce projet ne démarre pas un peu tard par rapport au reste de kde4 qui devrai en théorie sortir a la fin de l'année vers octobre je crois.
  
  --
  http://linuxdansmonpc.is-a-geek.com/
  
  « Quoi que tu fasses cela sera insignifiant, mais il est très important que tu le fasses». Mohandas Gandhi
  - [^]KDE 4.0 Release Plan
    
    Posté par Damien Gombault (Jabber id, page perso, ) le 28/04/2006 à 15:21. (lien). Évalué à 3.
    Un petit lien : http://developer.kde.org/development-versions/kde-4.0-releas(...)
    
    « October ... 2006: Technical Preview 1 »
    Il va falloir encore attendre pas mal de temps je pense avant la version finale de KDE 4.
  - [^]Re: Et la légéreté ?
    
    Posté par Narishma Jahar () le 28/04/2006 à 17:03. (lien). Évalué à 3.
    Le projet a démarré il y a quelques années déjà (lors de l'akademy de 2004) et il s'appelait KDEMM. C'est juste qu'il vient d'être annoncé officiellement. Et s'il a mis tout ce temps pour arriver c'est parcequ'un seul développeur travaille dessus sur son temps libre.
    - [^]Re: Et la légéreté ?
      
      Posté par Philippe Fremy (page perso, ) le 28/04/2006 à 17:07. (lien). Évalué à 5.
      Finalement, la plus grosse nouveaute dans ce projet, c'est le nom : Phonon. C'est quand meme plus joli que kdemm .
      
      --
      phil.freehackers.org
      - [^]Re: Et la légéreté ?
        
        Posté par agmk () le 28/04/2006 à 18:13. (lien). Évalué à 10.
        Bof, ça sonne faux non ? c'est limite faux nom.
        
        --
        Wr ar fbhunvgr cnf ha qrfgva sharfgr à yn cncnhgé. Nzra.
        
        [^]Re: Et la légéreté ?
        
        Posté par reno () le 29/04/2006 à 14:52. (lien). Évalué à 4.
        Oui c'est un faux nom: un phonon c'est du son, alors que phonon c'est aussi pour la vidéo.
        Donc phonon est un faux ami, fou non?
        
        [+] [^]Re: Et la légéreté ?
        
        Posté par jeff110 () le 01/05/2006 à 18:31. (lien). Évalué à -1.
        Phono-on
    - [^]Re: Et la légéreté ?
      
      Posté par Mark Havel () le 28/04/2006 à 18:41. (lien). Évalué à 1.
      Ce qui explique certainnement pourquoi il est si avancé si l'on en croit la page du projet...

[^]Re: Et la légéreté ?

Posté par Philippe Fremy (page perso, ) le 30/04/2006 à 14:01. (lien). Évalué à 7.
Je ne suis pas d'accord avec toi. Unifier une API, ce n'est pas nécéssairement l'alourdir. Cf mon message plus bas avec kio comme exemple. Kio n'alourdit pas le protocole html ou le protocole ssh, il se contente de l'utiliser en fournissant une interface uniforme pour les applications KDE.

D'un point de vue programmation, phonon rajoute une couche, mais d'un point de vue fonctionnel, phonon est complètement transparent.

--
phil.freehackers.org
- [^]Re: Et la légéreté ?
  
  Posté par atlexx () le 03/05/2006 à 07:56. (lien). Évalué à 1.
  c'est bien la ou l'on veut en venir ... si a chaque étape tu mets une couche d'abstratction, tu es tres fonctionnel, au niveau prog c'est bien plus simple, mais:
  - tu ajoute une couche (qui ne fait que de l'encapsulation) donc du perd de l'efficacité
  - soit tu te reduit au plus petit dénominateur commun fonctionnel, soit tu implemente des fonctions qui ne seront peut être pas supportée par la couche en dessous
  
  dans ton exemple, kio alourdit ssh dans ce sens qu'il ajoute un traitement, même leger, qui n'est pas indispensable fonctionellement.
  
  dans le cas de KDE, qui n'a pas prétention à la legereté, je ne crois pas que cela soit un problème. néanmoins rien n'est gratuit le système complet est vraisemblablement plus performant sans ces couches qu'avec.
  - [^]Re: Et la légéreté ?
    
    Posté par Philippe Fremy (page perso, ) le 07/05/2006 à 11:27. (lien). Évalué à 5.
    On n'a pas la meme definition d'alourdir. Si je suis ton raisonnement, tout ce qui n'est pas ecrit en assembleur est lourd.
    
    Je trouve que tu utilises un vocabulaire imprecis et une analyse hyper theorique eloignee des realites pratiques et des problematiques reelles, ce qui conduit a des conclusions qui sont a mon sens plutot denudees de justesse.
    
    Derriere le vocable fourre-tout "ajouter une couche", il y a differentes operations possibles, l'une pouvant ralentir de facon signficatives les performances du programme et meme en affecter le fonctionnement (genre rajouter xine au dessus de alsa) et l'autre a un impact negligeable (ajouter un ou deux appels de fonctions pour acceder a le meme fonctionnalite).
    
    Je ne sais pas ou tu as lu que KDE ne pretend pas a la legerete (peut-etre dans le marketing de Gnome ?) mais ce n'est pas du tout le cas. Toutes les versions de KDE depuis la 2.0 sont plus rapides les unes que les autres et consomment moins en memoire.
    
    La convivialite est en revanche une preoccupation importante de KDE et si cela veut dire "alourdir" le protocole ssh en "rajoutant une couche" avec kio pour que ce soit plus convivial, ca me semble une bonne chose.
    
    Juste pour rire, est-ce que qq'un a deja note que fish: etait plus lent que scp ? Est-ce que qq'un a deja eu un probleme de ce style au point de vouloir supprimer fish ?
    
    --
    phil.freehackers.org

Engin ?

Posté par GCN (Jabber id, page perso, ) le 28/04/2006 à 14:43. (lien). Évalué à 6.

> La transition vers KDE 4.0 offre donc l'opportunité de briser la compatibilité avec aRts et d'opter pour un nouvel engin multimédia tout neuf et rutilant… mais lequel choisir ?
[...snip...]
> [...] ne représenterait que le plus petit dénominateur commun à l'ensemble des commandes offertes par les engins multimédias sous-jacents.

J'imagine que le traducteur a voulu dire "moteur" ici, non ?
http://www.wordreference.com/enfr/engine

--
The UNIX way of sex:
gunzip;strip;touch;finger;mount;fsck;more;yes;umount;sleep

[^]Re: Engin ?

Posté par Nÿco (Jabber id, page perso, ) le 28/04/2006 à 16:44. (lien). Évalué à 3.
Oups, une correction de trad qui m'a echappée...

--
Jabber ID : xmpp:Nyco@jabber.fr
- [^]Re: Engin ?
  
  Posté par pingui (Jabber id, ) le 28/04/2006 à 17:22. (lien). Évalué à 2.
  moui alors à ce moment là ce devient :
  "un nouveau moteur" (et pas "un nouvel moteur")
  - [^]Re: Engin ?
    
    Posté par patrick_g (page perso, ) le 28/04/2006 à 19:52. (lien). Évalué à 2.
    Tout à fait ! C'est du sabotage de ma news :-)

Perte de fonctionnalités

Posté par creak (page perso, ) le 28/04/2006 à 14:47. (lien). Évalué à 5.

D'autre part il a été souligné (sans que l'on puisse savoir à l'heure actuelle si ce risque est avéré) que l'API de Phonon (les commandes disponibles en quelque sorte) ne représenterait que le plus petit dénominateur commun à l'ensemble des commandes offertes par les engins multimédias sous-jacents. Il y aurait donc une perte de fonctionnalités due au passage par cette couche d'abstraction. Bien entendu, il sera toujours possible, pour des applications spécialisées, d'attaquer directement les couches basses.

Quelque part ça me semble évident. Si arTs propose les fonctionnalités A, B et C et que ESD propose B, C et D, pour être parfaitement interopérable, Phonon doit supporter B et C.
Après, des "optimisations" peuvent avoir lieu, mais plus on fera des cas particulier, plus on perdra l'abstraction qui est le fer de lance de Phonon.

[^]Re: Perte de fonctionnalités

Posté par Romain Vinot (page perso, ) le 28/04/2006 à 16:58. (lien). Évalué à 4.
On peut aussi avoir A, B, C et D dans Phonon et la couche d'abstraction Phonon qui "débranche" la fonctionnalité si le moteur interne ne la gère pas.

C'est exactement ce que fait DirectX avec toutes les commandes 3D qui apparaissent au fur et à mesure des nouvelles générations de carte 3D. N'en déplaisent aux détracteurs de Microsoft (dont je fais partie), pour une fois, ils ont réussi à faire un truc particulièrement réussi. Les possesseurs de toute nouvelle carte 3D peuvent utiliser leur bidule au maximum et les possesseurs de carte moins puissante peuvent utiliser la leur, en baissant la qualité des images bien sûr.

J'y connais rien, mais je suppose que le même principe peut être utilisé pour Phonon également.
- [^]Re: Perte de fonctionnalités
  
  Posté par Narishma Jahar () le 28/04/2006 à 17:10. (lien). Évalué à 5.
  D'après ce que j'ai compris, Phonon proposera une API simplifié car son but n'est pas d'exposer toutes les fonctionnalités des backends mais de permettre d'ajouter facilement des capacités multimedia aux applications KDE.
  
  La majorité des applications on juste besoin de jouer ou capturer un son ou une vidéo, gérer le volume, etc... Phonon devrait permettre de faire facilement ce genre de choses.
  
  Après si ton application a besoin de faire des choses plus compliquées elle va surement utiliser xine, gstreamer ou autre, voir même alsa directement.
  - [^]Re: Perte de fonctionnalités
    
    Posté par djano () le 03/05/2006 à 11:42. (lien). Évalué à 3.
    Ca me fait penser au cas du toolkit graphique AWT dans Java qui n'utilisait que le plus petit denominateur commun a toutes les interfaces graphiques. Resultat: il a ete remplace par Swing qui offrait une interface unifiee et bien plus complete (entre autres raisons).
    Et puis SWT est arrive et il commence a grignoter serieusement des parts a Swing (avec la reussite d'Eclipse).
    Voir ceci pour mieux comprendre:
    http://en.wikipedia.org/wiki/Standard_Widget_Toolkit#Java_GU(...)
    
    Bref, j'espere pour Phonon que le spectre des fonctionnalites proposees va etre suffisamment large pour repondre le plus possible aux besoins des applications KDE. Dans le cas contraire, cela va etre un loupe total.
    
    Comme dis plus haut, un comportement a la DirectX avec le test des fonctionnalites presentes serait l'ideal.
    Ou alors, le support des fonctionnalites avancees non supportees par un backend pourrait etre implementees dans Phonon (ou le plugin) en s'appuyant sur les fonctionnalites existantes du backend (je ne connais rien a l'audio, peut etre que cela se voit) un peu comme Mesa le fait pour l'OpenGL.

[^]Re: Perte de fonctionnalités

Posté par Philippe Fremy (page perso, ) le 28/04/2006 à 17:06. (lien). Évalué à 10.

Quelque part ça me semble évident. Si arTs propose les fonctionnalités A, B et C et que ESD propose B, C et D, pour être parfaitement interopérable, Phonon doit supporter B et C.

Ou bien phonon fournira une emulation de A. Ou bien les applications qui necessitent D auront la possibilite de demander si la fonctionnalite est disponible et si ce n'est pas le cas, de dire a l'utilisateur "Pour s'executer, ce programme necessite la fonctionnalite D dans le backend multimedia mais cette fonctionnalite n'est pas disponible sur votre backend".

A noter que ce type de comportement est deja utilise dans plein d'application ou de technologies. Par exemple, la surveillance de la mise a jour des repertoires (un nouveau fichier est-il arrive ?) se fait via une bibliotheque (dont j'ai oublie le nom) qui par defaut va faire du polling sur le repertoire, mais qui si l'option qu'il faut est dans le noyau et que le filesystem le supporte, va utiliser un mecanisme du file system pour etre informe des modifications du repertoire.

Prenons un autre exemple: kio. C'est la facon standard sous KDE d'acceder a un fichier. kio offre des backend pour:
- local filesystem
- http
- ftp
- ssh
- samba
- nfs
- pda

Tu peux dire que kio n'offre qu'un sous-ensemble de tous les protocoles cites et c'est vrai. Je doute que tu puisses executer une commande ssh avec redirection de port via kio. Mais est-ce un probleme ? kio repond a une problematique, acceder a ses fichiers a distance de facon transparente pour toutes les applications KDE. Si tu veux faire de la redirection de port ssh, il semble plus correct d'utiliser directement ssh. Mais dans ce cas, tu changes la problematique, tu n'es plus en train d'acceder a tes fichiers a distance, tu es en train de faire un truc specifique a ssh.

De meme, la problematique de phonon n'est pas de tierer partie du moteur xine ou gstreamer pour faire du mixage video ou que sais-je, mais de fournir des fonctionnalites de base a l'utilisateur (cf la page web):
- faire en sorte que toutes les applications KDE puissent "faire du bruit" de facon simple sans se soucier du backend
- faire en sorte que KDE n'impose pas un moteur multimedia a l'utilisateur vu qu'il y en a pour tous les gouts et les couleurs
- pouvoir regler le son de facon simple sous KDE sous toutes les applications
- faire facilement de la capture de son

Le probleme pendant longtemp sous Linux a ete l'absence de moteur multimedia. Les differentes solutions developpees pallient cette absence, mais ont globalement un jeu de fonctionnalite tres similaire. Donc cette unification est plutot la pour gerer la diversite des moteurs multimedia et pas pour faire un meta-moteur.

--
phil.freehackers.org

[^]Re: Perte de fonctionnalités

Posté par wismerhill (page perso, ) le 28/04/2006 à 17:13. (lien). Évalué à 3.
Pas forcément.
Phonon pourrait supporter A B C et D avec une documentation claire disant que seuls B et C fonctionneront avec tous les systèmes. À charge ensuite aux développeurs des progammes de faire des choix et d'avertir clairement les utilisateurs de ce qui est nécessaire pour profiter des fonctionnalités.
Et ainsi quand un des backend ajoute le support d'une fonctionnalité il suffit de l'ajouter dans sa couche de liaison et les programmes qui utilisent cette fonctionnalité pourront aussi en profiter avec ce backend.

On pourrait même envisager que pour les fonctionnalités optionnelles il y aie une API parallèle qui permet aux programmes d'interroger phonon pour savoir si le backend actuel supporte telle fonctionnalité.
Les programmes pourraient ainsi s'adapter automatiquement au backend utilisé.

portabilité

Posté par CyrrusSmith (page perso, ) le 28/04/2006 à 15:32. (lien). Évalué à 4.

C'est vrai que l'envirronement KDE est tellement riche qu'il en devient un gros bout de système (vu par l'utilisateur) à lui seul.

S'il est portable sur windows ou d'autres OS, j'en viens à réver d'un système construit sur reactos (donc en partie FreeDOS) + KDE.

Avantages: utilisation des pilotes windows pour les matériels qui n'ont pas et ne peuvent avoir de pilotes GNU/Linux ou BSD, avec la richesse et la qualité de KDE...

Ceci dit personnellement je préfère quand même éviter ce genre de matériel, et je veille à n'acheter si possible que ce qui supporte des pilotes libres.

--
Il existe pour chaque problème complexe une solution
simple, directe et fausse.
H.L. MENCKEN

[^]Re: portabilité

Posté par Sarpedon () le 28/04/2006 à 18:13. (lien). Évalué à 4.
C'est vrai que l'envirronement KDE est tellement riche qu'il en devient un gros bout de système (vu par l'utilisateur) à lui seul.

100% d'accord.

D'ailleurs, si ca ne tenait qu'à moi d'organiser la stratégie marketing d'une communauté,
* on arrêterait de dire génériquement "moi j'utilise Linux", terme qui recouvre une telle variété d'usages que ca donne une vision totalement schizophrénique de ce qu'est le libre, voire contribue à renforcer son aspect "truc d'informaticiens, compliqué" puisque les gens entendent souvent parler de Linux pour l'infrastructure serveurs-BDD machin ou superorindateur truc. Personellement, je suis toujours décu d'entendre "XXX passe sous Linux" et de voir qu'il s'agit simplement de quelques serveurs
* on arrêterait de dire que "moi j'utilise distribution zYBXS", parce qu'il y en a beaucoup trop et trop peu différentes entre elles pour que ca parle aux gens, parce que dès qu'on commence à vanter distro XX, les trolls se précipitent, et parce que sur la durée c'est rarement significatif (il y a des bons crus et des mauvais crus et ca tient à pas grand chose).

Á la place, on dirait de "Moi j'ai GNOME sur mon ordi personnel", "Moi j'ai KDE sur mon ordi personnel". "Moi j'ai des serveurs sous Linux"

Là, au lieu d'avoir un terme ultra-flou ("Linux") ou 50 concurrents difficiles à départager ("Distribution XX"), on aurait les 3 cas d'utilisation les plus iimportants, ca correspondrait à quelquechose d'aussi concret pour les utilisateurs que "je suis sous MacOS X" ou "je suis sous Windows"

--
Kiu tro certas pri sia vero, kreas inferon sur la tero
- [^]Re: portabilité
  
  Posté par Nicolas Schoonbroodt (Jabber id, page perso, ) le 28/04/2006 à 18:23. (lien). Évalué à 5.
  Il faut dire :
  Moi j'utilise "`uname -a` `echo $SHELL $DESKTOP_SESSION $EDITOR`"
  
  Sinon c'est pas assez précis... (et en plus çane me donne pas la distrib avec mes paramètres... dommage)
  
  --
  [ Répondre ] Ce commentaire est-il impertinent ou utile ?
  - [^]Re: portabilité
    
    Posté par Julien Catalano (page perso, ) le 29/04/2006 à 17:23. (lien). Évalué à 1.
    
    Moi j'utilise "`uname -a` `echo $SHELL $DESKTOP_SESSION $EDITOR`"
    
    La magie des copier-coller:
    
    julien@ubuntu:~$ `uname -a` `echo $SHELL $DESKTOP_SESSION $EDITOR` bash: Linux: command not found
    
    arf!
    
    echo `uname -a` `echo $SHELL $DESKTOP_SESSION $EDITOR` marche mieux :-)
    
    Julien
    - [^]Re: portabilité
      
      Posté par Matthieu Moy (page perso, ) le 03/05/2006 à 22:58. (lien). Évalué à 3.
      En même temps, si tu avais copié-collé les guillemets doubles, tu aurais pas eu le problème.
      
      A part ça, après le UUOC (useless use of cat), un bel exemple de UUOE (useless use of echo) : `echo $FOO`.
- [^]Re: portabilité
  
  Posté par Mark Havel () le 28/04/2006 à 18:49. (lien). Évalué à 2.
  C'est vrai que j'ai de plus en plus l'impression que les grands environnements de bureaux comme KDE ou GNOME pourraient presque constituer à eux tout seuls une distribution Linux, enfin, un système d'exploitation complet quoi ; en se plaçant évidemment du point de vue de l'utilisateur. C'est d'ailleurs certainnement pas Ubuntu qui va me contredire.

[+] [^]Re: portabilité

Posté par GhZaaark3 () le 28/04/2006 à 19:09. (lien). Évalué à -2.
Portabilité, je ne vois tjrs pas l'intérêt d'un KDE sous windows qui n'est déjà pas très fortiche avec ses thèmes et autres extensions, mais bon, si ils - KDE/QT team - ont du temps et du pognon à gaspiller et si ils sont prêt à essuyer les critiques d'utilisateurs qui finalement ne comprennent rien au libre, tant mieux pour eux.

Finalement aussi grand KDéiste que je suis, je sens que j'm'en vais retourner vers un Fluxbox,

Ce n'est pas faire du chantage ou être puriste, mais mxxxx quoi, quel est cet argument à 2 balles qui fait croire qu'on popularisera ainsi mieux les LL?
On conforte plus la position de M$, car visiblement, ça gène moins d'utiliser un coeur proprio avec des apps libres.
Et puis avec l'arrivé de Vista, je doute que KDE for win32 puisse lever quoique ce soit, donc : Temps et ressources perdus.

En fait, toutes ces concessions me font de plus en plus m'interroger sur le libre car finalement, on ne s'impose jamais.

--
moué...
- [^]Re: portabilité
  
  Posté par agmk () le 28/04/2006 à 19:17. (lien). Évalué à 5.
  Il me semble que le principe c'est de porter le framework sous Windows, pour avoir toutes les applis KDE multiplateformes. Les parties fortement dépendantes du serveur X comme libplasma (ex-kicker kwin kdesktop) ne seront normalement pas disponibles sous l'OS de Redmond.
  
  --
  Wr ar fbhunvgr cnf ha qrfgva sharfgr à yn cncnhgé. Nzra.
- [^]Re: portabilité
  
  Posté par Juke (Jabber id, page perso, ) le 29/04/2006 à 00:37. (lien). Évalué à 3.
  Tourner sur un autre systeme d'exploitation, ça permet d'avoir une meilleure couche d'abstraction, ça permet egalement de montrer des bugs ou des faiblesse que l'ont aurait pas vu avant. Enfin, pour les developpeur ça permet de faire facilement du multiplateforme.
  
  Là je developpe un petit logiciel avec la Glib, pour manipuler les fichiers, j'utilise GnomeVFS qui offre une bonne couche d'abstraction du systeme de fichier, je peut par exemple utiliser de la meme façon des fichiers distants que des fichiers locaux.
  Je serais bien content si une fois ce soft developpé, je puisse le faire tourner sous windows sans rien changer.
  - [^]Re: portabilité
    
    Posté par reno () le 29/04/2006 à 08:40. (lien). Évalué à 3.
    Moui enfin les 2 logiciels libre multiplateformes les plus connus sont: OpenOffice et Mozilla.
    Ils sont aussi célebre pour être des monstres gourmands, la question est donc: est-ce lié?
    J'aurais tendance à penser que ce n'est pas obligatoire car Opéra bien que multi-plateforme est légé, mais le risque existe..
    - [^]Re: portabilité
      
      Posté par zero heure (Jabber id, page perso, ) le 29/04/2006 à 10:34. (lien). Évalué à 1.
      Dans la même classe deux gros programmes, Xara (dessin vectoriel) et Pixel (clone de Photoshop) sont multi-plateformes et légers. Donc non, ce n'est pas lié.
      
      --
      J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
      - [^]Re: portabilité
        
        Posté par Spack () le 29/04/2006 à 23:23. (lien). Évalué à 1.
        Xara je connais mais tu a un lien vers Pixel car je suis tombé sur ça ( http://www.mentalix.com/unixproducts/screenshots_pages/pixed(...) ) et je doute que ce soit de ça que tu parles :-)
        
        [^]lien vers Pixel
        
        Posté par zero heure (Jabber id, page perso, ) le 30/04/2006 à 22:38. (lien). Évalué à 3.
        Pas mal le lien!
        Voilà le Pixel dont je parlais: http://www.kanzelsberger.com/pixel/
        Pixel n'est pas libre. La liste des systèmes supportés par l'unique auteur du logiciel est impressionante:
        - PPC: MacOSX, MorphOS, Linux
        - x86: FreeBSD, SkyOS, Zeta/BeOS, Debian, QNX, Windows, DOS, Linux, eComStation
        - x86/64cmpt: Linux
        
        Un journal tchèque a comparé les principaux logiciels de traitements d'image. Pixel a été jugé très proche du niveau de Photoshop. C'est donc un gros programme, et pourtant il est étonnament rapide sur Debian (j'ai très peu testé).
        
        --
        J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
    - [^]Re: portabilité
      
      Posté par Gniarf () le 30/04/2006 à 14:05. (lien). Évalué à 1.
      ils sont surtout issus de deux logiciels propriétaires (StarOffice et Netscape Navigator/Communicator) qui se sont retrouvés libérés un jour.
      
      ils ont donc tout un historique qui fait qu'on ne peut pas les comparer à des logiciels nés libres, ou les appeller logiciels libres pour les comparer ensuite à des logiciels propriétaires
      
      --
      Windows has no users. It has hostages.
      - [^]Re: portabilité
        
        Posté par reno () le 02/05/2006 à 05:49. (lien). Évalué à 2.
        OOo cela je le savait, mais je croyais que Mozilla était une réécriture totale de Netscape?
        Si c'est vrai,dire que Mozilla est lourd a cause de son historique ne tient pas..
    - [^]Re: portabilité
      
      Posté par Philippe Fremy (page perso, ) le 30/04/2006 à 14:13. (lien). Évalué à 4.
      
      Moui enfin les 2 logiciels libre multiplateformes les plus connus sont: OpenOffice et Mozilla.
      Ils sont aussi célebre pour être des monstres gourmands, la question est donc: est-ce lié?
      J'aurais tendance à penser que ce n'est pas obligatoire car Opéra bien que multi-plateforme est légé, mais le risque existe..
      
      Et justement, opera utilise Qt, tout comme KDE.
      
      --
      phil.freehackers.org
  - [^]Re: portabilité
    
    Posté par golum () le 29/04/2006 à 10:28. (lien). Évalué à 2.
    Oui et puis surtout, chez KDE ils anticipent la migration sur les os qui ont de l'avenir car tout le monde ici a compris ici que Linux is dead ;^)
    pom pom pom ======> [ ]
- [^]Re: portabilité
  
  Posté par Philippe Fremy (page perso, ) le 30/04/2006 à 14:11. (lien). Évalué à 2.
  Ce portage vers windows ne fait pas l'unanimité dans la communauté KDE. Mais bon, je vois mal les développeurs KDE interdire à qq'un de faire le portage. Pour un soft en LGPL/BSD, ce serait un comble.
  
  Par contre; je ne sais pas où tu as rêvé que ce portage coûtait du temps ou de l'argent à Qt ou KDE. Qt tourne sous windows depuis la version 1.0 donc pas d'impact de ce côté-là. Concernant KDE, ce ne sont pas les gens qui dévelppaient auparavant sur KDE qui font le portage windows, ce sont des gens qui n'interviennent que sur cet aspect-là. Il n'y a donc pas de gachis ou de perte, simplement des contributeurs supplémentaires qui travaillent sur un aspect du projet qui n'avait pas encore été exploré.
  
  En revanche, visiblement, David Faure a accès à un MacOs X et patch régulièrement pour cette plate-forme.
  
  En tout cas, le projet KDE n'a pas dit "on va porter KDE sur windows parce que c'est une plateforme stratégique". C'est une bande de contributeurs indépendants qui font le travail, qui a d'ailleurs longtemp été héberge sur sourceforge, en tant que projet indépendant de KDE. Ils n'ont pas reçu d'interdiction de KDE de faire ce boulot.
  
  --
  phil.freehackers.org
  - [^]Re: portabilité
    
    Posté par GhZaaark3 () le 30/04/2006 à 22:20. (lien). Évalué à 1.
    Dit comme ça, c'est rassurant Phillippe.
    Encore un manque de rigueur dans les annonces.
    "Un groupe de contributeur externe décide de porter KDE sur Windows"
    c'est moins equivoque tout d'même, non?
    
    Merci
    
    --
    moué...

Pour la culture générale

Posté par Mais qui suis-je ? :) () le 28/04/2006 à 19:10. (lien). Évalué à 4.

Pour ceux que ça intéresse
un phonon désigne un quanta de vibration dans un cristal.
Wikipedia vous l'expliqueras mieux que moi
http://fr.wikipedia.org/wiki/Phonon

On peut se poser la question de la pertinence (physique )du nom: alors que Solide et Plasma désigne des états de la matière, le phonon désigne une quasi particule.

Pour mémoire les 4 (où 5 ) états de la matière sont (du plus froid au plus chaud ) Solide, Liquide, Gaz, Plasma (par exemple dans le soleil), auquel on peut ajouter le plasma quark-gluon (univers primordial )

[^]Re: Pour la culture générale

Posté par ThesmallgamerS () le 28/04/2006 à 19:36. (lien). Évalué à 6.
A ces 5 là, il faut rajouter le condensat de bose-einstein et dérivé : des états de la matière a très basses températures.
A être physicien, autant ne pas l'être a demi. Non mais.

[^]Re: Pour la culture générale

Posté par Matthieu Duchemin (page perso, ) le 29/04/2006 à 10:48. (lien). Évalué à 3.
on peut dire qu'il n'existe que deux états de la matière : solide, fluide. il n' y a que quand on passe d'un état solide à un état fluide que la transition est bien définie. Pour le reste, la transition est, en général, mal définie et se fait sur une "zone de transition" plus ou moins étendue.
- [^]Re: Pour la culture générale
  
  Posté par wismerhill (page perso, ) le 29/04/2006 à 11:53. (lien). Évalué à 2.
  Et encore, seulement si tu parle de solide cristallin, car pour des amorphes ce n'est pas si clair.
  
  C'est bien ce caractère cristallin qui fait une transition bien nette, car il y a une barrière de potentielle bien définie à la liaison cristalline.
  
  Cependant, c'est beaucoup trop réducteur de se baser sur la seule transition pour définir des états de la matière. Car même si les liquides et les gaz ont énormément en commun (et ne sont plus distinguable dans certaines conditions), il n'en reste pas moins qu'on peut les modéliser de façon différente (fluide "incompressible", gaz "parfait").
  
  Enfin, ces distinction en quelques états bien définis marchent pas mal pour des éléments simples, des métaux, des molécules de petites tailles genre H2O.
  Si on commence à jouer avec des molécules plus complexes on va découvrir des propriétés qui ne correspondent à aucune des classes simples citées précédemment.
  Que dire des colloïdes, ou des nano-tubes de carbonne?
  Mieux, la membrane cytoplasmique d'une cellule, comment la classerais-tu?
  
  Ce classement simple en états de la matière fonctionne bien pour des cas simples.
  - [^]Re: Pour la culture générale
    
    Posté par ThesmallgamerS () le 29/04/2006 à 15:52. (lien). Évalué à 2.
    Je continue, tire et marque. La transition vers l'état de condensat de bose-einstein est extrémement délimité (comme toute transition quantique). En dessous d'une certaine temperature limites, dépendant de si la molécule considéré est un boson ou un fermion, les particules tombent toutes au niveau d'énergie quantique, produisant entre autre effets de bords un réarrangement atomique en cascade.
    Espéces d'incultes.
    - [^]Re: Pour la culture générale
      
      Posté par ThesmallgamerS () le 29/04/2006 à 15:54. (lien). Évalué à 1.
      s/niveau d'énergie quantique/plus bas niveau d'énergie quantique.
      
      Mais je continue d'affirmer que vous êtes tous des incultes. ;-)
      - [^]Re: Pour la culture générale
        
        Posté par Xion345 (Jabber id, ) le 30/04/2006 à 19:21. (lien). Évalué à 4.
        Je vais me faire moinsser mais tant pis j'assume.... (Essayez quand même de me maintenir au dessus de -10). C'est pas grave, c'est mon premier message depuis longtemps qui a une note de 1 par défaut...
        
        Voilà que l'on trolle sur de la Physique/Chimie maintenant sur linux-fr.
        Vous essayez de me traumatiser hein... Oui, j'ai pas fini mes exercices de Physique et alors ?
        
        C'est qu'on arriverait à nourrir des trolls bien poilus et potelés avec pas mal de choses sur troll-fr.org, le plus libre des troll.
        Linux-fr est à mon avis un des seuls sites francophones où on peut en arriver à parler d'états de la matière à partir d'un article sur KDE. Enfin, c'est de l'humour, je trouve ça très positif, on apprend beaucoup de choses.
        
        En parlant, d'états de la matière, un "gel" appartient à quel état ? Liquide, solide, gazeux, plasma, bose-einstein.
    - [^]Re: Pour la culture générale
      
      Posté par Mais qui suis-je ? :) () le 05/05/2006 à 16:11. (lien). Évalué à 2.
      
      En dessous d'une certaine temperature limites, dépendant de si la molécule considéré est un boson ou un fermion
      
      La par contre il y a un truc que je comprend pas
      si on parle de Boson pas de probleme on condense ...
      Par contre avec des fermions : Principe d'exclusion toussa ...
      C'est une faute d'inatention
      ou bien il y a dans ce cas creation de systeme de simili-boson de type paire de Cooper ?
      
      P.S.
      dsl de te poser la question tard j'avais oublier ce post
      - [^]Re: Pour la culture générale
        
        Posté par ThesmallgamerS () le 05/05/2006 à 19:40. (lien). Évalué à 1.
        Exactement. Pour de l'helium 3, par exemple, ou tout autre assemblage de bosons, la température limite est environ mille fois plus haute que pour de l'hélium 4 où des paires de cooper se forment néanmoins a un certain niveau de T°. Je ne sais pas si ça a été prouvé mathématiquement (surtout que le modéle est semble t'il absent), mais normalement cela marche pour toute molécule.
        
        M'enfin, je commence a être fatigué, là... Et physicien, c'est pas mon travail. Je suis J2EE Lead Architect, moi.

Question

Posté par F. Orieux () le 28/04/2006 à 20:23. (lien). Évalué à 2.

Comme je ne suis pas expert, j'aimerais savoir pourquoi faire une surcouche ? Ca apporte quoi plutot que de choisir quelque chose directement comme au hasard gstreamer (ou autre). J'ai l'impression que ça fait apprendre une API plutôt qu'une autre.

[^]Re: Question

Posté par wismerhill (page perso, ) le 28/04/2006 à 20:35. (lien). Évalué à 2.
Parce que dans ce cas tu ne pourra utiliser que gstreamer, et les gens qui voulaient utiliser autre chose vont se plaindre.
Avec cette couche d'abstraction il suffit d'écrire la partie de liaison vers un backend spécifique et tous les programmes qui utilisent l'API phonon fonctionneront sans modification.

[^]Re: Question

Posté par Narishma Jahar () le 28/04/2006 à 20:55. (lien). Évalué à 2.
Pour ne pas avoir à dépendre de gstreamer (ou autre) pendant toute la durée de vie de KDE 4.x comme ça a été le cas avec aRts.

Pour ne pas avoir à porter gstreamer (ou autre) sur toutes les plateformes que KDE 4.x supportera (windows, osx...).

Pour simplifier la vie aux développeurs des applications KDE qui n'ont pas à apprendre une API complètement différente de ce dont ils ont l'habitude.
- [^]Re: Question
  
  Posté par F. Orieux () le 29/04/2006 à 16:14. (lien). Évalué à 2.
  Pour ne pas avoir à dépendre de gstreamer (ou autre) pendant toute la durée de vie de KDE 4.x comme ça a été le cas avec aRts.
  
  Ca ne fait que reporter le problème non ? Il dépendront de phonon et plus de arts. Et en plus phonon dépendera de tout les moteurs (si une modif est casse leur truc faudra bien réagir)
  
  Pour ne pas avoir à porter gstreamer (ou autre) sur toutes les plateformes que KDE 4.x supportera (windows, osx...).
  
  Je connais mieux gstreamer, c'est pour ça que j'en parle, mais il me semble que c'est une lib assez portable déjà. Pourquoi bosser sur leur truc plutot que de contribuer à gstreamer pour la rendre plus portable ? (vrai question, pas une critique)
  
  Pour simplifier la vie aux développeurs des applications KDE qui n'ont pas à apprendre une API complètement différente de ce dont ils ont l'habitude.
  
  Ils ont déjà l'habitude de phonon ? De plus j'ai lu qu'avec gstreamer, pour des besoins de base, c'est rapide à coder, et vite fonctionnel.
  
  Ce que je ne comprend pas c'est qu'il parle d'abstraction alors que ces moteur la fond déjà (enfin je crois). Ensuite il parle de besoin de base et que les applis poussées ou spécialisées utiliserons directement le moteur de leur choix. Si c'est pour du son de base, je reviens sur gstreamer qui à la réputation d'être rapide à coder et efficace.
  
  Je comprend toujours pas leur motivation :). Vu la difficulté et le temps que ca demande de faire un truc comme ça il doivent avoir de bonne raison (autre que le mauvais souvenir d'un démon de son) pour le faire.
  - [^]Re: Question
    
    Posté par agmk () le 29/04/2006 à 16:46. (lien). Évalué à 4.
    À mon avis ils n'ont aussi pas envie de se prendre la tête à utiliser un framework en C, Phonon doit servir de couche propre et cohérente avec le reste de l'API KDE en C++.
    
    --
    Wr ar fbhunvgr cnf ha qrfgva sharfgr à yn cncnhgé. Nzra.
  - [^]Re: Question
    
    Posté par Aiua () le 29/04/2006 à 16:56. (lien). Évalué à 4.
    Je ne suis pas sûr que tu ais bien compris ce que fait phonon...
    phonon en lui même ne fait "rien", ce n'est pas un moteur de son, c'est une couche d'abstraction au dessus des moteurs de son (ça fait donc des appels à ces moteurs de sons).
    
    Le problème avec aRts ce n'est pas forcément qu'il était intrinsèquement mauvais, mais qu'il n'était plus maintenu, et ils ne veulent plus se retrouver dans le même cas, "chat échaudé craint l'eau froide" comme on dit, donc ils ne veulent pas se bloquer sur un seul moteur de son.
    
    Avec phonon si demain gstreamer (ou NMM, ou ...) tombait en décrépitude, KDE n'en souffrirait pas.
    
    Ca n'enlève rien aux qualités de gstreamer, et ce n'est pas vraiment un pb de portabilité.
    - [+] [^]Re: Question
      
      Posté par Mickaël L () le 30/04/2006 à 06:56. (lien). Évalué à -1.
      Ben alors si ça ne fait rien, pourquoi le mettre?
      - [^]Re: Question
        
        Posté par Narishma Jahar () le 30/04/2006 à 16:11. (lien). Évalué à 0.
        Je l'ai déjà dit plus haut.

[^]Re: Question

Posté par Sylvain Forêt () le 29/04/2006 à 00:55. (lien). Évalué à 0.
Le seule raison que je vois est que les développeurs de KDE ne veulent pas se retrouver dépendant d'une bibliothèque qui n'est plus maintenue.

Je pense donc, malgré l'immense respect que j'ai pour eux, qu'ils ont fait un mauvais choix (ou alors quelque chose m'échappe).

En effet, ils ne satisfont ni les amateurs de Xine qui aiment la fonctionnalité A (que Gstreamer n'a pas), ni les utilisateurs de Gstreamer qui veulent la fontionnalité B (que Xine n'a pas).
En fait, ils déçoivent les deux.

Pour ce qui est du coté multi-OS, je ne sais pas pour Xine, mais Gstreamer compile pour linux, pour différent BSDs et pour Window$.

Finalement, pour ce qui est de se retrouver avec une bibliothèque qui n'est plus maintenue, je ne crois pas que les risques soient grand avec Gstreamer, vu le dynamisme de son dévelopement et son utilisation dans de nombreux projets, dont Gnome.
Si KDE avait choisit cette bibliothèque, tout risque d'abandon de cette bibiothèque aurait encore diminué.

Cela m'attriste, mais ce projet m'apparait comme un effort inutile.

Le 'design' logiciel (ou autre) est avant tout l'art de faire des choix, or il semble que gens de KDE ont décidé de ne pas se décider et toute l'élégance des couches intermédiaires orienté object, blablabla ... ne leur rendra jamais les foncionalités qu'ils se sont refusé, la lourdeur ajouté et le fait qu'un nouveau projet ad hoc comme Phonon a plus de chance d'être abandonné par ses développeurs qu'une librairie qui aurait été partagée par plusieurs environnements de bureau.
- [^]Re: Question
  
  Posté par Gof (Jabber id, page perso, ) le 29/04/2006 à 06:36. (lien). Évalué à 3.
  Il n'y a pas que le problème de "lib non maintenue"
  Il y a aussi l'important problème de l'incompatibilité entre eux des différents moteur pour faire du mixage logiciels.
  
  Comme Gnome utilise esd, pour faire tourner une appli kde dans gnome, ce serait bien s'il pouvait aussi utiliser esd.
  
  (Oui, je sais: alsa fait maintenant le mixage logiciel, mais tout le monde a pas dmix, et c'est quand même mieux niveau performance de n'avoir que un moteur de son)
  
  Quand au problème des fonctionalités A et B, c'est un faux problème, voir plus haut.
- [^]Re: Question
  
  Posté par patrick_g (page perso, ) le 29/04/2006 à 07:11. (lien). Évalué à 3.
  je suis en partie d'accord avec toi et je pense que GStreamer aurait été un choix logique. Mais il faut aussi reconnaitre que le projet NMM est très innovant avec sa transparence réseau totale. Certains dev de KDE ont voulu se préserver leurs chances d'utiliser NMM facilement et Phonon est la réponse à cette problématique.

Revenir en haut de page

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Dépêche éditée par

Articles : Annonce du projet Phonon

Et la légéreté ?

[^]Re: Et la légéreté ?

[^]Re: Et la légéreté ?

[^]KDE 4.0 Release Plan

[^]Re: Et la légéreté ?

[^]Re: Et la légéreté ?

[^]Re: Et la légéreté ?

[^]Re: Et la légéreté ?

[+] [^]Re: Et la légéreté ?

[^]Re: Et la légéreté ?

[^]Re: Et la légéreté ?

[^]Re: Et la légéreté ?

[^]Re: Et la légéreté ?

Engin ?

[^]Re: Engin ?

[^]Re: Engin ?

[^]Re: Engin ?

Perte de fonctionnalités

[^]Re: Perte de fonctionnalités

[^]Re: Perte de fonctionnalités

[^]Re: Perte de fonctionnalités

[^]Re: Perte de fonctionnalités

[^]Re: Perte de fonctionnalités

portabilité

[^]Re: portabilité

[^]Re: portabilité

[^]Re: portabilité

[^]Re: portabilité

[^]Re: portabilité

[+] [^]Re: portabilité

[^]Re: portabilité

[^]Re: portabilité

[^]Re: portabilité

[^]Re: portabilité

[^]Re: portabilité

[^]lien vers Pixel

[^]Re: portabilité

[^]Re: portabilité

[^]Re: portabilité

[^]Re: portabilité

[^]Re: portabilité

[^]Re: portabilité

Pour la culture générale

[^]Re: Pour la culture générale

[^]Re: Pour la culture générale

[^]Re: Pour la culture générale

[^]Re: Pour la culture générale

[^]Re: Pour la culture générale

[^]Re: Pour la culture générale

[^]Re: Pour la culture générale

[^]Re: Pour la culture générale

Question

[^]Re: Question

[^]Re: Question

[^]Re: Question

[^]Re: Question

[^]Re: Question

[+] [^]Re: Question

[^]Re: Question

[^]Re: Question

[^]Re: Question

[^]Re: Question