Ca m'etonne qu'en lisant tout ca, tu n'aies pas compris.
La texte que tu cites montre bien que X a une nautre asynchrone, mais que xlib a bufferiser les requetes pour en faire un truc synchrone. Resultat, il y a des appels de fonction bloquant qui empeche une application de gerer au mieux son rafraichissement. J'avais d'ailleurs discute avec Mathias Ettrich (fondateur de KDE, poste eleve chez Trolltech) qui expliquait qu'ils avaient passe pas mal de temps a traquer les appels les plus bloquants pour les remplacer par des appels moins bloquants.
xlib agit comme une librairie qui parle le protocole X au serveur X. C'est donc une implmentation cote client du code necessaire pour gerer la communication avec le serveur.
XCB est une autre implementation du protocole X. Elle parle le meme protocole donc peut discuter avec les memes serveurs. Cependant, son API n'est pas la meme. Tu feras sans doute un XCLOpenDisplay() puis un XCLWaitNextEvent(), etc. Les fonctionsn'ont peut etre pas le meme nom et ne fonctionnent pas de la meme maniere, bien qu'elles servent a la meme chose, parler le protocole X.
La tu es triste et tu te dis que c'est dommage de devoir re-ecrire toutes les applications X-Window de la terre pour profiter de XCB.
Mais les gentils concepteurs de XCB ont pense a toi: il y a XCL qui est le Xlib Compabilitiy Layer. C'est une lib qui contient exactement les memes fonctions que xlib, mais implementees en passant par XCB. En gros, tu as les memes .h mais les .c sont differents.
C'est plus clair ?
> Donc ma question, en quoi XCB va changer cela ?
Les memes messages de protocoles seront envoyes au serveur, mais en utilisant une autre lib.
> Je vais devoir laisser tomber ces appels Xlib pour autre chose ?
Ca depend. Si tu utilise XCL, non. Si tu utilises uniquement XCB, oui, tu dois re-ecrire la partie graphique. Mais qui ecrit encore des applis en X aujourd'hui ? Les developpeurs de Qt, Gtk, Mozilla, GnuStep, Fox, etc vont se palucher la partie difficile du travail et le codeur d'appli moyen ne verra pas la difference.
> Il ne faudra plus utiliser Xlib ?
Non, plus de xlib. C'est le but.
> XCB va dialoguer directement au serveur X sur la même machine sans passer par une couche réseau ?
Il va bien dialoguer avec le meme serveur, en passant par la couche reseau, en utilisant le protocole X.
> Comment rendre asynchrone un appel qui nécessite un résultat pour poursuivre le traitement sans ralentir le tout
> et sans rajouter une complexité de traitement supplémentaire ?
Le texte que tu cites donnes des elements de reponse. Le probleme de xlib, c'est pas tant que les appels soient synchrones, c'est qu'ils sont bufferises.
Sinon, ca va se traduire en effet dans une approche un peu differente de la gestion des appels a la lib X. En effet, ca ristque d'etre costaud, mais optimiser l'utilisation de X par une appli, c'est par pour les petits joueurs. Il faut savoir quels appels sont couteux en temps, lesquels on peut economiser, quand faire quoi, reflechir si l'inversion de deux operations ne me permet pas de debloquer une operation suivante plus rapidement, etc. etc. C'est les experts de Qt, Gtk et tout ca qui vont faire le travail difficile et ca ne changera rien pour le developpeur KDE moyen, sauf que ce sera plus rapide a l'affichage.
Note que de toute facon, la situation est encore pire pour l'instant. Pour optimiser des applis, les developpeurs de Qt sont obliges de comprendre exactement quels appels de xlib sont bufferises et de les eviter pour passer des appels plus rapides. A mon avis, XCB va leur simplifier grandement la vie.
Serveur d'affichage X <----[protocole X]---- xlib <--- client d'affichage X (Qt, Gtk, ...) <--- Application classique
Donc la xlib serait une implementation cote client du protocole X. Le travail du cote de X.org portait surtout l'amelioration du serveur X. Xcb arrive en parfait complement.
J'ai l'impression qu'il y a un malentendu. De ce que j'ai compris, avec les problemes de latence la xlib ne font pas qu'une application bloque toutes les autres.
Le principe, c'est qu'un appel xlib est bloquant. Donc pendant ce temps la, l'appli client appelante est bloquee. Pas de rafraichissement, du temps qu'elle pourrait utiliser a autre chose, etc. Avec XCB, cette meme appli n'est plus bloquee puisque les appels sont asynchrones. Elle peut faire autre chose en attendant le resultat.
Je suis pas expert X donc dites-moi si j'ai rien compris. Si on suit mon raisonnement, utiliser le pont xlib ne devrait pas apporter tant que ca puisque pour des raisons de compabilites, les appels doivent etre bloquants aussi ? Bon, j'ai l'impression que je m'embrouille.
D'apres ce que j'ai compris, leur objectif est plus en terme d'architecture. En revanche, ils sont convaincus, eux et tous les gourou de X, que ca va aller beaucoup plus vite puisqu'ils enlevent un certain nombre de blocages.
Sinon, c'est vraiment une super nouvelle. Les gens vont pouvoir arreter de dire "remplacer X par le framebuffer parce que c'est trop lent" et passer en mode "remplacons Xlib par XCB" et tout sera plus beau sur nos ecrans.
Ce n'est que le debut. Vim est un vieil editeur qui a eu le temps de se bonifier au moins sur les aspects robustesse. Yzis y arrivera aussi, je n'ai aucun doute.
L'interet de yzis, ce n'est pas de l'utiliser exactement comme vim. C'est vraiment les nouvelles possiblites que le projet offre:
- un backend vi generique re-utilisable dans d'autres projets
- une integration facile dans des bureaux graphiques
- un langage de script plus evolue
En tout cas, on note et on essaiera de faire mieux la prochaine fois.
- avoir des options visuelles plus avancees : le split vertical de vim est vraiment moche, en version graphique, on utilise un splitter Qt ou Gtk qui est plus propre
- avoir acces a une palette plus large de couleur : le terminaux sont limites en nombre de couleur
<< equilibre optimal entre droits d'auteurs et d'utilisateurs >>
Je ne suis pas d'accord. La GPL donne bien plus de droit a l'utilisateur qu'a l'auteur. Par exemple, malgre le discours de RMS sur le fait qu'on peut vendre du GPL, la licence est tres mal adapte a ce genre d'utilisation. Mais dans l'esprit, c'est peut-etre tout le logiciel libre qui est tres mal adapte a un modele economique (qui pourrait vendre KDE ? ou Gnome Meeting ?)
Pas vraiment bien sur. Qui peut prouver quoi que ce soit ?
Cependant, si tu regardes le nombre de developeurs KDE, on doit etre autour de 70 a 80% qui sont allemands. On a aussi pas mal de neerlandais, quelques francais, anglais, espagnols, etc. En gros, les developeurs americains sont peut-etre une dizaine.
A cote, si on compte le nombre de developeurs allemands de Gnome, on tombe a mon avis dans un rapport 95% / 5% avec KDE.
J'ai pas eu l'impression que Fedora soit tres populaire en Allemagne.
On trolle quand Fedora cache un peu KDE, mais dans certaines versions de Suse, Gnome etait limite en dehors du paysage et j'ai pas vu grand monde s'en plaindre.
Le but n'est pas de faire une gueguerre US/EU, c'est avant tout une constatation. Je crois a l'equation "Suse a 95% du marche allemand" et "100% des utilisateurs de Suse utilisent KDE en allemagne".
Un autre signe de la popularite de KDE en Allemagne, c'est qu'il y a des petites boites de services qui tournent autour de KDE / Suse (par exemple, ceux qui font Kontact / Kollab). Et puis KDE est un projet demarre par un allemand, largement popularise en Allemagne par un magazine allemand.
Je soupconne aussi que le projet dans sa facon de fonctionner et de se developper garde des marques de sa culture allemande (un peu plus carre).
De l'autre cote, Gnome est largement popularise au Etats-Unis, par Miguel, Havoc, etc
Surtout, il ne faudrait pas y voir une critique de quoi que ce soit, juste un constat.
Pour en revenir au sujet, KDE est tellement implante en Allemagne que Novell/Suse ne pourra pas le remplacer. Il y aussi de tres fervents supporters de KDE haut places chez Suse (plus haut que la ou est Miguel dans la pratique) qui vont defendre la place de KDE.
C'est pour ca que je maintiens ma position que pour l'instant, la strategie desktop de Novell ne passe pas par l'eradication de KDE ou Gnome mais qu'ils ne savent pas tres bien ou ils en sont. Une des caracterisitques de cette situation, c'est que suivant les personnes qui parlent, on a pas le meme son de cloche.
Ca, ca m'etonnerait. La position entre Redhat et Sun n'est pas tres clair, a moitie concurrent, a moitie avec des interets communs. Sun fait plus ou moins une distrib linux en hesitant a faire le pas a fond.
Toujours est-il qu'avec des relations aussi floues, je doute que Sun file un centime a Red hat. Donc non, Red hat paye les developpeurs Red hat/Gnome de sa poche.
Tu avances un non-sens: tu dis que KDE perds un de ses plus gros contributeurs mais en meme temps, il est dit dans l'article que Suse va continuer comme elle est, c'est a dire avec KDE. De toute facon, il ne faut pas se leurrer. Autant Gnome marche tres bien aux US, au temps en Allemagne, c'est 95% de KDE et on ne pourra pas migrer de force les clients de Suse a Gnome.
Ce que je comprends de l'article, c'est que les fonctionnalites Novell rentreront dans la partie Gnome. Et encore, quand on regarde de plus pres:
<<
For example, a calendar item entered in Evolution will appear in the GNOME calendar, and an instant-messenger nickname entered in Evolution will appear in the GAIM instant-messenger client. GNOME components Evolution and GAIM will dovetail with GroupWise server software, while the KDE equivalents--KMail and Kopete--will not.
>>
Ainsi, Evolution s'integre au calendrier Gnome, et les contacts seront partages entre Evolution et Gaim. Impressionnant ! En effet, c'est un truc qui Novell ne pourra pas contribuer a KDE vu que si je ne m'abuse, les contacts sont deja partages entre Kopete et Kontact.
Troll mis a part, tout ce qu'on peut retirer de l'article, c'est que la situation est loin d'etre claire a l'interieur de Novell. A mon avis, les entites americaines et europeennes n'ont pas la meme vision et la meme strategie ce qui donne un tableau plutot complique.
> ce que de petits malin ont affirmé en faisant une implentation bidon de Python
Tu parles peut-etre de l'implementation realisee par Mark Hammond un des gourou de la communaute python, implementation financee par Microsoft ?
Dans ce cas, je remballerai l'experssion "petits malins". Mark Hammond est extremement respecte dans la communaute python et il y a des raisons pour lesquelles son implementaiton n 'etait pas optimale, que Guido van Rossum detaille dans mon interview (http://www.freehackers.org/fosdem2002/guido.html(...)):
<<
Anyway, they did a Python port to .NET very early on, with some funding from Microsoft. I think the issue was mostly for Microsoft to show that Common Language Runtime really was a suitable target for multiple languages because they did the same thing with lot of language groups. [...] It's true that the Python .NET interpreter is very slow. I think part of that is just that they didn't have enough time to make it faster, there is always optimisations. The other thing was beacuase they did it so early on that they had to sign very strict Non Disclosure Agreements and Mark Hammond couldn't ask anyone for help because he was on NDA. He couldn't tell anybody even that he was working on this project until it was finished. So if he didn't know the compiler techniques, he was basically on his own. And there was also not much documentation about .NET available at that point, because .NET was basically still a Microsoft internal project. So I think now, this is based on a few things that Miguel told me actually. There are number of approaches to make it much faster.
>>
> Les quelques constructeurs qui veulent sortir des drivers pour Linux n'ont pas de difficultée à le faire.
Non. Les quelques constructeurs hyper motives qui veulent sortir des drivers pour Linux y arrivent tant bien que mal apres beaucoup d'efforts.
Imagine une boite qui fait un peripherique a la con. 95% de son marche est sous windows, 5% sous Linux (je suis tres optimiste, normalement, c'est 99.99999% ). Elle passe 2 ans a developper son driver avec son equipe de 2 personnes et il marche sous tous les windows. Elle est contente.
Mainenant, cette boite n'a aucun a priori sur Linux. Elle se dit que ca pourrait etre sympa de recuperer les 5% restant. De toute facon, sa version windows ne lui coute en maintenance que quelques jours-hommes par an donc elle a un tout petit peu de temps libre.
Voila qu'elle decouvre que si elle veut faire des drivers pour Linux, il faut qu'elle les fasse pour une version de Linux donnee. Ensuite, il faut qq'un qui suive en permanence l'evolution du kernel pour garantir que le driver n'est pas pete a chaque seconde qui passe. Sa maintenance va se chiffrer en mois-hommes parce que tout Linus a decide que l'api utilisee par le driver etait de toute facon pourrie et obsolete et va donc re-ecrire un truc completement incompable.
On imagine que la boite suit cette premiere transition. Apres, bien que le truc ait ete re-ecrit, il y encore des modifs a apporter a l'API du machin qui sont faites tranquillement, sans communiquer plus que un message sur la lkml, et qui petent le driver de nouveau.
Pour resumer, en terme de cout, un driver sous Linux, c'est quelque mois-hommes par an alors que le marche lui-meme est beaucoup plus faible que sous windows.
Le choix est vite fait pour n'importe quelle entreprise, il n'y aura pas de driver pour Linux. Mais ca Linus s'en fout apparemment.
> Rien ne garantit en effet qu'elle n'est pas contournée et qu'il n'y a
> pas dans le code du driver des hacks qui créeront des
> incompatibilitées avec des versions futures à cause de changement
> internes au noyau
Oui, mais dans ce cas, tu peux faire un report de bug clair incriminant le driver. Maintenant, la situation, ce sera "ca marche pas" sans que tu saches si un truc subtil a change dans le noyau, dans le driver, si le driver est code comme un pied ou si tu as un probleme sur ta machine.
Personellement, je considere ce modele de developpement comme une regression. Certe Linus aura moins de difficulte. Par contre, ca va etre la merde pour tout le monde en dehors de ceux qui suivent la lkml.
Les noyaux vont etre beaucoup moins testes par les utilisateurs puisqu'une mise a jour deviendra une operation tres dangereuse si on n'est pas sur de maitriser.
De tres gros projets arrivent tres bien a gerer l'evolution d'une base de code stable avec une evolution rapide (Mozilla, KDE, Gnome, Qt, Gtk) tout en conservant la compabilite binaire. Je ne vois pas pourquoi le noyau n'y arriverait pas. En fait, si , je vois tres bien. C'est parce que ca ne plait pas a Linus. C'est pas assez fun, c'est bien plus fun de tout peter a tout moment parce que ca nous plait que de conserver des API mouvante parce que soi-disant, ca va ameliorer la qualite des drivers.
Plus ca va, plus Linus fout la merde dans Linux. Mais c'est son bebe, on n'a rien a dire.
La phase "mais non, c'est pas dur de recompiler son noyau" ne pourra plus etre valable du tout.
Ca m'enerve vraiment. Quand je vois tous les efforts deployes par Trolltech, KDE ou Gnome pour qu'une mise a jour incompatible des lib se passe le plus tranquillement possible du monde, j'admire. Ils ne font ca que tous les 2 a 4 ans, ils preparent de bibliotheques de compabilite, ils preparent les developpeurs pendant plusieurs mois en faisant des snapshots, ils communiques, ils reflechissent longtemp a l'avance a ce qu'ils vont changer.
Linus, lui s'en bat tout simplement les couilles et je trouve ca dommage. Il a toujours eu cette attitude mais la ca devient vraiment genant. Le 2.6 ne pourra plus etre considere comme un noyau de reference.
Qu'est ce qui te permet de faire cette prediction optimiste ?
Le probleme souleve est au coeur du fonctionnement de XUL. A premiere vue, le spoofer fait exactement ce pour quoi XUL a ete prevu. Donc la facon la plus simple de remedier au probleme, c'est de supprimer l'execution XUL. Ah ouai, mais ca risque de serieuseement diminuer les possiblites du browser.
Bref, avant de predire, j'attends de vois ce que va proposer la communaute mozilla.
Tout a fait. emerge, c'est d'un ennuyeux comme nom. Alors que jeter un sort, ca jette plus niveau vocabulaire. Et dans l'imaginaire, c'est un peu ca, quand on lance un emerge/apt-get, il y a un peu de magie qui s'execute pour nous rapporter tout ce qu'on vuet.
J'ai pas dit qu'il avait ete seul. Mais tout ce qui est modele de composant et virtual file system sont des choses dont MDI parlait deja au temps de Gnome 0.x, avant meme qu'elles ne soient realisees concretement. Je ne serai pas surpris qu'il aie eu aussi la vision d'un moteur dynamique de coeur de Gnome, comme celui qui va etre utilise pour generer les differents bindings de Gnome. Il avait plein de bonnes idees MDI, dont un certain nombre ont abouti a qqch de pas trop mal.
Non, j'avoue avoir beaucoup de mal a te suivre dans tes raisonnements. Si plutot que de faire du delire, tu t'exprimais en phrases claires argumentees en parlant de faits reels ou au moins en proposant des explications qui se tiennent logiquement et socialement, ca serait plus facile de discuter avec toi.
> > C'est juste que dire que Ximian est completement independant de
> > Gnome et vice versa, ce n'est pas tout a fait vrai.
>
> Et tu veux en venir où ?
Je veux en venir au fait que quand tu dis que MDI est completement independant de Gnome, ce n'est pas vrai. MDI a encore via Ximian et via d'autre manieres une certaine influence sur le projet Gnome, bien qu'il n'en soit plus le leader ni meme un contributeur.
Et le fait que MDI bosse sur Mono encourage la communaute Gnome a reflechir autour de Mono. Ce n'est pas negatif mais c'est indeniable.
Et pour revenir a mon argumentation originelle (car perso, je tiens ma ligne de raisonnement), les differentes declarations de MDI ont enerve ou decu au cours du temps un certains nombre de membres de la communaute Gnome (car tout le monde dans Gnome ne voue pas une admiration sans borne a MDI et ses methodes). La direction actuelle de Gnome a largement ete insuflee par MDI et elle est differente de ce dont il faisait la promotion au moment de Gnome 1.0 et meme avant.
Donc il y a un certain nombre de mecontents chez Gnome qui se retrouveront probablement dans ce fork. Non, a peu d'exceptions pres, ils n'iront pas vers KDE car ils aiment bien le framework Gnome et ce qu'ils en ont fait. En revanche, ils ne sont pas necessairement en accord avec la direction pro-entreprise, pro-simplification qui (mais je me repete) etait loin de faire partie de Gnome dans sa version initiale. A l'epoque, c'etait meme Gnome le bureau de hacker hyper configurable et KDE le bureau pour les neuneu venant du monde windows.
En fait, il y a en effet deux categories d'utilisateurs. Ceux qui ne customisent rien, et ceux qui veulent un bureau exactement selon leurs specs.
Pour les seconds, Gnome a choisi de cacher pour pas que les premiers tombent dessus. KDE a fait le choix de les considerer comme des utilisateurs legitimes et de leur donner aussi une belle interface graphique.
> Ça fait depuis 3 ans que MDI ne fait rien pour Gnome !
> C'est claire.
Ca ce n'est pas vrai. Il n'a pas ecrit de code pour Gnome mais il contribue au projet autrement. Il pousse le desktop dans les entreprises, il developpe evolution pour que Gnome puisse etre accepte en entreprise.
Il continue aussi a avoir son role de visionnaire. Quand il voit une bonne techno et qu'il pond un article en disant a quelle point elle est interessante, tous les hackers de Gnome regardent ce qu'il dit. Et ca n'a rien de negatif. MDI est un hacker de Gnome respecte pour sa contribution par les autres hackers de Gnome, donc quand il dit qqch, les autres l'ecoute.
Bref, nier qu'il y a encore des liens entre MDI et Gnome me parait un peu extreme comme attitude. Cependant, c'est sur qu'il n'est pas a la direction de Gnome et qu'il repete toutes les jours que Gnome ne sera pas developpe en mono. A ton avis, pourquoi il a besoin de le repeter autant ? Serait-ce parce que en raison de son role historique dans Gnome, des gens s'imaginent le contraire ?
Comme tu peux faire ces deux choses sans passer par le centre de controle, l'ergonomie de celui-ci est un tout petit peu moins importante.
Perso, dans le centre de controle KDE, comme il est complique, j'utilise tout le temps la fonction recherche. Je trouve tout ce que je veux du premier coup.
Je ne sais pas pourquoi tu sors ton delire sur Red hat.
Ce que te dis le monsieur, c'est que pendant quelques temps, la page de download officielle de Gnome etait chez Ximian. Ce probleme a ete corrige rapidement (en quelques jours si je me souviens bien), justement pour montrer que Gnome est bien independant dans la mesure du possible de Ximian et eviter les polemiques "Ximian controle gnome etc"
Exhiber la page de download actuelle et sortir ton delire sur Redhat ne change rien au fait que ce dont on parle est arrive.
Pour eviter toute surinterpretation, ce n'est pas mal que Ximian aie des liens forts avec Gnome. Ils contribuent avec evolution et les developpeurs de Ximian sont de tres gros contributeurs de Gnome et sont tres respectes.
C'est juste que dire que Ximian est completement independant de Gnome et vice versa, ce n'est pas tout a fait vrai.
Ca c'est la theorie. La pratique est beaucoup moins claire. Par exemple, on m'a cite le cas d'application d'une technique a un autre domaine que son domaine d'origine. Il y aurait innovation parce que c'est nouveau dans ce domaine bien qu'en soi, il n'ya rien de neuf, juste du recyclage.
Exemple auquel j'ai ete confronte : transposition dans le monde de le carte a puce d'une technique logicielle a la con utilise couramment dans les appli non embarquee.
>> Mais je pense que les dev. bonobo sont un peu responsables
Et non, ce ne sont pas eux les responsables. Au contraire, ils ont fait un travail formidable dont l'ampleur est probablement mal appreciee.
Les responsables, ce sont qui ont affirme haut et fort que Corba etait parfaitement adapte comme modele de composant pour un desktop et ont continue sur ce choix technique. Ils ont fait fi de l'experience de KDE qui a renonce a CORBA a bout de deux ans de galere et ecrit un remplacant en moins d'un mois.
Corba est une tres bonne techno, mais c'est trop lourd par rapport aux besoins d'une techno de composant desktop. Donc il y a eu un travail enorme qui a ete fait pour rendre CORBA accessible relativement simplement en C. Du coup les developpeurs sont tellement pris dans Corba que documenter l'interface bonobo relativement triviale, ca leur parait superflu (ce dernier point est ma petite interpretation).
A cote, KDE est parti d'une techno existante et l'a a peine modifie pour en faire une techno de communication qui convenait parfaitement.
Et ce choix technique de CORBA, MDI en est en partie responsable. Comme il est responsable de pas mal d'autres choses chez Gnome, en bien comme en mal.
[^] # Re: Je n'ai pas bien compris
Posté par Philippe F (site web personnel) . En réponse à la dépêche XCB : bientôt la version 1. Évalué à 10.
La texte que tu cites montre bien que X a une nautre asynchrone, mais que xlib a bufferiser les requetes pour en faire un truc synchrone. Resultat, il y a des appels de fonction bloquant qui empeche une application de gerer au mieux son rafraichissement. J'avais d'ailleurs discute avec Mathias Ettrich (fondateur de KDE, poste eleve chez Trolltech) qui expliquait qu'ils avaient passe pas mal de temps a traquer les appels les plus bloquants pour les remplacer par des appels moins bloquants.
xlib agit comme une librairie qui parle le protocole X au serveur X. C'est donc une implmentation cote client du code necessaire pour gerer la communication avec le serveur.
XCB est une autre implementation du protocole X. Elle parle le meme protocole donc peut discuter avec les memes serveurs. Cependant, son API n'est pas la meme. Tu feras sans doute un XCLOpenDisplay() puis un XCLWaitNextEvent(), etc. Les fonctionsn'ont peut etre pas le meme nom et ne fonctionnent pas de la meme maniere, bien qu'elles servent a la meme chose, parler le protocole X.
La tu es triste et tu te dis que c'est dommage de devoir re-ecrire toutes les applications X-Window de la terre pour profiter de XCB.
Mais les gentils concepteurs de XCB ont pense a toi: il y a XCL qui est le Xlib Compabilitiy Layer. C'est une lib qui contient exactement les memes fonctions que xlib, mais implementees en passant par XCB. En gros, tu as les memes .h mais les .c sont differents.
C'est plus clair ?
> Donc ma question, en quoi XCB va changer cela ?
Les memes messages de protocoles seront envoyes au serveur, mais en utilisant une autre lib.
> Je vais devoir laisser tomber ces appels Xlib pour autre chose ?
Ca depend. Si tu utilise XCL, non. Si tu utilises uniquement XCB, oui, tu dois re-ecrire la partie graphique. Mais qui ecrit encore des applis en X aujourd'hui ? Les developpeurs de Qt, Gtk, Mozilla, GnuStep, Fox, etc vont se palucher la partie difficile du travail et le codeur d'appli moyen ne verra pas la difference.
> Il ne faudra plus utiliser Xlib ?
Non, plus de xlib. C'est le but.
> XCB va dialoguer directement au serveur X sur la même machine sans passer par une couche réseau ?
Il va bien dialoguer avec le meme serveur, en passant par la couche reseau, en utilisant le protocole X.
> Comment rendre asynchrone un appel qui nécessite un résultat pour poursuivre le traitement sans ralentir le tout
> et sans rajouter une complexité de traitement supplémentaire ?
Le texte que tu cites donnes des elements de reponse. Le probleme de xlib, c'est pas tant que les appels soient synchrones, c'est qu'ils sont bufferises.
Sinon, ca va se traduire en effet dans une approche un peu differente de la gestion des appels a la lib X. En effet, ca ristque d'etre costaud, mais optimiser l'utilisation de X par une appli, c'est par pour les petits joueurs. Il faut savoir quels appels sont couteux en temps, lesquels on peut economiser, quand faire quoi, reflechir si l'inversion de deux operations ne me permet pas de debloquer une operation suivante plus rapidement, etc. etc. C'est les experts de Qt, Gtk et tout ca qui vont faire le travail difficile et ca ne changera rien pour le developpeur KDE moyen, sauf que ce sera plus rapide a l'affichage.
Note que de toute facon, la situation est encore pire pour l'instant. Pour optimiser des applis, les developpeurs de Qt sont obliges de comprendre exactement quels appels de xlib sont bufferises et de les eviter pour passer des appels plus rapides. A mon avis, XCB va leur simplifier grandement la vie.
[^] # Re: question
Posté par Philippe F (site web personnel) . En réponse à la dépêche XCB : bientôt la version 1. Évalué à 4.
mv xlib.so /dev/null
ln -s xclib.so xlib.so
[^] # Re: Pont
Posté par Philippe F (site web personnel) . En réponse à la dépêche XCB : bientôt la version 1. Évalué à 3.
Serveur d'affichage X <----[protocole X]---- xlib <--- client d'affichage X (Qt, Gtk, ...) <--- Application classique
Donc la xlib serait une implementation cote client du protocole X. Le travail du cote de X.org portait surtout l'amelioration du serveur X. Xcb arrive en parfait complement.
[^] # Re: Pont
Posté par Philippe F (site web personnel) . En réponse à la dépêche XCB : bientôt la version 1. Évalué à 8.
Le principe, c'est qu'un appel xlib est bloquant. Donc pendant ce temps la, l'appli client appelante est bloquee. Pas de rafraichissement, du temps qu'elle pourrait utiliser a autre chose, etc. Avec XCB, cette meme appli n'est plus bloquee puisque les appels sont asynchrones. Elle peut faire autre chose en attendant le resultat.
Je suis pas expert X donc dites-moi si j'ai rien compris. Si on suit mon raisonnement, utiliser le pont xlib ne devrait pas apporter tant que ca puisque pour des raisons de compabilites, les appels doivent etre bloquants aussi ? Bon, j'ai l'impression que je m'embrouille.
[^] # Re: Performances ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche XCB : bientôt la version 1. Évalué à 10.
Sinon, c'est vraiment une super nouvelle. Les gens vont pouvoir arreter de dire "remplacer X par le framebuffer parce que c'est trop lent" et passer en mode "remplacons Xlib par XCB" et tout sera plus beau sur nos ecrans.
[^] # Re: Hum, hum
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis sort sa deuxième version. Évalué à 5.
L'interet de yzis, ce n'est pas de l'utiliser exactement comme vim. C'est vraiment les nouvelles possiblites que le projet offre:
- un backend vi generique re-utilisable dans d'autres projets
- une integration facile dans des bureaux graphiques
- un langage de script plus evolue
En tout cas, on note et on essaiera de faire mieux la prochaine fois.
[^] # Re: Y a plus qu'à...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis sort sa deuxième version. Évalué à 4.
- avoir acces a une palette plus large de couleur : le terminaux sont limites en nombre de couleur
- avoir des menus et des barres d'outils
- fournir une integration dans KDevelop et Quanta
Je suis sur qu'on peut en trouver d'autres.
[^] # Re: Tout est relatif
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trop de licences libres ?. Évalué à 3.
Je ne suis pas d'accord. La GPL donne bien plus de droit a l'utilisateur qu'a l'auteur. Par exemple, malgre le discours de RMS sur le fait qu'on peut vendre du GPL, la licence est tres mal adapte a ce genre d'utilisation. Mais dans l'esprit, c'est peut-etre tout le logiciel libre qui est tres mal adapte a un modele economique (qui pourrait vendre KDE ? ou Gnome Meeting ?)
[^] # Re: Trop fade comme news
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un aperçu de GNOME 2.8. Évalué à 1.
Pas vraiment bien sur. Qui peut prouver quoi que ce soit ?
Cependant, si tu regardes le nombre de developeurs KDE, on doit etre autour de 70 a 80% qui sont allemands. On a aussi pas mal de neerlandais, quelques francais, anglais, espagnols, etc. En gros, les developeurs americains sont peut-etre une dizaine.
A cote, si on compte le nombre de developeurs allemands de Gnome, on tombe a mon avis dans un rapport 95% / 5% avec KDE.
J'ai pas eu l'impression que Fedora soit tres populaire en Allemagne.
On trolle quand Fedora cache un peu KDE, mais dans certaines versions de Suse, Gnome etait limite en dehors du paysage et j'ai pas vu grand monde s'en plaindre.
Le but n'est pas de faire une gueguerre US/EU, c'est avant tout une constatation. Je crois a l'equation "Suse a 95% du marche allemand" et "100% des utilisateurs de Suse utilisent KDE en allemagne".
Un autre signe de la popularite de KDE en Allemagne, c'est qu'il y a des petites boites de services qui tournent autour de KDE / Suse (par exemple, ceux qui font Kontact / Kollab). Et puis KDE est un projet demarre par un allemand, largement popularise en Allemagne par un magazine allemand.
Je soupconne aussi que le projet dans sa facon de fonctionner et de se developper garde des marques de sa culture allemande (un peu plus carre).
De l'autre cote, Gnome est largement popularise au Etats-Unis, par Miguel, Havoc, etc
Surtout, il ne faudrait pas y voir une critique de quoi que ce soit, juste un constat.
Pour en revenir au sujet, KDE est tellement implante en Allemagne que Novell/Suse ne pourra pas le remplacer. Il y aussi de tres fervents supporters de KDE haut places chez Suse (plus haut que la ou est Miguel dans la pratique) qui vont defendre la place de KDE.
C'est pour ca que je maintiens ma position que pour l'instant, la strategie desktop de Novell ne passe pas par l'eradication de KDE ou Gnome mais qu'ils ne savent pas tres bien ou ils en sont. Une des caracterisitques de cette situation, c'est que suivant les personnes qui parlent, on a pas le meme son de cloche.
[^] # Re: Trop fade comme news
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un aperçu de GNOME 2.8. Évalué à 3.
Toujours est-il qu'avec des relations aussi floues, je doute que Sun file un centime a Red hat. Donc non, Red hat paye les developpeurs Red hat/Gnome de sa poche.
[^] # Re: Trop fade comme news
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un aperçu de GNOME 2.8. Évalué à 1.
Tu avances un non-sens: tu dis que KDE perds un de ses plus gros contributeurs mais en meme temps, il est dit dans l'article que Suse va continuer comme elle est, c'est a dire avec KDE. De toute facon, il ne faut pas se leurrer. Autant Gnome marche tres bien aux US, au temps en Allemagne, c'est 95% de KDE et on ne pourra pas migrer de force les clients de Suse a Gnome.
Ce que je comprends de l'article, c'est que les fonctionnalites Novell rentreront dans la partie Gnome. Et encore, quand on regarde de plus pres:
<<
For example, a calendar item entered in Evolution will appear in the GNOME calendar, and an instant-messenger nickname entered in Evolution will appear in the GAIM instant-messenger client. GNOME components Evolution and GAIM will dovetail with GroupWise server software, while the KDE equivalents--KMail and Kopete--will not.
>>
Ainsi, Evolution s'integre au calendrier Gnome, et les contacts seront partages entre Evolution et Gaim. Impressionnant ! En effet, c'est un truc qui Novell ne pourra pas contribuer a KDE vu que si je ne m'abuse, les contacts sont deja partages entre Kopete et Kontact.
Troll mis a part, tout ce qu'on peut retirer de l'article, c'est que la situation est loin d'etre claire a l'interieur de Novell. A mon avis, les entites americaines et europeennes n'ont pas la meme vision et la meme strategie ce qui donne un tableau plutot complique.
[^] # Re: Peut-être aurait-il été utile de préciser que...
Posté par Philippe F (site web personnel) . En réponse à la dépêche IronPython : implémentation pour Mono/.NET. Évalué à 4.
Tu parles peut-etre de l'implementation realisee par Mark Hammond un des gourou de la communaute python, implementation financee par Microsoft ?
Dans ce cas, je remballerai l'experssion "petits malins". Mark Hammond est extremement respecte dans la communaute python et il y a des raisons pour lesquelles son implementaiton n 'etait pas optimale, que Guido van Rossum detaille dans mon interview (http://www.freehackers.org/fosdem2002/guido.html(...)):
<<
Anyway, they did a Python port to .NET very early on, with some funding from Microsoft. I think the issue was mostly for Microsoft to show that Common Language Runtime really was a suitable target for multiple languages because they did the same thing with lot of language groups. [...] It's true that the Python .NET interpreter is very slow. I think part of that is just that they didn't have enough time to make it faster, there is always optimisations. The other thing was beacuase they did it so early on that they had to sign very strict Non Disclosure Agreements and Mark Hammond couldn't ask anyone for help because he was on NDA. He couldn't tell anybody even that he was working on this project until it was finished. So if he didn't know the compiler techniques, he was basically on his own. And there was also not much documentation about .NET available at that point, because .NET was basically still a Microsoft internal project. So I think now, this is based on a few things that Miguel told me actually. There are number of approaches to make it much faster.
>>
[^] # Re: Question ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Nouveau modèle de développement pour Linux. Évalué à 6.
Oui. Je pense que c'est le probleme no 1.
> Les quelques constructeurs qui veulent sortir des drivers pour Linux n'ont pas de difficultée à le faire.
Non. Les quelques constructeurs hyper motives qui veulent sortir des drivers pour Linux y arrivent tant bien que mal apres beaucoup d'efforts.
Imagine une boite qui fait un peripherique a la con. 95% de son marche est sous windows, 5% sous Linux (je suis tres optimiste, normalement, c'est 99.99999% ). Elle passe 2 ans a developper son driver avec son equipe de 2 personnes et il marche sous tous les windows. Elle est contente.
Mainenant, cette boite n'a aucun a priori sur Linux. Elle se dit que ca pourrait etre sympa de recuperer les 5% restant. De toute facon, sa version windows ne lui coute en maintenance que quelques jours-hommes par an donc elle a un tout petit peu de temps libre.
Voila qu'elle decouvre que si elle veut faire des drivers pour Linux, il faut qu'elle les fasse pour une version de Linux donnee. Ensuite, il faut qq'un qui suive en permanence l'evolution du kernel pour garantir que le driver n'est pas pete a chaque seconde qui passe. Sa maintenance va se chiffrer en mois-hommes parce que tout Linus a decide que l'api utilisee par le driver etait de toute facon pourrie et obsolete et va donc re-ecrire un truc completement incompable.
On imagine que la boite suit cette premiere transition. Apres, bien que le truc ait ete re-ecrit, il y encore des modifs a apporter a l'API du machin qui sont faites tranquillement, sans communiquer plus que un message sur la lkml, et qui petent le driver de nouveau.
Pour resumer, en terme de cout, un driver sous Linux, c'est quelque mois-hommes par an alors que le marche lui-meme est beaucoup plus faible que sous windows.
Le choix est vite fait pour n'importe quelle entreprise, il n'y aura pas de driver pour Linux. Mais ca Linus s'en fout apparemment.
[^] # Re: Question ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Nouveau modèle de développement pour Linux. Évalué à 1.
> pas dans le code du driver des hacks qui créeront des
> incompatibilitées avec des versions futures à cause de changement
> internes au noyau
Oui, mais dans ce cas, tu peux faire un report de bug clair incriminant le driver. Maintenant, la situation, ce sera "ca marche pas" sans que tu saches si un truc subtil a change dans le noyau, dans le driver, si le driver est code comme un pied ou si tu as un probleme sur ta machine.
Personellement, je considere ce modele de developpement comme une regression. Certe Linus aura moins de difficulte. Par contre, ca va etre la merde pour tout le monde en dehors de ceux qui suivent la lkml.
Les noyaux vont etre beaucoup moins testes par les utilisateurs puisqu'une mise a jour deviendra une operation tres dangereuse si on n'est pas sur de maitriser.
De tres gros projets arrivent tres bien a gerer l'evolution d'une base de code stable avec une evolution rapide (Mozilla, KDE, Gnome, Qt, Gtk) tout en conservant la compabilite binaire. Je ne vois pas pourquoi le noyau n'y arriverait pas. En fait, si , je vois tres bien. C'est parce que ca ne plait pas a Linus. C'est pas assez fun, c'est bien plus fun de tout peter a tout moment parce que ca nous plait que de conserver des API mouvante parce que soi-disant, ca va ameliorer la qualite des drivers.
Plus ca va, plus Linus fout la merde dans Linux. Mais c'est son bebe, on n'a rien a dire.
La phase "mais non, c'est pas dur de recompiler son noyau" ne pourra plus etre valable du tout.
Ca m'enerve vraiment. Quand je vois tous les efforts deployes par Trolltech, KDE ou Gnome pour qu'une mise a jour incompatible des lib se passe le plus tranquillement possible du monde, j'admire. Ils ne font ca que tous les 2 a 4 ans, ils preparent de bibliotheques de compabilite, ils preparent les developpeurs pendant plusieurs mois en faisant des snapshots, ils communiques, ils reflechissent longtemp a l'avance a ce qu'ils vont changer.
Linus, lui s'en bat tout simplement les couilles et je trouve ca dommage. Il a toujours eu cette attitude mais la ca devient vraiment genant. Le 2.6 ne pourra plus etre considere comme un noyau de reference.
[^] # Re: Oui mais..
Posté par Philippe F (site web personnel) . En réponse à la dépêche Nouvelle forme d'arnaque : l'usurpation d'identité de site web via XUL. Évalué à 10.
Le probleme souleve est au coeur du fonctionnement de XUL. A premiere vue, le spoofer fait exactement ce pour quoi XUL a ete prevu. Donc la facon la plus simple de remedier au probleme, c'est de supprimer l'execution XUL. Ah ouai, mais ca risque de serieuseement diminuer les possiblites du browser.
Bref, avant de predire, j'attends de vois ce que va proposer la communaute mozilla.
[^] # Re: apt
Posté par Philippe F (site web personnel) . En réponse au sondage Je réinstalle Linux sur mon ordinateur. Évalué à 2.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 2.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 2.
De fait, il y a des gens plus interessants et plus senses dans Gnome qui font heureusement avancer les choses de facon intelligente.
Cela dit, gtk#, je pense que c'est un bon concept. N'import quel langage objet me parait preferable a du C pour coder une appli graphique.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
Non, j'avoue avoir beaucoup de mal a te suivre dans tes raisonnements. Si plutot que de faire du delire, tu t'exprimais en phrases claires argumentees en parlant de faits reels ou au moins en proposant des explications qui se tiennent logiquement et socialement, ca serait plus facile de discuter avec toi.
> > C'est juste que dire que Ximian est completement independant de
> > Gnome et vice versa, ce n'est pas tout a fait vrai.
>
> Et tu veux en venir où ?
Je veux en venir au fait que quand tu dis que MDI est completement independant de Gnome, ce n'est pas vrai. MDI a encore via Ximian et via d'autre manieres une certaine influence sur le projet Gnome, bien qu'il n'en soit plus le leader ni meme un contributeur.
Et le fait que MDI bosse sur Mono encourage la communaute Gnome a reflechir autour de Mono. Ce n'est pas negatif mais c'est indeniable.
Et pour revenir a mon argumentation originelle (car perso, je tiens ma ligne de raisonnement), les differentes declarations de MDI ont enerve ou decu au cours du temps un certains nombre de membres de la communaute Gnome (car tout le monde dans Gnome ne voue pas une admiration sans borne a MDI et ses methodes). La direction actuelle de Gnome a largement ete insuflee par MDI et elle est differente de ce dont il faisait la promotion au moment de Gnome 1.0 et meme avant.
Donc il y a un certain nombre de mecontents chez Gnome qui se retrouveront probablement dans ce fork. Non, a peu d'exceptions pres, ils n'iront pas vers KDE car ils aiment bien le framework Gnome et ce qu'ils en ont fait. En revanche, ils ne sont pas necessairement en accord avec la direction pro-entreprise, pro-simplification qui (mais je me repete) etait loin de faire partie de Gnome dans sa version initiale. A l'epoque, c'etait meme Gnome le bureau de hacker hyper configurable et KDE le bureau pour les neuneu venant du monde windows.
[^] # Re: Un fork pour un gnome d'expert
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 1.
Pour les seconds, Gnome a choisi de cacher pour pas que les premiers tombent dessus. KDE a fait le choix de les considerer comme des utilisateurs legitimes et de leur donner aussi une belle interface graphique.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 2.
> C'est claire.
Ca ce n'est pas vrai. Il n'a pas ecrit de code pour Gnome mais il contribue au projet autrement. Il pousse le desktop dans les entreprises, il developpe evolution pour que Gnome puisse etre accepte en entreprise.
Il continue aussi a avoir son role de visionnaire. Quand il voit une bonne techno et qu'il pond un article en disant a quelle point elle est interessante, tous les hackers de Gnome regardent ce qu'il dit. Et ca n'a rien de negatif. MDI est un hacker de Gnome respecte pour sa contribution par les autres hackers de Gnome, donc quand il dit qqch, les autres l'ecoute.
Bref, nier qu'il y a encore des liens entre MDI et Gnome me parait un peu extreme comme attitude. Cependant, c'est sur qu'il n'est pas a la direction de Gnome et qu'il repete toutes les jours que Gnome ne sera pas developpe en mono. A ton avis, pourquoi il a besoin de le repeter autant ? Serait-ce parce que en raison de son role historique dans Gnome, des gens s'imaginent le contraire ?
[^] # Re: Un fork pour un gnome d'expert
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 2.
- fond d'écran
- économiseur d'écran
Comme tu peux faire ces deux choses sans passer par le centre de controle, l'ergonomie de celui-ci est un tout petit peu moins importante.
Perso, dans le centre de controle KDE, comme il est complique, j'utilise tout le temps la fonction recherche. Je trouve tout ce que je veux du premier coup.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 3.
Ce que te dis le monsieur, c'est que pendant quelques temps, la page de download officielle de Gnome etait chez Ximian. Ce probleme a ete corrige rapidement (en quelques jours si je me souviens bien), justement pour montrer que Gnome est bien independant dans la mesure du possible de Ximian et eviter les polemiques "Ximian controle gnome etc"
Exhiber la page de download actuelle et sortir ton delire sur Redhat ne change rien au fait que ce dont on parle est arrive.
Pour eviter toute surinterpretation, ce n'est pas mal que Ximian aie des liens forts avec Gnome. Ils contribuent avec evolution et les developpeurs de Ximian sont de tres gros contributeurs de Gnome et sont tres respectes.
C'est juste que dire que Ximian est completement independant de Gnome et vice versa, ce n'est pas tout a fait vrai.
[^] # Re: C'estle genre de brevets qui peut faire avancer les choses
Posté par Philippe F (site web personnel) . En réponse à la dépêche Microsoft et Apple poursuivis pour violation de brevet. Évalué à 3.
Exemple auquel j'ai ete confronte : transposition dans le monde de le carte a puce d'une technique logicielle a la con utilise couramment dans les appli non embarquee.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 3.
Et non, ce ne sont pas eux les responsables. Au contraire, ils ont fait un travail formidable dont l'ampleur est probablement mal appreciee.
Les responsables, ce sont qui ont affirme haut et fort que Corba etait parfaitement adapte comme modele de composant pour un desktop et ont continue sur ce choix technique. Ils ont fait fi de l'experience de KDE qui a renonce a CORBA a bout de deux ans de galere et ecrit un remplacant en moins d'un mois.
Corba est une tres bonne techno, mais c'est trop lourd par rapport aux besoins d'une techno de composant desktop. Donc il y a eu un travail enorme qui a ete fait pour rendre CORBA accessible relativement simplement en C. Du coup les developpeurs sont tellement pris dans Corba que documenter l'interface bonobo relativement triviale, ca leur parait superflu (ce dernier point est ma petite interpretation).
A cote, KDE est parti d'une techno existante et l'a a peine modifie pour en faire une techno de communication qui convenait parfaitement.
Et ce choix technique de CORBA, MDI en est en partie responsable. Comme il est responsable de pas mal d'autres choses chez Gnome, en bien comme en mal.