XCB/XCL: mort à la xlib ?

Posté par  . Modéré par Nÿco.
Étiquettes : aucune
0
5
mai
2003
Serveurs d’affichage
Dans un message intitulé "death to xlib...? :)", Rasterman le gourou de Enlightenment a annoncé son intention d'utiliser la bibliothèque XCB en remplacement de la Xlib. XCB est une bibliothèque destinée à implémenter le protocole X et à remplacer Xlib. Une autre bibliothèque, appelée XCL, implante au-dessus l'API de la Xlib. XCB/XCL utilise le préprocesseur m4 et le langage C.

Parmi les avantages annoncés, outre un côté moins "usine à gaz" que la Xlib (j'ai mon doute là-dessus, s'ils réimplémentent toute l'API...), il y a surtout un côté non bloquant pour les appels à X : une requête renvoit un cookie, et quand les données sont nécessaires, présente le cookie pour les obtenir. C'est celà qui intéresse surtout Rasterman.

Il reste quand même un petit problème : XCB n'implémente pas encore l'extension shm (shared memory) du MIT, dont a besoin Enlightenment...

On se retrouve donc dans la situation suivante : un appel aux codeurs a été lancé pour "finir" xcb sur la liste e-devel, et le travail sur e17 va amha s'en ressentir.

Un post explicatif sur xcb/xcl a répondu à l'annonce de Rasterman, il est en anglais mais il est très clair.

Notons qu'on retrouve le nom de Keith Packard au coté de xcb/xcl, et on peut reparler du fork de Xfree...

Aller plus loin

  • # Re: XCB/XCL: mort à la xlib ?

    Posté par  . Évalué à 3.

    Je me demande vraiment si E17 sortira un jour...

    • [^] # Re: XCB/XCL: mort à la xlib ?

      Posté par  . Évalué à 8.

      Je trouve E16 parfait donc j'attends tranquillement.

      Les développeurs ne sont pas nombreux et l'équipe a vraiment l'ambition de
      produire quelque chose de parfait.

      Le fait que Raster remette (un peu) en cause le développement de E17
      en voulant utiliser XCB (il faudra ajouter des fonctionnalité a XCB pour que
      ca marche) en est la preuve.

      En ce moment, ils font un gros boulot sur les Libs autour de E17. Et ca avance
      pas mal. Il y a meme déja quelques appli a tester comme Enitce (magnifique viewer)
      ou Entrance (un magnifique gestionnaire de login).

      Il faudra etre patient, mais E17 sortira un jour et il il sera très bon.
      Et la meilleure facon de patienter, c'est d'tuiliser E16 : ) .

      • [^] # Re: XCB/XCL: mort à la xlib ?

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

        "Et la meilleure facon de patienter, c'est d'tuiliser E16 : )"

        Et de tester E16.6(pour l'instant le cvs) afin de permettre a E16 d'etre parfaitement intégré a gnome2(meme si le 2.3 semble poser des problemes...). Bon, histoire de pas me répéter a propos de E16.6: http://linuxfr.org/~gnumdk/2573.html(...)

        • [^] # Re: XCB/XCL: mort à la xlib ?

          Posté par  . Évalué à 4.

          Ca a été une bénédiction, la sortie de Gnome 2 : ) !

          Grace a son incompatibilité avec E16, je me suis rendu compte, qu'en fait,
          je n'ai pas besion du gnome-panel !

          J'ai un bureau totalement E et se suis très heureux comme ca !

          Le code de E16 a presque 4ans et je touve qu'on a rien fait de mieux après.

          Gloire a Raster !!

          • [^] # Re: XCB/XCL: mort à la xlib ?

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

            Moi, je suis hyper malheureux quant à la gestion du refocus de mozilla sous E. faut parfois faire 4 fois alt-tab pour que ça marche.
            GRAAAAAAAAAH
            D'ailleurs, le "mouse-over" obligé de wmcoincoin est parfois chiant, quand on préfère que la souris reste dans un coin quand on navigue entre fenetres

      • [^] # Re: XCB/XCL: mort à la xlib ?

        Posté par  . Évalué à 2.

        d'ailleur, puisqu'on en parle,
        evas, la bibliothèque 2D accélérée via OpenGL ou en rendu software optimisé mmx (si on le CPU qui va avec) et qui est multiplatforme,
        est passé en version 1.0.0-pre5, selon ce que j'ai cru comprendre,
        ça veut dir que l'API ne changera plus, c'est un pas en avant vers E17.
        c'est cette bibliothèque qui est utilisé dans entrance et entice pour l'affichage, elle sera utilisé dans E17 pour l'affichage du bureau, des bordures des fenêtres la toolbox et tout le reste.

        bref, vivement la sortie de E17

    • [^] # Re: XCB/XCL: mort à la xlib ?

      Posté par  . Évalué à 3.

      je ne sais pas non plus.
      C'est marrant que Rasterman ait repris le développement de Enlightenment, il avait confessé lors d'une interview à Linux and Main que Linux avait perdu la guerre du bureau :
      http://www.linuxandmain.com/modules.php?name=News&file=article&(...)

      Voici l'extrait :

      LaM: Where do you think the future lies for desktop Linux?

      R: Not on the desktop. Not on the PC. Not on anything that resembles
      what you call the desktop. Windows has won. Face it.


      En lisant un peu plus, il ne disait pas que Linux était une daube, mais que les gens se moquaient d'avoir un OS dont le kernel est stable...
      Devant tant de pessimisme, je m'étais dit qu'il avait vraiment arrêté tout développement de Enlightenment !!

    • [^] # Re: XCB/XCL: mort à la xlib ?

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

      il est prévu pour la prochaine Debian

      (bon, on a le droit de troller de temps en temps non ? :))

      • [^] # Re: XCB/XCL: mort à la xlib ?

        Posté par  . Évalué à 0.

        il est prévu pour la prochaine Debian

        non ca sera la version 0.18 pour la debian, la 0.17 etant deja declaree trop "advanced" (ala JC) pour la future debian :))))

        (bon, on a le droit de troller de temps en temps non ? :))

        Juste de temps en temps alors, histoire de pas avoir trop de XP :)

    • [^] # Re: XCB/XCL: mort à la xlib ?

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

      Je me demande vraiment si E17 sortira un jour...
      Ben quoi, Diablo 2 il est bien sorti aussi. Je n'y croyais plus...

      Ok, bon d'accord, je me fais tout petit...

  • # Re: XCB/XCL: mort à la xlib ?

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

    en fait le code pour l'extension shm est déjà dans le CVS.

  • # Re: XCB/XCL: mort à la xlib ?

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

    XCB/XCL utilise le préprocesseur m4 et le language C.

    que du bonheur

    • [^] # Re: XCB/XCL: mort à la xlib ?

      Posté par  . Évalué à 1.

      tu peux expliciter stp?

      • [^] # Re: XCB/XCL: mort à la xlib ?

        Posté par  . Évalué à 2.

        jeune inocent,
        tu as jamais vu du code m4 toi :))))

        • [^] # Re: XCB/XCL: mort à la xlib ?

          Posté par  . Évalué à 8.

          ah si, je me souviens! C'est pas automake/autoconf??
          c'est vrai qu'on fait difficilement plus incomprehensible!!

          (troll: à croire que c'est RH qui l'a mis au point pour faire de l' "obfuscation" dans les srpm!! )

          Nota: vous saviez que les premiers drivers officiels nVidia étaient distribués avec leurs sources, mais qu'elles été méchament modifiées pour les rendre inintellegibles? J'ai appris ça alors que je cherchais sur le net un projet de reverse engineering des drivers nVidia.

          • [^] # Re: XCB/XCL: mort à la xlib ?

            Posté par  . Évalué à 1.

            ah si, je me souviens! C'est pas automake/autoconf??
            c'est vrai qu'on fait difficilement plus incomprehensible!!

            exactement :)

            Nota: vous saviez que les premiers drivers officiels nVidia étaient distribués avec leurs sources, mais qu'elles été méchament modifiées pour les rendre inintellegibles? J'ai appris ça alors que je cherchais sur le net un projet de reverse engineering des drivers nVidia.

            Ahh, d'ou tiens tu ca: liens ? liens vers le source ?

        • [^] # Re: XCB/XCL: mort à la xlib ?

          Posté par  . Évalué à 1.

          je n'ai pas regardé le code mais je crois que justement il fait allusion au script automake/autoconf. Donc pas de m4 dans la lib :o)

    • [^] # Re: XCB/XCL: mort à la xlib ?

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

      ça reste mieux que CPP

      • [^] # Re: XCB/XCL: mort à la xlib ?

        Posté par  . Évalué à 0.

        hmm.... non. J'ai déjà tenté de comprendre pourquoi un "autoconf" dans libeva cvs de E17 fonctionnait pas. J'ai réussi au bout d'une demi-heure.
        Par contre j'ai toujours pas compris comment modifier le fichier .in ... J'ai lancé les lignes de compilation à la main.

        • [^] # Re: XCB/XCL: mort à la xlib ?

          Posté par  . Évalué à 1.

          On modifie pas les regles d'un fichier .in, vu qu'ils sont generes par automake
          a partir des Makefile.am

          quand au configure il cree, les Makefile a partir des Makefile.in en remplacant toutes les directives @...@ et peut-etre d'autres.

          • [^] # Re: XCB/XCL: mort à la xlib ?

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

            On modifie pas les regles d'un fichier .in, vu qu'ils sont generes par automake
            C'est vrai s'il s'agit d'un makefile.in, mais on peut (doit) modifier parfois les .in , ne serait-ce que pour modifier configure.in.

            Et puis on peut faire des choses sympatiques comme un fichier "monprog.spec.in", puis ajouter "monprog.spec" dans la liste des fichiers à générer par configure. Ca permet d'obtenir un specfile pour les rpm qui a un numero de version du package défini par configure, et donc ca m'évite de mettre à jour le no de version à la main (oui, je suis un fainéant).

      • [^] # Re: XCB/XCL: mort à la xlib ?

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

        En terme de puissance très certainement, maintenant en terme de bonheur et de lisibilité c'est plus contestable. m4 a beau être turing équivalent, on voit beaucoup plus de jeux d'échecs codés en sed qu'en m4, c'est dire si cet outil rebute les plus pervers.

  • # On écrit langage et non language

    Posté par  . Évalué à 3.

    Je ne sais pas pourquoi mais c'est une faute qui m'agace a un point ....

Suivre le flux des commentaires

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