Justement, personne dans KDE ne connait ce qui va arriver. Ce qui est clair, c'est que arts commence a faire chier pas mal de monde (pour ma part, il me fait chier depuis le debut). L"Akademy va permettre de faire le point sur tout ca, surtout avec la perspective de KDE 4.
De toute facon, en logiciel libre, c'est le logiciel le plus dynamique qui s'impose, et gstreamer m'a bien l'air de repondre a cette definition.
Le probleme pour integrer des trucs comme gstreamer, c'est que les types de bases ne sont pas compatibles. Genre sous KDE, tu geres un qlist de qstring et tu dois convertir ca en glist dont le champ data contient une gstring. Dans le cas de gstreamer, c'est peut-etre pas aussi violent vu que les string ne sont pas au coeur de l'application mais ce genre de probleme entraine de traductions lourde a la volee de gstring (code en utf8) en qstring (codees en UCS2) qui ralentisse le fonctionnement global et rende tres difficile la croisee de projets entre Gnome et KDE.
On peut dire que linuxfr rivalise de news entre KDE et Gnome. C'est bon signe, ca veut dire que les deux projets se portent bien et sont dynamiques. Quand le logiciel libre avance, tout le monde y gagne.
> Il doit être très difficile d'intégrer du code dépendant de l'application avec du code dépendant de l'interface graphique sans avoir un couplage
> indésirable
Ben non, il suffit de faire attention. Il est toujours tres interessant de separer le coeur de l'application de son interface graphique:
- pour la rendre plus facile a tester
- pour facilement modifier l'interface graphique
- pour ajouter de nouvelles interfaces (ligne de commandes, ...)
<< Cote Gnome, je pense a GnomeMeeting, ou Evolution qui n'ont pas d'equivalents libres >>
Je me suis mal exprime. Je voulais dire que ces applications sont uniques dans le monde du libre. Si on prend Abiword, on trouve tout de suite openoffice ou koffice. Si on prend xine, on trouve tout de suite mplayer.
J'avoue que bien qu'etant un grand supporter de KDE, je suis tout a fait d'accord.
En general, je trouve les logiciels KDE tres bien faits, c'est a dire qu'ils repartent d'un concept existant (un navigateur, un player de mp3, ...) et en font un outil super ergonomique avec plein de fonctionnalites sympa. C'est a mon avis la facilite de developpement avec Qt/KDE qui permet de rajouter toutes ces petites fonctionnalites qui font que la version KDE au final s'en sort mieux que son concurrent initial. Les developpeurs de KDE aiment aussi les outils puissants et facile a utiliser, et ca s'en ressent dans un certains nombre d'applications qui font plus que le minimum legal.
On peut prendre par exemple k3b, qui au depart etait moins bien que X-CD-Roast on Toaster. Maintenant, bien qu'au depart les deux logiciels fassent la meme chose, k3b est le meilleur logiciel de gravage.
D'un autre cote, si KDE innove dans les details, il manque des applications vraiment uniques. Cote Gnome, je pense a GnomeMeeting, ou Evolution qui n'ont pas d'equivalents libres (c'est plus vrai pour evolution mais ce fut initialsment le cas). Cote KDE, des applis qu'on ne retrouve nulle part ailleurs, il faut en chercher. Je vois KStars, KDiff3, KDevelop, Kachegrind et c'est a peu pres tout.
Dans la serie des outils comme ca, KDE aussi une regle qui permet de mesurer la taille des fenetres ou d'elements graphiques en pixel. Bien pratique dans certaines situations. D'ailleurs, je vais en faire un astuce.
Moi, ma signature, c'est un .zip nomme "Document tres important".
Bizarrement, mes interlocuteurs ne recoivent jamais mes mails :-)
Sinon, j'ai une selection de phrase hautement philosophique a portee humaniste, genre :
"It is said that if one million monkey type one million messages, one of them shall type the content of Hamlet. Thank to usenet, we now know that this is not true".
ou bien
"Dad, we should we hide from the Police ?
Because they use emacs, son, and we use vi".
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.
[^] # Re: ouah
Posté par Philippe F (site web personnel) . En réponse à la dépêche The aKademy 2004 a commencé. Évalué à 7.
De toute facon, en logiciel libre, c'est le logiciel le plus dynamique qui s'impose, et gstreamer m'a bien l'air de repondre a cette definition.
Le probleme pour integrer des trucs comme gstreamer, c'est que les types de bases ne sont pas compatibles. Genre sous KDE, tu geres un qlist de qstring et tu dois convertir ca en glist dont le champ data contient une gstring. Dans le cas de gstreamer, c'est peut-etre pas aussi violent vu que les string ne sont pas au coeur de l'application mais ce genre de probleme entraine de traductions lourde a la volee de gstring (code en utf8) en qstring (codees en UCS2) qui ralentisse le fonctionnement global et rende tres difficile la croisee de projets entre Gnome et KDE.
# ouah
Posté par Philippe F (site web personnel) . En réponse à la dépêche The aKademy 2004 a commencé. Évalué à 3.
[^] # Re: Et la librairie GTKMM ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche S'investir dans le projet Gnome, développeur ou non.. Évalué à 2.
> indésirable
Ben non, il suffit de faire attention. Il est toujours tres interessant de separer le coeur de l'application de son interface graphique:
- pour la rendre plus facile a tester
- pour facilement modifier l'interface graphique
- pour ajouter de nouvelles interfaces (ligne de commandes, ...)
[^] # Re: Merci ploum !
Posté par Philippe F (site web personnel) . En réponse à la dépêche S'investir dans le projet Gnome, développeur ou non.. Évalué à 5.
[^] # Re: Evolution et GnomeMeeting sont libres
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE 3.3 disponible. Évalué à 3.
Je me suis mal exprime. Je voulais dire que ces applications sont uniques dans le monde du libre. Si on prend Abiword, on trouve tout de suite openoffice ou koffice. Si on prend xine, on trouve tout de suite mplayer.
[^] # Re: Le logiciel "a la"
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE 3.3 disponible. Évalué à 7.
En general, je trouve les logiciels KDE tres bien faits, c'est a dire qu'ils repartent d'un concept existant (un navigateur, un player de mp3, ...) et en font un outil super ergonomique avec plein de fonctionnalites sympa. C'est a mon avis la facilite de developpement avec Qt/KDE qui permet de rajouter toutes ces petites fonctionnalites qui font que la version KDE au final s'en sort mieux que son concurrent initial. Les developpeurs de KDE aiment aussi les outils puissants et facile a utiliser, et ca s'en ressent dans un certains nombre d'applications qui font plus que le minimum legal.
On peut prendre par exemple k3b, qui au depart etait moins bien que X-CD-Roast on Toaster. Maintenant, bien qu'au depart les deux logiciels fassent la meme chose, k3b est le meilleur logiciel de gravage.
D'un autre cote, si KDE innove dans les details, il manque des applications vraiment uniques. Cote Gnome, je pense a GnomeMeeting, ou Evolution qui n'ont pas d'equivalents libres (c'est plus vrai pour evolution mais ce fut initialsment le cas). Cote KDE, des applis qu'on ne retrouve nulle part ailleurs, il faut en chercher. Je vois KStars, KDiff3, KDevelop, Kachegrind et c'est a peu pres tout.
[^] # Re: Le logiciel "a la"
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE 3.3 disponible. Évalué à 5.
ALT-F2, gg:I want a big konquy
et tu trouves tout de suite ton bonheur. Idem pour les pages de man, ou les pages info:
ALT-F2: info:cvs
ALT-F2: man:lilo
Je trouve ca vraiment top pratique.
# Regle
Posté par Philippe F (site web personnel) . En réponse au message [X/KDE] La pipette de KDE. Évalué à 2.
[^] # Re: EAI ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Nouvelle version stable de BIE (v 6.0.3). Évalué à 3.
[^] # Re: signature
Posté par Philippe F (site web personnel) . En réponse au sondage La signature en bas de mes mails est. Évalué à 4.
Bizarrement, mes interlocuteurs ne recoivent jamais mes mails :-)
Sinon, j'ai une selection de phrase hautement philosophique a portee humaniste, genre :
"It is said that if one million monkey type one million messages, one of them shall type the content of Hamlet. Thank to usenet, we now know that this is not true".
ou bien
"Dad, we should we hide from the Police ?
Because they use emacs, son, and we use vi".
[^] # 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.