> Les GString ne sont pas utilisée dans les API publiques
Une connerie a mon avis, vu que sur un 'char *' tu as plus de doute sur la nature de l'encodage utilise justement.
Qt a des fonctions de conversions utf8 ucs2, mais c'est vrai que c'est con. Imagine pour une appli un peu complexe si tu dois passer des strucutures de donnees un poil elaborees (dictionnaires, string, listes) l e nombre de conversion qu'il pourrait y avoir.
Pour chipoter vraiment, il me semble que glib comme qt ont une classe qui gere de listes de strings directement.
Ces tutoriaux a 500 euro sont destines a des societes souhaitant former leurs ingenieurs a KDE ou Qt et servent notamment a financer la conference. Si tu te souviens a la linux expo, il y a ce genre de classique corresponsdant a tout salon professionnel.
cf la page principale:
<<
KDE e.V. is soliciting donations from companies and individuals towards this conference. These donations will be used both for running the complete "2004 KDE Contributors and Users Conference" (code-named aKademy) and for bursaries for delegates from other continents and/or without income. Delegates with an accepted paper/presentation will be prioritized in the distribution of these bursaries.
The tutorial program announced here is geared to raise funds for the same purpose. The tutorials will be offering excellent quality content, delivered by world-class instructors on their respective fields, and we are asking for a competitive participation fee in exchange. We are aiming to get Linux power users and administrators as well as other IT professionals (from the Stuttgart Region as well as anywhere else in the world) into participating here, with their employers paying the tutorial fees.
>
IBM et HP pournissent de l'equipement, la ville et le LUG sur place aident beaucoup pour la logistique. HP a aussi fait une offre interessante d'achats d'un nombre limite de portables pour les developpeurs KDE
Pour ce qui est du resultat financier, on en saura plus dans quelques jours.
Moi je pense comme le posteur original que c'en est un. En revanche, je suis rassure car on voit un certain nombre de projets qui permettent de gommer ces incompatbilites:
- themes commun gnome / kde / mozilla
- integration de OO dans Gnome
- integration de OO dans KDE
- utilisations des themes KDE par les applis Gnome
- utilisations des technologies KDE par les applis non KDE
- une convergence du cote de freedesktop
- des bonnes nouvlles comme la possibilite d'utiliser gstreamer
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.
>>
[^] # Re: ouah
Posté par Philippe F (site web personnel) . En réponse à la dépêche The aKademy 2004 a commencé. Évalué à 5.
Une connerie a mon avis, vu que sur un 'char *' tu as plus de doute sur la nature de l'encodage utilise justement.
Qt a des fonctions de conversions utf8 ucs2, mais c'est vrai que c'est con. Imagine pour une appli un peu complexe si tu dois passer des strucutures de donnees un poil elaborees (dictionnaires, string, listes) l e nombre de conversion qu'il pourrait y avoir.
Pour chipoter vraiment, il me semble que glib comme qt ont une classe qui gere de listes de strings directement.
[^] # Re: Module 6: ne pas retarder Sarge
Posté par Philippe F (site web personnel) . En réponse à la dépêche The aKademy 2004 a commencé. Évalué à 3.
cf la page principale:
<<
KDE e.V. is soliciting donations from companies and individuals towards this conference. These donations will be used both for running the complete "2004 KDE Contributors and Users Conference" (code-named aKademy) and for bursaries for delegates from other continents and/or without income. Delegates with an accepted paper/presentation will be prioritized in the distribution of these bursaries.
The tutorial program announced here is geared to raise funds for the same purpose. The tutorials will be offering excellent quality content, delivered by world-class instructors on their respective fields, and we are asking for a competitive participation fee in exchange. We are aiming to get Linux power users and administrators as well as other IT professionals (from the Stuttgart Region as well as anywhere else in the world) into participating here, with their employers paying the tutorial fees.
>
Pour les sponsors effectifs, on a:
http://conference2004.kde.org/sponsors.php(...)
IBM et HP pournissent de l'equipement, la ville et le LUG sur place aident beaucoup pour la logistique. HP a aussi fait une offre interessante d'achats d'un nombre limite de portables pour les developpeurs KDE
Pour ce qui est du resultat financier, on en saura plus dans quelques jours.
[^] # Re: ouah
Posté par Philippe F (site web personnel) . En réponse à la dépêche The aKademy 2004 a commencé. Évalué à 3.
Moi je pense comme le posteur original que c'en est un. En revanche, je suis rassure car on voit un certain nombre de projets qui permettent de gommer ces incompatbilites:
- themes commun gnome / kde / mozilla
- integration de OO dans Gnome
- integration de OO dans KDE
- utilisations des themes KDE par les applis Gnome
- utilisations des technologies KDE par les applis non KDE
- une convergence du cote de freedesktop
- des bonnes nouvlles comme la possibilite d'utiliser gstreamer
http://wiki.kdenews.org/tiki-index.php?page=KDE%2C+the+integrative+(...)
Donc dans l'ensemble, ca avance dans la bonne direction.
[^] # 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.
>>