Annonce du projet Phonon

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes : aucune
0
28
avr.
2006
KDE
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". 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.

Aller plus loin

  • # Et la légéreté ?

    Posté par  . É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  . É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  (site web personnel) . É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.

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

      Posté par  (site web personnel) . É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.

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

        Posté par  . É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  (site web personnel) . É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 ?

  • # Engin ?

    Posté par  (site web personnel) . É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

  • # Perte de fonctionnalités

    Posté par  (site web personnel) . É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  . É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  . É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  . É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  (site web personnel) . É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.

    • [^] # Re: Perte de fonctionnalités

      Posté par  . É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  (site web personnel) . É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.

    • [^] # Re: portabilité

      Posté par  . É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"

      • [^] # Re: portabilité

        Posté par  . É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)

        • [^] # Re: portabilité

          Posté par  . É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  (site web personnel) . É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  . É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  . É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.

      • [^] # Re: portabilité

        Posté par  . É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.

      • [^] # Re: portabilité

        Posté par  (site web personnel) . É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  . É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  . É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é.

            "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

            • [^] # Re: portabilité

              Posté par  . É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  . É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é).

                "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: portabilité

            Posté par  . É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

            • [^] # Re: portabilité

              Posté par  . É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  (site web personnel) . É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.

        • [^] # Re: portabilité

          Posté par  . É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  (site web personnel) . É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.

        • [^] # Re: portabilité

          Posté par  . É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

  • # Pour la culture générale

    Posté par  . É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  . É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  (site web personnel) . É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  . É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  . É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  . É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  . É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  . É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  . É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  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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  . É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++.

        • [^] # Re: Question

          Posté par  . É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  . É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  (site web personnel) . É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  (site web personnel) . É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.

Suivre le flux des commentaires

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