La cohabitation se passe très bien. Les deux lib parlent le même protocole avec le serveur, mais celui ci n'est pas "raciste" il accepte de parler aux deux. Tu peux donc installer XCB en parralèle sans problèmes, et utiliser en même temps des applis Xlib classique, des applis XCB pure, et des applis Xlib/XCB.
Le lancement du serveur ne change absolument pas, XCB et Xlib sont utilisés uniquement par le client pour parler au serveur, le protocole étant le même dans tous les cas le serveur n'a même pas besoin d'être au courrant du changement.
Pour les applis, en fait elles sont toutes opérationelle avec la version Xlib qui utilise XCB comme couche de transport. Pas mal de personnes utilisent déjà un système qui ne possède que XCB et cette version de la Xlib sans problème. Par contre ses application ne profitent que peut des avantages de XCB. Mais on peux éspérer une migration progressive de ces applications puisque il est possible de mélanger les appels Xlib et XCB au seins d'une même application.
Il n'est pas nécéssaire de recompiler les applis si tu passe par la Xlib/XCB, par contre si tu veux passer à du XCB pure il est nécéssaire de modifier le code, parfois assez profondément pour pouvoir profiter notament de l'aspect asynchrone. Il y a aussi des différence assées importantes notament au niveau de la gestions des évenements.
Pour ce qui est du choix entre les deux API, actuellement XCB se présente quand même comme l'avenir. Il est quasiment certains que cette API va s'imposer, mais la Xlib restera toujour présente à des fin de compatibilitée. Une fois la version 1.0 finale sortie, on verra probablement la Xlib standard remplacée par le couple XCB/Xlib.
Le choix est donc entre les mains des développeurs, mais à mon avis, un developpeur qui bosse à ce niveau devrait serieusement envisager d'utiliser XCB. Ce qu'il faut bien voir, comme rappelé dans un commentaire plus bas, c'est que dans la majoritée des cas, les developpeurs bossent à un niveau plus élevé et utilisent des toolkit tel que GTK, il ne voient donc jamais les appels à la Xlib. La programation au niveau du protocole X est généralement limitée aux toolkit, au window manager, ou à des petites applications telle que les dockapps de window maker.
Le principal objectif est donc de convertir ces systèmes d'abstraction pour que un maximum d'application bénéficies de XCB. Un gros boulot à déjà été fait pour evas, il me semble qu'il y a aussi eu du travail de fait pour cairo (mais je n'est pas trop suivi ça), une vieille version de GTK avait aussi étée portée mais le travail n'a pas été poursuivit. Bref, c'est possible, maintenant il va falloir du temps pour que ça ce fasse, mais il semble à peu près inévitable que l'on y viennent à l'avenir.
[^] # Re: Pourquoi ?
Posté par beagf . En réponse au journal XCB en version 1.0-RC1, le futur en marche.... Évalué à 4.
Le lancement du serveur ne change absolument pas, XCB et Xlib sont utilisés uniquement par le client pour parler au serveur, le protocole étant le même dans tous les cas le serveur n'a même pas besoin d'être au courrant du changement.
Pour les applis, en fait elles sont toutes opérationelle avec la version Xlib qui utilise XCB comme couche de transport. Pas mal de personnes utilisent déjà un système qui ne possède que XCB et cette version de la Xlib sans problème. Par contre ses application ne profitent que peut des avantages de XCB. Mais on peux éspérer une migration progressive de ces applications puisque il est possible de mélanger les appels Xlib et XCB au seins d'une même application.
Il n'est pas nécéssaire de recompiler les applis si tu passe par la Xlib/XCB, par contre si tu veux passer à du XCB pure il est nécéssaire de modifier le code, parfois assez profondément pour pouvoir profiter notament de l'aspect asynchrone. Il y a aussi des différence assées importantes notament au niveau de la gestions des évenements.
Pour ce qui est du choix entre les deux API, actuellement XCB se présente quand même comme l'avenir. Il est quasiment certains que cette API va s'imposer, mais la Xlib restera toujour présente à des fin de compatibilitée. Une fois la version 1.0 finale sortie, on verra probablement la Xlib standard remplacée par le couple XCB/Xlib.
Le choix est donc entre les mains des développeurs, mais à mon avis, un developpeur qui bosse à ce niveau devrait serieusement envisager d'utiliser XCB. Ce qu'il faut bien voir, comme rappelé dans un commentaire plus bas, c'est que dans la majoritée des cas, les developpeurs bossent à un niveau plus élevé et utilisent des toolkit tel que GTK, il ne voient donc jamais les appels à la Xlib. La programation au niveau du protocole X est généralement limitée aux toolkit, au window manager, ou à des petites applications telle que les dockapps de window maker.
Le principal objectif est donc de convertir ces systèmes d'abstraction pour que un maximum d'application bénéficies de XCB. Un gros boulot à déjà été fait pour evas, il me semble qu'il y a aussi eu du travail de fait pour cairo (mais je n'est pas trop suivi ça), une vieille version de GTK avait aussi étée portée mais le travail n'a pas été poursuivit. Bref, c'est possible, maintenant il va falloir du temps pour que ça ce fasse, mais il semble à peu près inévitable que l'on y viennent à l'avenir.