Y : un remplaçant pour X ?

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
1
6
mar.
2004
Serveurs d’affichage
En juin 2003, un étudiant du Department of Computing l'Imperial College de Londres, Mark Thomas, présentait son projet de 4ème année : Y un successeur du X Window System.

À partir d'une étude approfondie des différents systèmes existants ou en projet (X, Aqua, Windows, Fresco, PicoGUI...) il définit un protocole très prometteur, gardant les meilleurs aspects de chacun d'eux.

Son projet comporte également une implémentation basique mais fonctionnelle de son serveur, avec quelques applis de démonstration.

Depuis le mois dernier, un groupe de développeurs s'est peu à peu constitué autour de Mark pour développer le projet Y-Windows. Ce projet est diffusé sous licence GPL pour le serveur et LGPL pour les bibliothèques client. Les principales caractéristiques de Y sont :
- Des widgets côté serveur, accélérant les connexions sur un réseau et permettant le "Y-forwarding" même sur internet.
- Support Unicode
- Véritable alpha blending en 32bit.
- Des modules chargeables à chaud

Pour faciliter le passage de X à Y, le portage des principales boîtes à outils (Qt, GTK, wxWidgets, ...) est à l'étude. De plus, un module sera créé pour faire fonctionner les applications écrites pour X sous Y, en attendant qu'elles soient réécrites nativement pour Y.

Actuellement, Y se compose d'un serveur, d'une bibliothèque client, et de quelques applications de démonstration. La connexion au serveur peut se faire par un socket unix ou par TCP/IP. À noter toutefois qu'aucun système de sécurité n'a encore été implémenté.

