Philippe F a écrit 2204 commentaires

Je ne suis pas un specialiste KDE meme si je suis le projet de pres. Ce qui est sur, c'est que je ne suis pas du tout un specialiste de webcore.

Cela dit, d'apres ce que j'ai compris, c'est en effet pas l'objective C qui pose des problemes, mais plus l'utilisation de routines graphiques propres a MacOs X, qui ne sont pas transposable sous X.

Pour ce qui est de ton autre remarque, je moderai un peu. Il y a plein de projets libres qui sont codes comme des cochons, et plein de projets proprio ou chaque commit est soigneusement etudie avant d'etre envoye.

Et puis les problemes d'integration, c'est pas forcement que les trucs sont codes comme des cochons, c'est juste que c'est pas code comme les dev de khtml le voudraient. Et les mecs de Apple n'ont malheureusement pas le temps de reprendre leur code (ils ont visiblement une pression enorme, c'est un des mecs de KDE qui les a vu qui le confirme).

Donc tu peux instancier des classes C++. Il y a pas besoin d'un .h en objective C pour faire ca ?

Qt s'appuie beaucoup sur l'heritage et la surcharge de methodes pour fonctionner. Si tu ne peux faire aucune de ces deux choses, tu ne vas pas aller tres loin.

Mais quand meme ca ouvre des perspectives...

Mais maintenant que tu as le CVS, tu vas pouvoir la compiler et reporter gentiment des bugs a Apple.

Je m'avance un peu mais M. Binding de KDE, nom de code Richard Dale a commence a travailler sur les bindings de KDE uniquement pour pouvoir ecrire des applis KDE en Objective C. Depuis, il s'est plus tourne vers java, ruby et C# mais je ne serai pas surpris que les bindings objective C marchent encore.

Mais il faut bien plus que gcc pour faire marcher KDE en objective C. Il faut que chaque classe C++ soit egalement accessible en objective C, ce qui represente le gros du travail du binding. Heureusement, tout ca est relativement automatise, de sorte qu'on a un moteur (nom de code smoke) qui genere un "runtime", c'est a dire un espece de pont generique entre KDE/Qt et des fonctions en C. Generer des bindings revient a alors juste a interfacer le "runtime".

Ce qui a joue, c'est surtout la communication. Apple est tres tres sensible a sa communication. Et c'est clair que c'est pas le moment de se mettre a dos la communaute du libre, avec tout ce qu'ils ont a gagner a une cooperation linux / Apple.

Tout a fait. Sa sortie, est une non news. En plus, c'est presque deprimant pour tous les sujets de conversations qui vont disparaitre.

Ben ouai, mais moi, je prefere avoir 3h d'autonomie et un peu moins de puissance que l'inverse. Tout le monde n'est pas focalise vers la course a la performance. Je peux attendre 3 secondes de plus pour que firefox se charge.

Aujourd'hui, si tu veux acheter un materiel en faisant le choix d'avoir moins de performance, plus de silence, moins de consommation, c'est difficile. La seule chose que les revendeurs savent te vendre, c'est plus. Plus de vitesse, plus de ceci, plus de cela.

Pour une carte d'identite, 50 cm, c'est du delire. Si t'arrives a faire 5 cm, c'est deja un miracle.

Les distances que tu vois, c'est pour des tags tout betes, qui renvoient juste un numero de serie. C'est bien pour tracer le colis UPS, c'est pas du tout adapte a la securite.