Aller plus loin

  • # Re: Y : un remplaçant pour X ?

    Posté par  (site web personnel) . Évalué à 9.

    Il semble bien que la succession au serveur X soit ouverte. C'est manifestement l'une des prochaines grandes étapes de l'évolution des Logiciels Libres. Vu que ce serveur arrive au moment où Xfree a de gros problèmes existentiels, il faut espérer que tous ces projets alternatifs puissent accoucher d'une solution viable.

    • [^] # Re: Y : un remplaçant pour X ?

      Posté par  (site web personnel) . Évalué à -5.

      ... dans cinq ans.

      Bon, ben moi je vais aller me compiler XFree86 4.4.

      • [^] # Re: Y : un remplaçant pour X ?

        Posté par  . Évalué à 5.

        il faut bien penser un peu au long terme

        en tout cas, j'ai regardé un peu la mailing-list, ca a l'air plutot actif

        • [^] # Re: Y : un remplaçant pour X ?

          Posté par  (site web personnel) . Évalué à 3.

          C'est souvent très actif au début les mailing list de projet.

          On a de grandes ambitions, de grandes visions, ça avance bien, on se concerte pour décider de trucs, et à un moment donner ça va patiner pour une raison quelconque et les gens vont perdre de l'intêret...

          Moi, pessimiste? Nooon... :)

          • [^] # Re: Y : un remplaçant pour X ?

            Posté par  . Évalué à 3.

            Ça fait un moment qu'on en parle de Y, là c'est juste l'impléentation qui vient réellement d'être lancée.

            Et sa conception de base est vraiment intéressante : reprendre les bonnes idées de X tout en le corrigeant. Le but n'étant pas de faire une nouvelle implémentation de X11, mais de créer un nouveau protocol (d'où le nom : Y ). Enfin, ça c'est si j'ai bien compris. Moi je suis assez enthousiaste quand au futur de ce projet qui pourrait très bien se développer très rapidement.

            Ça ne peut laisser augurer que du bon. Sachant qu'en plus la licence choisie est la LGPL, ça pourra permettre d'éviter des problèmes futurs, tout en permettant l'utilisation de progs non libres dessus.

            Allez hop, une bonne dose d'optimisme, on sait jamais ^^

            • [^] # Re: Y : un remplaçant pour X ?

              Posté par  (site web personnel) . Évalué à 1.

              a prioris le protocole X11 est prévus pour être extensible : en créé un nouveau n'a pas vraiment d'interret. Surtout qu'ils ont eu ONZE version pour maximiser les perf par le réseau...

              "La première sécurité est la liberté"

              • [^] # Re: Y : un remplaçant pour X ?

                Posté par  . Évalué à 1.

                Ca tombe bien, les sources sont libres...

              • [^] # Re: Y : un remplaçant pour X ?

                Posté par  (site web personnel) . Évalué à 2.

                Voire, quand tu discutes avec des dieux de X, ils te disent que la meilleure partie de X, c'est vraiment son protocole, qui a quand meme survecu 15 ans qui assure l'interoperabilite entre une vingtaine de serveurs X. Donc je doute que ce soit la partie a remplacer. C'est plutot en effet les aller-retours clients/serveurs et les operations synchrones qui posent des problemes.

                En ce qui me concerne, je crois qu'aucun projet de serveur graphique ne pourra s'imposer sans une compabilite tres forte avec X au niveau de la base existante. Coup de bol, c'est prevu. M'enfin, je reste tres tres tres sceptique et je crois bcp plus a la re-ecriture de la xlib.

                • [^] # Re: Y : un remplaçant pour X ?

                  Posté par  (site web personnel) . Évalué à 3.

                  C'est bien ce qu'explique le document : le protocole X est bien, mais il commence à avoir pas mal vécu, il a été étendu dans tous les sens, ce qui entraine parfois des incohérences entre modules ou un prix trops élever à payer (en terme de performances ou de facilité d'utilisation) pour assurer la compatibilité entre toutes les parties.

                  Ce que propose l'auteur d'après ce que j'ai compris au document, c'est de reprendre le protocole X en y intégrant dès le debuts certaines choses qui lui manque et qu'il serait difficile d'intégrer, malgrès son caractère extensible.

                  Le protocle Y est un successeur de X, donc l'auteur ne jette pas tout :l'auteur veut réécrire le protocole pour lui faire profiter de 20 ans d'expérience et rendre le tout cohérent et plus en phase avec les avancées techniques.
                  De plus, je crois qu'il pense clairement implémenter une couche de compatibilité X/Y pour assurer la transition (si elle doit se faire).

                  C'est pourquoi, je trouve sa démarche très intéressante. Je pensais également que le protocole X étant vraiment bon. À lire le PDF, je me rend compte que pas de choses peuvent être améliorer.

                • [^] # Re: Y : un remplaçant pour X ?

                  Posté par  . Évalué à 5.

                  En ce qui me concerne, je crois qu'aucun projet de serveur graphique ne pourra s'imposer sans une compabilite tres forte avec X au niveau de la base existante.

                  A mon avis il suffit que Gtk et Qt soient portes pour que la plupart des gens considerent la compatibilite suffisante.

                • [^] # Re: Y : un remplaçant pour X ?

                  Posté par  (site web personnel) . Évalué à 4.

                  > je crois qu'aucun projet de serveur graphique ne pourra s'imposer sans
                  > une compabilite tres forte avec X au niveau de la base existante. Coup
                  > de bol, c'est prevu.

                  La compatibilité, avec le X actuel, c'est déjà du domaine du passé. Je travaille souvent sur une machine Linux qui déporte l'affichage sur une SUN, et les applications récentes (Gtk, Qt, ...) plantent souvent sur un "Missing extension machin-bidule", ou pas de message d'erreur du tout, alors que les mêmes applications marchent sur un affichage XFree86.

                  Bref, l'idée de garder l'existant pour la compatibilité et de ne faire que des extensions, si c'est pour n'avoir plus que des extensions à la fin, ça n'est pas très intéressant ...

                  • [^] # Re: Y : un remplaçant pour X ?

                    Posté par  (site web personnel) . Évalué à 1.

                    C'est pour ça que X.org reprend aujourd'hui du service. Le but est de définir ce qu'est X et de coller au temps qui passe, comme par exemple en définissant le standard comme étant le protocole X + les extensions machins et bidules de façon à ce que toutes les implémentations de X rassemblent au minimum un certains nombres d'extension devenues standard et qu'on ne voit plus apparaitre le genre de problèmes que tu soulèves.

                  • [^] # Re: Y : un remplaçant pour X ?

                    Posté par  . Évalué à 1.

                    Bah, meme entre 2 Sun, il peut y avoir des problemes..

                    J'étais ahuri quand j'ai découvert que dtpad et dtbrowse ne marche pas correctement en export DISPLAY..

                    Quel m@@@@ CDE..

      • [^] # Re: Y : un remplaçant pour X ?

        Posté par  . Évalué à -1.

        Pour information, XFree ne s'est pas bati en un jour ni comme tout autre projet autour et sans rapport avec les LL.

        Une remarque comme celle ci mériterai -7 ou plus car elle donne pas du tout envie de développer des projets libres ou non.

        Si tu créait un projet de ce genre et que quelqu'un te disait une remarque de ce genre, quelle serait ta réaction ?

        • [^] # Re: Y : un remplaçant pour X ?

          Posté par  (site web personnel) . Évalué à -3.

          Pour information, XFree ne s'est pas bati en un jour ni comme tout autre projet autour et sans rapport avec les LL.

          Je ne comprends pas la fin de ta phrase, et puis je suppose que tu parles de XFree86 ?

          Une remarque comme celle ci mériterai -7 ou plus car elle donne pas du tout envie de développer des projets libres ou non.

          Effectivement, elle a plus. Ceci dit, je ne vois pas pourquoi tu trouves qu'elle ne donne pas envie de développer des projets.

          Si tu créait un projet de ce genre et que quelqu'un te disait une remarque de ce genre, quelle serait ta réaction ?

          Ce connard a bien raison. Allez, dans cinq ans, il changera d'avis !

    • [^] # Re: Y : un remplaçant pour X ?

      Posté par  . Évalué à 6.

      Oui, sans même parler de la qualité technique de XFree ou de ses concurrents, les récentes histoires de licence en ont refroidi plus d'un (je pense aussi à l'"affaire" Apache).

      Y a pour lui d'avoir clairement identifié ce qui pose problème dans X et d'y proposer des solutions alléchantes (que ce soit du code plus lisible, une modularisation accrue, travailler sur des widgets complètes plutôt que des primitives partout où c'est possible, avoir un toolkit graphique par défaut...). Le pdf du rapport préliminaire est très intéressant à lire pour ça, si seulement tous les projets de LL proposaient de la doc aussi claire...

      Ceci dit, c'est pas demain la veille qu'on pourra utiliser Y: pas d'accélération matérielle (un truc relativement important pour l'utilisation d'un*x et dérivés dans pas mal d'industries), le système de hotplug de modules pas encore en place... mais ça reste quand même alléchant (et il y a des bindings en python et perl, ça laisse pas à la porte les gens qui sont allergiques au C)

      • [^] # Re: Y : un remplaçant pour X ?

        Posté par  (site web personnel) . Évalué à 9.

        Ceci dit, c'est pas demain la veille qu'on pourra utiliser Y (...)
        Il est déjà possible de l'utiliser en surcouche de X/SDL ce qui permet de développer facilement des extensions (portage de Qt/GTK/wxWidget/XUL/...)
        même si les drivers directs ne sont pas encore dispos (y a déjà un framebuffer linux).

        De plus le mode de développement a l'air beaucoup plus ouvert que celui de XFree86 et le projet Y utilise notamment Gnu-Arch (et non pas CVS) pour un mode de développement distribué à la "kernel Linux". Cela permettra d'inciter les developpeurs potentiels à se lancer dans des forks innnovants avec la possibilité de plus tard retransmettre ces innovations dans la branche de base grace à star-merge :o)

        Y a aussi un wiki en place. Même s'il y a pas grand chose dedans pour l'instant, il est déjà bien organisé et pret à recevoir des contributions des utilisateurs/développeurs. Ca montre bien la volonté de bien faire de l'auteur du projet.

        Il faudrait peut être aussi considérer une collaboration avec le projet freedesktop.org.

        Bref souhaitons leur bonne chance. Ils partent sur de bonnes bases.

    • [^] # Re: Y : un remplaçant pour X ?

      Posté par  . Évalué à 2.

      Autant c'est bien de vouloir trouver un remplaçant à XFree86, autant je reste perplexe face au nombre de projets qui veulent réinventer la roue. Il y a déjà xserver (http://xserver.freedesktop.org/(...)), xouvert et maintenant Y ?? (et je ne parle pas des anciennes tentatives telles que Berlin/Fresco)

      Il est évident que sur un tel créneau, un projet sera choisi majoritairement par les distributions Linux (parce qu'il sera plus abouti, mieux supporté, etc.) et les autres tomberont dans l'oubli. Alors pourquoi ne pas chercher à mutualiser les efforts dès le début ?

      • [^] # Re: Y : un remplaçant pour X ?

        Posté par  . Évalué à 6.

        > pourquoi ne pas chercher à mutualiser les efforts dès le début ?
        Parcequ'on est jamais sur que le projet le plus "en vu" soit le plus performant et que la diversité des projets permet à une diversité d'idées de s'exprimer, et donc à la fin tout le monde y gagne.
        Dans ce cas précis, on a un bon exemple d'une base de dev, X, utilisé par une majorité de projet (XFree, Xouvert, Xserver ....) et un nouveau projet qui essais de créer un protocol plus performant que X en s'aidant du meillieur des projets actuels et passé.

        • [^] # Re: Y : un remplaçant pour X ?

          Posté par  (site web personnel) . Évalué à 1.

          Tout a fait. Il y avait une tres bonne analyse de Linus je ne sais plus ou sur le sujet.

          La force du logiciel libre, c'est la diversite de l'ecosysteme. Je fais partie de ceux qui pestent a cause de la separation des efforts, mais c'est ca aussi qui permet d'essayer des idees differentes et de proposer des solutions innovantes.

          Il y a toujours deux approches possibles: la cathedrale ou tu fais tes plans et avec ton equipe, tu construis ton bazar. Tu sais ou tu vas et si tu t'es pas goure dans tes plans, ca marche. Sauf si t'avait pas vu au depart quelques subtilite qu'on ne rencontre qu'un milieu de projet.

          Le bazar: tout le monde fait n'importe quoi et a la fin, ceux qui ont survecu et qui apportent qqch emergent. Ca prend plus de temps mais le resultat est plus robuste. Et surtout, il y a plusieurs voies qui sont envisagees.

          • [^] # Re: Y : un remplaçant pour X ?

            Posté par  . Évalué à 2.

            On peut beaucoup rapprocher ca a une vision "ecologique" du systeme (j'adore faire les comparaisons dans les deux sens ;) ) :
            si il n'y a qu'un gros animal, tres performant certe, il y a des problemes quand l'environnement change et qu'il n'est plus adapte ou bien qu'il se fait manger par une bestiole plus grosse.
            Si plusieurs especes d'animaux existent, plus ou moins performants, si l'environnement change, il y en aura sans doute un qui aura la chance d'etre plus adapte que dans le milieu precedent, ou bien encore si y'en a un qui se fait bouloter, il en reste d'autres...
            m'enfin je m'emporte...

            en bref, le fond, c'est qu'un peu de diversite ne fait pas de mal, meme si on a l'impression de laisser des forces dans la desunion.

      • [^] # Re: Y : un remplaçant pour X ?

        Posté par  . Évalué à 4.

        Bah, le probleme c'est qu'il y a plein de possibilitées differente pour implementer l'equivalent de X, alors forcément cela génere plusieurs projets différents..

        D'autant plus que le but de ces projets est différent: le but du Berlin|Fresco actuel est de faire les choses bien en pensant au futur: par exemple ils utilisent les flottants pour les coordonnées..

        Le but initial de PicoGUI était les PDA, les petits environnement, comme son nom l'indique, alors forcément dans ces environnements ou souvent le CPU n'a même pas de FPU, on utilise des entiers pour les coordonnées..

        Lequel est le mieux? Entier, Flottant?
        Et bien ça dépend du contexte --> plusieurs projets..

        Note: ça fait un certain temps que je me suis intéréssé a Berlin|Fresco donc je peux dire des bétises..

      • [^] # Re: Y : un remplaçant pour X ?

        Posté par  (site web personnel) . Évalué à 5.

        Mutualiser dès le départ : la belle utopie ! C'est comme ça que tout le monde va dans le mur en même temps.
        Les logiciels libres, c'est LIBRE , par conséquent tout le monde a le droit de faire valoir ses idées. C'est la meilleure façon de rechercher toutes les voies possibles afin de trouver la meilleure (ou les meilleures). De plus, il n'y a que les gens compétents qui interviennent, ceux qui sont capables de réaliser. C'est pourquoi les projets fortement créatifs ne peuvent pas être gérés comme des entreprises de production.

    • [^] # Re: Y : un remplaçant pour X ?

      Posté par  . Évalué à 4.

      Oui c'est clairement LA prochaine étape du logiciel libre : 1)la chaîne de développement (merci Richard) 2)le noyau (merci Linus) 3)le serveur graphique....merci qui? c'est très dur de le dire maintenant, la seule chose qui soit sûre c'est que c'est ici une question de necessité pour le logiciel libre, l'archaïsme de Xfree ne pouvant crédibiliser celui-ci pour le desktop de manière généralisé. Il est cependant dommage qu'un projet à priori aussi innovant que Y annonce gérer OpenGL avec une widget du style "openglarea", c'est à dire comme Qt ou GTK et donc avec déjà 5 trains de retard sur Quartz....et bientôt sur le serveur graphique de longhorn(pour dircetx bien sûr).

  • # Re: Y : un remplaçant pour X ?

    Posté par  (site web personnel) . Évalué à 10.

    ça a l'air pas mal ! mais la route est encore longue.
    Vivement le successeur d'Y : Z
    Les softs clients de Z s'appelleront des wareZ, enfin légaux !

  • # Re: Y : un remplaçant pour X ?

    Posté par  (site web personnel) . Évalué à -1.

    A l'origine il y avait W
    maintenant c X
    Bientot on aura Y
    a quand Z?

  • # Re: Y : un remplaçant pour X ?

    Posté par  . Évalué à 9.

    Il y a des debs disponible, apres installation, ca se lance dans X et ca tourne sans aucun probleme :]

    c'est assez sympa, ya quelques apps, on voit la transparence, toussa, mais c'est pas tellement utilisable.

  • # Re: Y : un remplaçant pour X ?

    Posté par  (site web personnel) . Évalué à 2.

    permettant le "Y-forwarding" même sur internet.

    Le "X-forwarding" fonctionne même sur Internet. Bien sûr, avec un upload de 16 Ko/sec, c'est pas super réactif. À partir de 80 Ko/sec, ça devient bien.

  • # Re: Y : un remplaçant pour X ?

    Posté par  . Évalué à 2.

    C'est peut-être le moment de mettre en avant le projet 3dwm qui se veut un remplacement 3D de Xwindow.
    http://www.3dwm.org(...)
    (projet endormi ? :-/ )

  • # Re: Y : un remplaçant pour X ?

    Posté par  . Évalué à -5.

    sigh

  • # Petits soucis de compil...

    Posté par  . Évalué à 10.

    J'ai installé et testé la bêbête depuis les sources avec quelques petits soucis.... Si certains veulent essayer Y, voici les écueils que j'ai rencontré et comment les surmonter. Pour la suite des explications, noté que j'ai configuré la compil de libsigc++ et libiterm avec:

    ./configure --prefix=/usr/local

    Et la compil de Y avec:

    ./configure --prefix=/usr/local --with-libsig-prefix=/usr/local/bin/

    lors de compilation/édition des liens de Y, ld plante avec le message : /usr/bin/ld:./Versions:5: parse error in VERSION script .

    La réponse à ce problème (trouvé dans les archives de la ML de Y) est de passez à la version suivante de ld ( 2.14.90.0.8 20040114 ) et tout va effectivement mieux...

    Si vous lancer startY une fois le make install terminé vous aurez peut-être un problème avec des librairies non trouvées. Je ne vous ferais pas l'affront du LD_LIBRARY_PATH ou du ld.so.conf/ldconfig ... :-)

    De même Y cherche des fontes TrueType dans /usr/X11R6/lib/X11/fonts/truetype

    Sur ma RedHat 9, les fontes TrueType fournies avec X sont dans /usr/X11R6/lib/X11/fonts/TTF

    Editer le fichier /usr/local/etc/Y/default.conf
    Commenter les deux lignes FontDirectory
    Ajouter la ligne

    FontDirectory "/usr/X11R6/lib/X11/fonts/TTF" recursive

    Au passage Y log ses messages dans /var/log/messages

    Si ca peut aider quelqu'un...

    • [^] # Re: Petits soucis de compil...

      Posté par  . Évalué à 5.

      Sous Debian (une testing) il m'a suffit de télécharger les deb à cette adresse :

      http://www.darkobjects.net/~drizzt/y-base/debs(...)

      Et d'utiliser ensuite dpkg -i sans cet ordre :

      dpkg -i libiterm1_0.5-2mbt_i386.deb
      dpkg -i libiterm-dev_0.5-2mbt_i386.deb

      J'ai ensuite du installer libsigc++0c102, requis par y-devel : apt-get install libsigc++0c102

      dpkg -i y-devel_0.2-current_i386.deb

      Il me manquait aussi unifont pour fbiterm : apt-get install unifont

      dpkg -i fbiterm_0.5-2mbt_i386.deb
      dpkg -i xiterm_0.5-2mbt_i386.deb

      Vous trouverez Y dans /opt/Y-devel

      Il suffit de rajouter le chemin vers les binaires dans votre PATH (/usr/Y-devel/bin), puis de lancer startY. Attention j'ai eu quelques problèmes avec le keymap (plus de slash :/)

      Et là amusez vous à créer plein de fenêtres se superposant, c'est encore assez sommaire, mais ça donne envie de voir la suite! :)

  • # Re: Y : un remplaçant pour X ?

    Posté par  . Évalué à 5.

    Si ça a du succès, ils feraient mieux de changer le nom du site, parce que M$ va pas être content! A quand le site www.y-w-----s.org ?

  • # Interaction entre widget coté serveur et coté client?

    Posté par  . Évalué à 4.

    Je me demande comment marche l'interaction entre les widgets coté serveur et coté client?

    Je m'explique: seule les widgets "simples" peuvent être mis cotés serveur. Pour définir le formattage d'une page web, d'un document texte, c'est forcément le client qui va le faire, pas le serveur..

    Je crois que Berlin|Fresco essayait de faire executer du code du client sur le serveur pour faire ça, ce qui me parait compliqué|dangeureux, la seule alternative viable que je vois c'est une composition coté serveux de pixmap envoyé par le client..

    Soit dit en passant sur la FAQ, j'adore:
    Should it be referred to as "Y", "The Y Window System", or "Y Windows" ..?
    I don't care.

    Ca, c'est un réel progrés par rapport à X !!
    :-)

    Je suis curieux de voir la comparaison avec PicoGUI qui m'a l'air d'être aussi bien pensé..

    Bon aller, lecture de PDF.

    • [^] # Re: Interaction entre widget coté serveur et coté client?

      Posté par  . Évalué à 2.

      Quand on parle de serveur X...

      le serveur est souvent... sur le poste client !!!

      L'application tourne quelque part... (par exempe sur un serveur) et est le client pour le serveur d'afiichage (qui lui tourne sur le poste client)...

      Don, quand on dit que c'est le serveur qui s'occupe des widgets... je pense que c'est sur le poste client que le serveur s'en occupe !

      Me trompe-je ?

      • [^] # Re: Interaction entre widget coté serveur et coté client?

        Posté par  . Évalué à 1.

        Bon arrete d'embrouiller tout le monde :-)

        Serveur == serveur d'affichage: la machine qui affiche ce que tu as sous les yeux (enfin en général! Tu peux exporter sur un autre écran que le tiens, mais c'est rare).

        Client: la machine qui envoit les demandes d'affichage, donc soit ta machine, soit la machine sur laquelle tu es rlogué.

        Ca va mieux, là? ;-)

    • [^] # Re: Interaction entre widget coté serveur et coté client?

      Posté par  (site web personnel) . Évalué à 2.

      > Pour définir le formattage d'une page web, d'un document texte, c'est
      > forcément le client qui va le faire, pas le serveur..

      Oui, mais déjà, si le serveur gère les boutons, les barres de défilement, les menus, et deux-trois autres widgets de base, ça te permet d'afficher une fenêtre bien remplie en ne passant que quelques octets sur le réseau (Et ce, y compris si tu as un thème de fou avec du pixmap sur les boutons, des dégradés dans les menus, ...)

  • # Re: Y : un remplaçant pour X ?

    Posté par  . Évalué à 1.

    A noter le driver SDL, ce qui pourrait vouloir dire que Y pourrait tourner sur tous les systemes supportes par SDL :o)

  • # Re: Y : un remplaçant pour X ?

    Posté par  . Évalué à 3.

    Il me semblait bien avoir déjà vu cela... ;-)

    http://linuxfr.org/2003/09/28/14120.html(...)

    • [^] # Re: Y : un remplaçant pour X ?

      Posté par  . Évalué à 6.

      d'ailleurs c'est intéressant de voir les différences dans les commentaires entre les deux news. En septembre dernier, tous les commentaires sont la pour dire que la critique de X est injustifié, qu'il est très bien et tout et tout. Maintenant, on dit plutot que l'initiative est sympathique. Est-ce que l'idée aurait fait son chemin ?
      les problèmes de licence récents doivent aussi y être pour quelque chose

      • [^] # Re: Y : un remplaçant pour X ?

        Posté par  . Évalué à 3.

        Ah, je n'avais pas pris la peine de relire tous les commentaires...
        Peut-être tout simplement parce que le projet commence à devenir concret ?

  • # Re: Y : un remplaçant pour X ?

    Posté par  (site web personnel) . Évalué à 2.

    > A partir d'une étude approfondie des différents systèmes existants ou en projet (X, Aqua, Windows, Fresco, PicoGUI...)
    Comme toujours on oublie directfb
    A mon gout il est d'excellente qualite
    Il a des drivers pour de nombreuses cartes
    meme pour nvidia et radeon meme si ils sont tres limites
    on est pas obliger de passer par le frame buffer on peut faire sur sdl
    il existe Xdirectfb qui permet d'avoir une couche de compatibilite entre X et directfb
    clanlib, qt et gtk sont deja portes dessus
    (enfin qt n'a pas l'air terminer, a tester)

    • [^] # Re: Y : un remplaçant pour X ?

      Posté par  (site web personnel) . Évalué à 1.

      Peut etre que le probleme avec directfb c'est qu'il n'est pas pensé pour avoir un transparence réseau comme freso, X ou Y.
      Ca n'empeche pas que ca a l'air très joli sur les screenshots, mais ca enleve une fonctionalité par rapports a l'implémentation actuelle de X.

      Moi, personnelement je ne me sers quasiment jamais de la transparence réseau pour l'affichage, mais il y a bcp de personne que ca generai si ca disparraissait.

    • [^] # Re: Y : un remplaçant pour X ?

      Posté par  (site web personnel) . Évalué à 1.

      L'auteur en parle : page 19 du pdf, et y'en a même autant sur directFB que sur aqua ou Windows

  • # Question

    Posté par  . Évalué à 1.

    Est-ce que le concept de widget coté serveur permettrait à une application d'accéder aux widgets des autres applications ?

    Ca peut être intéressant pour développer des applications permettant d'en piloter d'autres, par exemple pour automatiser des taches graphiques.

    • [^] # Re: Question

      Posté par  (site web personnel) . Évalué à 1.

      d'une part je reponderais dcop
      de l'autre je reponderais 42

      • [^] # Re: Question

        Posté par  . Évalué à 1.

        aux tempes pour moi, je pensais que dcop était un truc de kde

      • [^] # Re: Question

        Posté par  . Évalué à 1.

        DCOP, ou le futur DBUS... si j'ai bien compris de quoi il retournait...

      • [^] # Re: Question

        Posté par  . Évalué à 1.

        et puis quand on est nul en orthographe on fait pas son malin :)

  • # Prononciation

    Posté par  . Évalué à 7.

    "Y-windows" se prononce (en anglais) comme "why windows ?"
    Doit-on y voir un signe ?

Suivre le flux des commentaires

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