Pour tout ce qui est spec de securite (carte d'identite, permis de conduire, passeport, carte de sante, ...), on utilise un microprocesseur qui est telealimente. La norme de communication utilisee est l'ISO 14443, ou les distances varient theoriquement de 0 a 10 cm. Dans la pratique, 5 cm, c'est beaucoup. 50 cm, c'est possible avec une super antenne cote lecteur, mais tu risques de mettre feu a la carte tellement ca va chauffer.

Pour ce qui est de la gestion de plusieurs reponses simultanees, des protocoles sont prevus pour gerer ca. Ca varie suivant les technos utilisees mais on peut gerer jusqu'a 10 cartes dans le champ sans trop de probleme.

J'ajoute que ces specs sont plutot bien concues, a savoir que tu ne peux pas espionner facilement a distance une personne. Typiquement, pour le passeport, il est impossible de lire le contenu electronique du passeport sans avoir au prealable lu physiquement le contenu du passeport (nom, prenom, etc) parce que les infos utilisateurs ne sont pas stockees dans la partie puce, mais servent a l'authentification.

Toutes les specs d'identite sont en train de s'appuyer sur la spec du passeport, donc niveau securite et respect de la vie privee, c'est plutot la bonne direction. Apres, malheureusement, il y a toujours un malin qui rajoute une base de donnee.

Je suis pas un expert de X, mais il me semble que tu accumules beaucoup d'erreurs en un seul post.

> - tout le rendu par X se fait via des IPC de type socket.
Tout a fait faux. C'est vrai uniquement quand le serveur et le client ne sont pas sur la meme machine. Sinon, ca se fait via de la memoire partage, ce qui est extremement rapide.

> - X n'a aucune couche ressemblant à du vectoriel et ne gere que des bitmaps et qq polices codés en dur
Le vectoriel arrive a grand pas dans X avec cairo. Pour ce qui est des polices, elles sont chargees lors du demarrage de X et il n'est pas tres difficile d'en ajouter.

> - X ne gere pas vraiment l'anti-aliasing, le rendu est souvent fait coté client et transmis par IPC ( pango au hasard )

Bizarre, il me semblait que c'etait l'objet de l'extentsion XRandR et que c'est grace a ca qu'on a l'antialiasing dans Qt puis de Gtk.

Pour le reste, je ne suis pas bien place pour contrer.

J'en ai discute avec des gens comme Mathias Ettrich qui ont connaissent les arcanes de X pour avoir optimise Qt dessus. Ils ont une tres bonne opinion de X. Certains aspects du projet sont en retard, mais globalement, c'est une bonne technologie.

Mais j'utilise un langage avec un modele objet. Je posais la question de savoir pourquoi le modele de pygtk etait considere "au top" ?

Peut-etre est-ce juste en comparaison du modle objet de gtk tout court. C'est sur qu'il y a de la marge.

Je m'etais amuse a faire des erreurs de syntaxes dans les declarations des types d'objets en Gtk. Comme je m'y attendais, aucune erreur n'a ete detectee. Ca me parait dangereux quand meme.

Nombre de gens disent "je prefere X parce que Y n'est pas la fonctionnalite A" et tu leux montres que Y a la fonctionnalite A mais ils ne changent pas d'avis.

Tu as tort a mon avis de croire que les preferences de desktop sont rationelles. C'est irrationnel, emotionnel. Il y a bien sur des petits bouts de logique pour justifier tout ca, mais ca ne va pas bien loin.

> et je trouve le modèle objet de GTK vraiment au top

La, tu m'en bouches un coin ? Tu sais comment est fait ton modele objet "au top" ? Pour heriter d'une structure, ou cree une nouvelle structure dont le premier membre est la structure precedente. Et derriere, on fait des gros cast crados en C pour mapper tout ca et faire croire que le C peut faire de l'heritage.

C'est quoi qui te fais dire qu'il est "au top" ?

Je precise que KDE a ete oublie de cette liste, mais c'est en cours de correction. Si vous voulez faire un bounty pour KDE, patientez quelques jours, et vous aurez une liste a votre disposition.

C'est peut-etre pas l'etudiant moyen, mais quand KDE a demarre, 95% de ses developpeurs etaient etudiants, et ca ne les a pas empeche de faire un des meilleurs desktop linux. Linus lui-meme etait etudiant.

C'est sur que c'est plus dur que de faire un demineur, mais bon, vous voulez devenir informaticien ou non ?

Perso, j'utilise la version non commerciale de Qt3 (disponible avec le bouquin sur la programmation Qt). C'est pas GPL, mais ca marche tres bien sous windows. Je dois juste ajouter une clause d'exception dans la licence de mon soft.

Des que Qt4 sera sorti, je basculerai dessus.

Sinon, je ne suis pas trop d'accord de dire que Gtk est plus business friendly que Qt. Ce qui est business friendly, c'est d'avoir un support technique sur qui tu peux compter 24h/24, des gens sur qui tu peux raler quand ca marche pas et des professionnels qui te _garantissent_ que ton soft marchera avec ton toolkit sous windows linux mac hpux solaris etc etc.

Il manque toutes ces choses a Gtk. Notamment, il n'y a personne qui te garantit que gtk marchera sans probleme sous windows et sous macos. A la difference de Trolltech, qui pour tes 1500 $, te garantit que t'auras 0 probleme de portage (ce que je confirme).

De plus, GTk sous windows a il me semble un certain nombre de limitations. Typiquement il me semble que le port a ete fait pour des gens qui developpent avec gcc. Si tu utilises borland ou Visual, ce qui est assez courant sous windows, le support va devenir beaucoup plus difficile a assurer. Un mec qui fait du logciiel libre n'est en general pas tres motive pour faire du support sur des IDE bugges et non libres faits par Microsoft.

J'ajouterai aussi que beaucoup de developpements professionnels sont aujourd'hui fait en C++ ou en java. Avec un toolkit en C, tu vas avoir du mal a expliquer que t'es plus productif a ton manager alors que ca fait 5 ans que tous les devs sont passes du C au C++.

Bref, je pense que les 1500$ de licence commerciale de Qt pour le monde professionnel sont bien depenses. Si tu perds 3 jours sur un projet, ca veut dire que ta boite t'a paye pendant 3 jours sans resultats. Le cout homme d'une journee (salaire + locaux + charges + ...) c'est d'enfiron 700 euro. A partir de 2 jours, tu es rentre dans tes frais.

> Jusqu'à présent en tout cas, la GPL a l'avantage d'être bien connue et beaucoup étudiée,

Certe, mais la GPL a ete redigee par des juristes americains, pour le droit americain.

Ici, on a une licence redigee par des juristes francais, pour le droit francais.

En France, je preferai utiliser la Cecill car le fait qu'elle ait ete redigee pour le droit francais permet surement de mieux la defendre devant des tribunaux. Cela dit, tous mes softs ont une portee internationale, donc j'utiliserai la GPL.

Mais je suis tout a fait en desaccord avec ton analyse de risque juridique.

Trop fort, c'est un peu une couche d'emulation de links dans firefox !

Yzis fait son petit bonhomme de chemin.

Il compile a la fois sur Qt3 et sur Qt4. Ce matin, panard a commence a ajoute le support pour le folding. Cote scripting, je viens de rajouter le support des regexp facon perl (une simple couche d'interfacage avec les excellentes regexp Qt).

Mikmak fait le portage Qt3 -> Qt4 de KDE donc il a un peu moins de temps a consacrer a yzis.

Quelqu'un a lance une discussion sur comp.editor a propos de yzis et de lua. Au passage, une ou deux personnes ont mentionne des scripts qui leur paraissaient cle pour vim: vimoutliner et vst. Donc on releve le defi de les porter rapidement. C'est pour ca que je rajoute les regexp et j'imagine que c'est ce qui a motive panard a ajouter le folding. Normalement, je devrai arriver a du code deux fois plus lisible, et tout aussi fonctionnel d'ici quelques semaines.

Cote Gnome, mikmak avait commence un petit truc, mais il lui manque la motivation. Il faudrait qu'un gnomeux prenne le truc en main. Il faut aussi passer l'etape psychlogique d'avoir un programme qui link a la fois avec Gtk et avec Qt, et qui utilise un certain nombre de classes Qt de base (regexp, listes, boucle d'evenement, ...). Mais si on franchit ce seuil psychologique, on peut vraiment faire qqch de sympa.

On note qu'il y a de plus en plus de bug report qui arrivent, donc de plus en plus de gens qui utilisent yzis au quotidien, notamment en tant que kpart dans kdevelop. C'est a dire que il est suffisamment stable pour etre utilise au quotidien.

Avec Qt4, on devrait avoir une version windows GPL, ainsi qu'une version de libyzis qui ne depend que des libs non graphique de Qt.

Il y a encore du boulot, mais quand je vois le temps qu'il a fallu pour avoir toutes les fonctionnalites actuelles de vim, et le temps qu'on met pour les refaire dans yzis, je sais qu'on est sur la bonne voie.

Ma prediction, c'est que d'ici 2007, yzis aura le meme niveau de fonctionnalite que vim.

Et tous les coups de main sont les bienvenus. Fan de vi, contribuez a cet excellent moteur vi re-utilisable dans tous vos programmes.

J'avais mal interprete ta phrase. J'ai cru que tu demandais une couche en C pour programmer sous KDE, et c'est a cette possibilite que je faisais reference.

Sinon, de fait, KDE propose une couche en C automatiquement generee, qui ne demande pas de maintenance. Le developpeur du binding n'a plus qu'a integrer cette couche dans un moteur et hop, ca marche (ca doit etre un poil plus complique quand meme) donc il n'a lui aussi pas de maintenance (theoriquement) a effectuer.

Ok, je comprends mieux. Pour un besoin ponctuel et limite, c'est en effet exploitable. Mais dans le cadre ou tu proposes un framework de developpement comme Gnome, ce n'est pas le cas.

Le but du binding, c'est de proposer le confort du langage cible, avec les fonctionnalites du projet original. Ca demande beaucoup de travail affinage pour que toutes les problematiques de binding, de gestion de memoire et autres restent transparentes.

Tout ce qui a ete dit est vrai, mais il y a d'autres solutions. Si le fait que ce soft shareware ne soit pas open source ne te pose pas de probleme, tu peux :
- inclure une exception dans la licence GPL permettant de te linker avec ce soft sans pour autant que ce soft ne soit GPL

- utiliser une autre licence moins contaminante (creative commons) mais ca me paraitrait dommage

- faire le choix de la LGPL qui n'oblige pas les derives de ton soft a etre GPL mais qui conserve l'obligation pour quiconque utilie ton soft de respecter la LGPL.

Bref, c'est pas les solutions qui manquent. D'un autre cote, si t'arrive a tout faire en GPL, c'est encore mieux.

Je suis surpris qu'ils aient choisi autotools. Il y a quelques annees, la question ne se posait pas, mais aujourd'hui, il y a un certain nombre d'alternatives qui pointent leur nez et qui ont l'air tres interessante (citons scons par exemple).

A l'heure ou KDE envisage de se debarasser d'autotools, j'espere qu'ils ont bien reflechi a la chose.

Et ca te gene d'argumenter comme ca ?

On parle de faire un binding, et toi tu nous dis que pour faire un truc completement merdique, c'est facile. C'est super interessant comme info.

> Avec ta couche supérieur en C par dessus le C++ le compilateur aura les même problèmes
> quand le langage de haut niveau cherchera à dériver le code C++ : il sera bien enmerder pour optimiser.

Ben non. La derivation a deja ete faite en C++ (donc deja optimisee). Ensuite, la classe est visible dans ton langage cible. Si ce langage supporte la derivation, la derivation sera faite dans ce langage cible. La couche c ne sert vraiment qu'a transferer des appels.

Cela dit, tu as probablement raison que le plus lent, dans tout ca, c'est le langage cible. Sauf si ce n'est pas un langage de script : ada, ocaml, objective C.

> le C est nécessaire, et KDE devrait proposer des API sous cette forme,

Ben non, on est pas maso. Si tu veux faire des applis C graphiques, va voir Gnome, tu seras plus heureux. Les devs de KDE ont des criteres de qualite pour la facilite de developpement que le C ne remplit pas, et encore moins du C wrappant du C++. Ca a ete fait a une epoque et c'etait immonde.

Je pense qu'il est possible de voir l'avantage de programmer dans un langage objet lorsque tu manipules des concepts objets a tour de bras. Quitte a faire un binding aussi debile, je preferai le faire pour le brainfuck (http://www.muppetlabs.com/~breadbox/bf/).(...) Au moins, je sais pourquoi je le fais.

> Mais fournir aux utilisateurs une API C++ (non standard), c'est vraiement pas faciliter la vie des binders.

Pourquoi est-ce que j'ai l'impression de me repeter 23 fois ? Ton argument est completement ecule. D'une part, il semble avoir ete exprime ici clairement que le C est loin de faciliter la vie des binder non plus pour d'autres raisons. D'autres part, KDE a resolue ce probleme du C++ en generant automatiquement une couche intermediaire en C extraite automatiquement des headers KDE.

Donc KDE facilite la vie des binders sur deux plans, et ce depuis 2002:
- la generation des api KDE dans un langage intermediaire est automatisee et maintenue a chaque version de KDE : pas besoin aux binders de maintenir cette partie la
- ils doivent uniquement s'occuper de la semantique du langage qu'ils binde, sachant que smoke prevoit deja toutes les caracteristiques des langages de scripts actuels : introspection et typage dynamique notamment.

<< Yahoo. Donc tu proposes de mettre une couche C à KDE. Clap clap clap. Tu dis que en c++ c ouachement mieux parcque c optimisé par rapport à C machin machin, et tu proposes de justement de rajouter une couche qui, si on te suit, n'est pas optimisé puisqu'en C. Cherche l'erreur.
>>

Tu peux essayer de tourner la phrase pour que ce que je dise paraisse debile mais je maintiens.

Tu as plusieurs niveaux:
- Gtk (avant gobject), avec un framework objet emule en C, et eventuellement un binding genere a la main. Le compilateur ne peut pas optimiser correctement les parties objet du code car il ne connait pas l'objet. Les bindings attaquent directement les .h de gtk (bien que ce point soit a verifier, je ne serait pas surpris qu'il y aie des couches intermediaires, par exemple pour gerer le comptage de reference et autres joyeusetes des langages de script).

- KDE, avec un framework en C++, que le compilateur peut optimiser correctement. Ce framework genere ensuite une _interface_ en C, qui utilise en interne du C++ (qui est donc optimisee correctement par le compilateur), mais qui ajoute au moins un appel de fonction par methode. Pour info, le cout d'un appel de fonction de nos jours et negligeable, plus particulierement dans un gui ou c'est l'utilisateur qui declenche les evenements.

- Gnome + Gobject : le framework objet s'est complexifie, mais est toujours en C (donc toujours aussi difficile a optimiser) mais en plus, on genere une couche intermediaire qui sert a interfacer le binding. Bref, on cumule deux inconvenients en terme de performance, mais on gagne en qualite des bindings et en quantite de travail.

Il serait interessant de valider ce que j'affirme avec des benchs. Je serai infiniment surpris si l'appel d'une methode virtuelle en gobject etait plus rapide qu'en C++. J'essaye d'imaginer le nombre d'etape intermediaire par lequel le code C passe pour simuler une methode virtuelle.

> Si tu veux te contenter d'appeler les API à la mode C, t'as toutes les infos nécessaire dans le .h

Ok, je prends deux fonctions au hasard:
cf http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Fun(...)

- g_strstr() renvoie un gchar * deja alloue a ne pas liberer.
- g_strdup_printf() renvoie un char * qui doit etre libere.

Dis moi comment un binding base sur une moulinette du .h peut savoir si il doit faire des gfree sur les chaines renvoyees par ces fonctions. Tu es oblige d'inclure une phase manuelle basee sur la documentation que tu auras lu.