> Ah si t'as l'énorme avantage de pouvoir appeler facilement un API en C depuis n'importe quel langage
Donc l'interet d'avoir Gnome en C, c'est de ne pas programmer en C. Super ! C'est con pour tous les mecs naifs qui ont ecrit des programmes Gnome/Gtk en C. En fait, ils se sont trompes, il fallait qu'ils utilisent plutot un binding.
Je prefere le choix de KDE: pour programmer des bonnes applis, on prend un bon langage. Le C++ offrait et offre toujours beaucoup de possibilites et permettait d'avancer rapidement et proprement dans le developpement d'un bureau de qualite.
Il y avait un petit inconvenient au niveau des bindings mais il faut relativiser : comme le C++ est un langage globalement de bonne qualite, le besoin de binding est beaucoup plus faible (c'est pour ca qu'il n'y a pas d'empoignades sur KDE a propos de C# ou Java. Le C++ satisfait deja une tres grande partie des developpeurs KDE et ils ne ressentent pas autant que Gnome le besoin de passer a un langage plus moderne).
Par ailleurs, malgre cet avantage certain, les bindings de Gtk ont ete certes plus nombreux au depart, mais tres souvent pas maintenu sur le long terme, de qualite inegale, et tres peu ont inclus a la fois les bilbiotheques Gtk et Gnome. L'apparente facilite de generer des bindings en C a ete contrebalancee par la necessite de les generer a la main et donc de les maintenir. L'absence d'infos suffisante dans les .h empechait d'automatiser completement cette tache (cf les problemes cites plus haut) qui ont fait que avoir des bindings a jour sur Gnome a ete une gagure. Il faut attendre gobject pour avoir un truc propre.
Au final, KDE a pondu un systeme de generation de binding qui s'affranchit des problemes du C++ et permet de generer des bindings pour plusieurs langages de facon automatise. Ils ont eu directement la bonne approche.
En choisissant le bon langage des le depart, on a gagne sur les deux tableaux:
- on programme avec KDE dans un langage moderne
- on a une generation de binding automatisee
> Il faut voir aussi qu'à l'époque du choix de C par Gnome le C++ n'était pas vraiment standardisé dans les compilos (je précises dans les compilos)
Pourtant, deja a l'epoque, Qt compilait out-of-the-box sur toutes les architectures majeurs, et tous les compilos majeurs. Donc c'etait peut-etre pas la panacee, mais ca marchait tres bien. C'est sur que un truc comme boost on libsig++ qui utilise les template de facon majeure n'aurait surement pas compile a l'epoque. Ca tombe bien, Qt utilise justement tres peu les template.
Maintenant, qu'on peut se lacher un peu plus au niveau du C++, Qt fournit aussi des trucs sympas, genre :
> en gros faut faire un wrapper C++ intermédiaire qui soit plus friendly
De fait, il y a une couche intermediaire en C qui est generee (il me semble).
> Je ne suis pas sûr qu'une couche intermédiaire soit un gage d'efficacité,
Comment tu peux parler d'efficacite d'une couche intermediaire alors que utilise un langage ou tout le framework objet est genere par macro et ne peux donc pas etre optimise par le compilateur. En C++, tu donnes beaucoup d'info sur tes structures au compilateur, qui peut donc les optimiser en consequence. Avec un wrapper objet en C comme on a en Gtk/Gobject, le compilateur ne peut pas faire ce type d'optimisation parce qu'il ne sait pas ce que c'est qu'un objet.
> il faut refaire cette couche pour tous les langages
Ben non, c'est la meme partout. C'est elle justement qui fournit le coeur de binding. Elle fournit tous les services dont le binding va avoir besoin (introspection, typage dynamique pour certains langages, ...) en C.
> les .h suffisent, aussi bien en c++ qu'en C.
Justement, non. Une partie des informations sur un objet en Gtk est contenu dans les structures qui sont definies dans le .c, pas dans le .h
> Je vois pas pourquoi il ne serait pas de même pour Gnome et ses .h.
Parce que comme l'objet ne fait pas partie de la syntaxe C, il est emule a coup de macros et de struct, qui sont beaucoup plus difficile a parser.
Qui plus est, un certain nombre d'information sont tout simplement perdue dans la syntaxe C. Je pense aux signaux Gtk qui acceptent un argument de type void *
Tu noteras la presence de gpointer callback_data qui est impossible a interpreter pour un outil de binding automatique.
Au contraire, les signaux et slots Qt sont types et peuvent donc etre pris en compte dans une generation automatique.
De meme, les listes Gtk ne sont pas typees. Elles prennent aussi un gpointer pour la partie data donc tu ne sais pas de quoi est faite la liste. En C++, les listes sont faites avec des templates ou le type est explicitement visible.
Tu sais, moi aussi j'adore le C. J'aime bien faire du C pur.
Mais quand je dois faire des objets avec de l'heritage et des methodes virtuelles, ben je choisis un langage objet. C'est etonnant hein ? De meme que si je devais faire de la programmation fonctionnelle, je me tournerai plutot vers un langage fonctionnel.
En toute honnetete, je ne comprends pas comment tu peux a la fois aimer le C et aimer programmer en C avec Gnome. La programmation sous Gnome n'a pour moi rien a voir avec la programmation en C (que j'aime beaucoup, je le reappelle). Quand tu fais des classes, des objets, des methodes virtuelles et de l'heritage et que tu dis que tu programmes en C, tu te mens a toi-meme.
Le C sous Gnome, c'est un mensonge. Tu fais du C++ mais en fait c'est pas du C++. T'as tous les inconvenients de ne pas avoir un langage oriente objet et aucun des avantages du C (langage sobre et efficace).
A noter que la news KDE est datee de 2002. Et oui, 3 ans deja que KDE genere une partie de ses bindings de la meme facon.
Et vous savez pourquoi c'est beaucoup plus facile avec KDE ? Le langage ! En C++, en parsant le .h, tu as 99% de l'info dont tu as besoin. Les pointeurs ou les template ont un type precis (pas comme les void * qui sont utilises par exemple dans les listes gnome), la syntaxe est plutot simple (vous avez deja vu le nombre de declarations necessaire a faire l'equivalent d'un class Toto: public QObject en gnome ?).
Bon, on va encore s'offusquer de ma prise de position extreme pro-KDE mais depuis que j'ai decouvert le logiciel libre, je suis persuade que Gnome a fait une grosse erreur en choisissant un toolkit en C et que KDE a fait un bon choix en choisissant du C++.
Pour repondre a la remarque originale, il faut bien distinguer deux choses:
- le toolkit utilise par anjuta
- les modeles proposes pour faire du dev
Il est evident que anjuta developpe par et pour Gnome utilise a fond les bibliotheques et toutes les possibilites de Gnome.
Il est aussi tout a fait naturel que maitrisant bien Gnome et le developpant pour Gnome, les modeles de projets soient des modeles de projets Gnome.
Mais il ne faut pas y voir la une restriction. Je ne connais pas anjuta mais je serai surpris que l'auteur y aie mis une telle restriction. C'est juste des modeles de projets. Avec le temps et avec les contributions, d'autres modeles seront proposes, qui te permettront de commencer facilement un projet KDE, un projet ncurses, etc.
Si tu prends KDevelop, le concurrent principal, au debut, il n'y avait que des modeles de projets pour KDE ou pour rien du tout. Maintenant, si tu regardes la listes des modeles en C/C++, tu vois qu'il y a beaucoup de KDE, mais pas mal d'autres choses: du ncurses, du gnome, ... http://webcvs.kde.org/kdevelop/languages/cpp/app_templates/(...)
Donc si tu veux des modeles pour d'autres projets que Gnome, a toi de les proposer.
Si tu veux que anjuta ne s'integre pas dans Gnome, c'est completement debile.
> Mais c'est assez risqué d'intégrer des considérations spécifiques à un environnement graphique (IHM) dans le coeur de gestion
En effet, on devrait faire des applis Gnome qui ne dependent pas de Gnome. Comme ca, pas de considerations IHM dans le coeur de gestion.
Pour faire une reponse plus intelligente, Gnome (ou KDE), c'est bien plus qu'une IHM. C'est un modele de boucle d'evenement, des classes de bases, un modele graphique et une IHM. Si tu developpes avec Gnome, tu utilises au strict minimum le modele de la boucle d'evenement et le modele graphique. En general, il n'y a pas de raison de se priver des autres elements.
> On se retrouve dans des situations à la k3b où les gens n'ont les libs qt que pour cette appli.
Et ? Quel probleme cela pose-t-il ? Avoir Qt pour k3b est une bonne raison d'avoir Qt.
> Résultat, une application aussi fondatrice de GTK+ que Gimp est en train de détacher le core de la GUI.
Au contraire, c'est une bonne chose. En separant bien les fonctionnalites de gimp de son interface, on ouvre la possibilite a une nouvelle communaute de contributeur de proposer des nouvelles interfaces. On pourrait donc avoir un gimp en WxWidgets, un gimp en Qt, un gimp en KDE, un gimp en ncurses (j'deconne!).
Honnetement, je trouve que ca ne devrait pas etre le boulot des developpeurs d'applis de developper le toolkit. Gimp a developpe gtk parce qu'il n'y avait rien qui leur convenait. Si un bon equivalent de Gtk avait ete la a l'epoque, gimp l'aurait utilise.
Developper un toolkit et developper une appli sont deux choses differentes. On a pas necessairement les memes objectifs
> Après tout, les spécifications FreeDesktop, la gestion unifiée des messages (Dbus?) me semblent permettre une description du comportement d'une application sans référer à un toolkit.
Tu fais erreur. DBUS, s'il est adopte par KDE et Gnome permet juste d'envoyer des messages a des applications.
On n'a pas a l'heure actuelle de description d'une application complete independante du toolkit. Et tu sais quoi ? C'est une bonne chose. Pour faire une bonne application (ergonomique, fonctionelle, rapide, optimisee), il faut tirer au maximum avantage des possibilites du toolkit.
> Cependant, c'est très récent ce genre de réflexion, et on peut se demander si le port qt de firefox (ou de son rendu, peu importe, je
> souhaiterais qu'on n'ergote pas sur les termes) ne risque pas de souffrir d'une conception trop conditionnée par GTK+.
Ben justement, le rendu ne depend pas de Gtk, ce qui a permis de le porter rapidement en Qt.
Je pense que tu devrais te renseigner plus sur les questions qui te tarabustent, parce que visiblement, tu es peu informe et du dis des betises.
Mon impressino personnelle est que c'est tout a fait inexact.
La tres grande majorite des logiciels libres que je connais sont developpes sont par des etudiants en info, soit par des ingenieurs.
Je peux prendre KDE comme exemple. De tous les developpeur du coeur, il n'y en a aucun qui soit chercheur. La plupart etaient etudiants quand ils ont commence, et sont maintenant ingenieurs. A part l'auteur de KStart et deux ou trois logiciels extremement mineurs, il y a tres peu de chercheurs developpeurs dans les logiciels libres generaux. Apres, sur quelques cas particulier comme des applis de calcul mathematique, on se doute qu'il y a plus de chercheurs qui les developpent qu'autre chose.
De toute facon, c'est une facon d'ecarter le debat. Qui developpe le logiciel libre n'a pas beaucoup d'importance. La question, c'est est-ce qu'on peut les utiliser, et est-ce qu'on peut contribuer.
J'ai lu le jugement et je comprends mieux. Mme Milka Budimir n'a pas de societe du nom de milka. Et les juges ont tenu compte du fait que son site etait initialement mauve.
Pour que ca passe, il aurait fallu que mlika soit le nom (pas le prenom) de mme Budimir, lui donnant une protection legal autour de son droit. Le coup du mauve, c'est vraiment pas de bol. Pareil, si le site avait ete rouge au depart, les juges auraient surement considere qu'il n'y avait pas de confusion possible. Et si elle avait mis un lien au debut de la page principal "ceci n'est pas la pages de chocolats milka mais vous les trouverez ici", il n'y aurait pas non plus eu de confusion.
On tombe dans un cas de "un particulier depose un truc" contre "un nom commercial". C'est le nom commercial qui a gagne parce qu'il avait plus de trucs depose mais a lire le jugement, c'est vraiment un ensemble de details qui ont joue.
Je rappelle que dans un proces "continent" l'epicerie du coin contre "continent" la chaine etablie, c'est continent la chaine qui a perdu et que pendant deux mois, tous les produits continents de la chaine avaient leurs nom raye au marqueur dans les rayonnage. L'epicier du coin doit maintenant etre aux Bahamas.
Donc il ne faut pas sauter directement au "c'est toujours les plus gros et les plus connus qui gagnent".
Internet etant a la fois un espace ou s'epanouissent particuliers et entreprise, c'est difficile a gerer. Notamment, les entreprises protegent mieux leur marque que les particulier, ce qui leur donne plus d'argument lors de proces.
A lire le jugement, c'est vraiment un ensemble de details qui ont joue contre Mme Budimir, et le poid de la societe milka n'ayant ete qu'un des arguments.
Je suis beaucoup plus inquiet de l'affaire tati / kitetoi qui met vraiment en question la liberte d'expression et le droit de mise en garde.
Je ne connais pas les details de cette affaire, mais je suis surpris qu'une societe X puisse prevaloir sur une societe Y alors que Y a depose le nom de domaine et qu'il correspond a une utilisation legitime.
Est-ce que tu sais ce qui a motive la decision du juge ?
Le coup de l'enveloppe soleau est quand meme plus sur. Ca te fait une source exterieure qui garde tes donnees, en plus de toi. Et ca doit etre dans le meme ordre de prix.
Cela dit, en y reflechissant, je crois que ca ne marche que sur du papier. Va falloir imprimer tes paroles et tes arrangements...
Quel est l'interet de diffuser une info sur une faille de securite si aucun fix n'est disponible ? Quand on decouvre une faille, il est quand meme classique d'informer d'abord les devs, de leur laisser un temps raisonnable pour sortir un correctif (une semaine) avant d'en faire grand bruit.
> Ils ont envoyés des corrections aux devs de Konqueror - Khtml
La tu reves. Cf les autres remarques, dont le journal de dirk mueller. Les modifs de Safari ne seront jamais integrees dans Konqueror parce que apple a fait un fork sauvage. Ils respectent la licence LGPL de khtml, mais ils ne jouent pas le jeu en ne cooperant pas du tout avec khtml.
Ces corrections de bugs n'arriveront jamais dans khtml, sauf si un mec de KDE les implemente.
D'un autre cote, comme je le disais plus haut, le fait que le jeu aie pu aller si loin, c'est parce qu'il est tour par tour, ce qui est 100 fois plus simple a gerer.
Mais bon, les graphismes sont la, les caracteristiques des unites, yapuka mettre un moteur de jeu temps reel et une IA temps reel.
Il faudrait trouver une syntaxe qui sois discrete. Surtout que slots: et signals: sont vires a la compilation. Ils ne servent que pour le mocm pour qu'il comprenne de quoi li retourne. Je te suggere de faire un rapport de bug a Trolltech. Le mieux, c'est si tu fais quelques essais pour leur proposer une nouvelle syntaxe. Genre:
class Toto : public QObject {
PSEUDO_TYPE Q_OBJECT; // hey, I look like a variable declaration
/* public slots: */
void activate();
/* signals: */
void activated();
};
Sinon, tu peux probablement "patcher" le moc, ca doit pas etre si complique que ca. Il faut juste trouver la ligne ou il cherche les "signals:" et remplacer ca par autre chose.
> on développe majoritairement avec VisualC++, donc la compilation et le déboggage avec Qt, je sais pas trop ce que ça va donner
Ca se passe tres tres bien. Qt fournit un petit plugin pour Visual qui permet de gerer facilement les moc et les fichiers d'interface graphique (generes par Qt Designer). Ca fait plusieurs annees que je developpe avec Qt + Visual et je n'ai aucun probleme. C'est meme mon environnement favori, a cause l'excellente qualite du debugger de Visual (dommage que gdb soit a des annees lumieres).
> on ne fait pas des applis GPL, donc on est obligé d'inverstir si on veut du Qt.
De fait. Mais si vraiment c'est important pour vous d'avoir des applis multi-plateformes, l'investissement est rentable. Avec Qt, non seulement tu vas vite quand tu developpes, mais en plus, ca marche partout sans aucun effort. Je suis vraiment epoustoufle par la qualite de ce toolkit. A mon avis, si tu cherches une alternative moins cher, tu vas au final perdre du temps dans ton developpement. N'oublies pas que un mois-homme, c'est plusieurs licences Qt.
> Si quelqu'un me dit qu'on peut faire la même chose en utilisant Qt,
Qt ne change rien a ca, c'est une fonctionnalite du compilateur de Microsoft. Comme quoi, c'est pas des manchots quans ils veulent.
> Que se passe-t-il en effet si la version de Qt disponible sous licence propriétaire prend une direction qui ne te convient pas ?
Je ne comprends pas ce qui se cache derriere cette phase. Avec la version commerciale, tu peux utiliser la licence que tu veux pour ton soft, a condition de ne pas exposer l'api Qt. Et tu as les sources, donc si ca evolue pas dans le bon sens, tu as le droit de le faire evoluer toi-meme.
Tu sais, le C++, c'est beaucoup de choses. Il y a au moins 5 a 6 facons completement differentes de programmer en C++. Ca part du mec qui fait du C avec un objet par ci par la pour dire que c'est objet, au mec qui fait de la meta-programmation a coup de template (on peut calculer la suite de fibonacci avec juste une phase de compilation, genial non ?).
Cela dit, je suis d'accord, c'est pas du C++ pur puisqu'on invente un nouveau paradigme de programmation. Mais les template aussi ont apporte un nouveau paradigme de programmation. Je prefere les signaux et slots, parce que au moins, je comprends comment ca marche (j'ai jamais rien compris aux template), et que ca me sert au quotidien.
Pour ce qui est du modeling, je suis d'accord que les "slots:" foutent la merde dans les classes. Pour moi, c'est un probleme inherent au C++. Avec d'un cote les macros, de l'autre cote les template, et d'un troisieme cote les pointeurs un peu tordu, on arrive a une syntaxe qui est hyper complexe, ce qui fait qu'il est tres difficile de l'utiliser avec des outils de meta-programmation. Java au contraire, a une syntaxe tres simple et deterministe, ce qui fait qu'on voit fleurir des outils de toute sorte: refactoring, programmation orientee aspect, introspection, etc etc.
J'ai commencé à jouer il y a un mois et je suis époustouflé par la qualité du jeu. Contrairement à 95% des jeux libres, celui-ci est extrèmement soigné.
Il y a un tutorial graphique (et non pas un bout de pdf dans un coin) qui vous apprend pas à pas les techniques de jeu et les choix à faire.
Apres, c'est un plaisir. Les campagnes ne sont pas faciles, il faut souvent repartir en arriere pour renforcer ses unites pour le scenario suivant.
Il y a de la musique de bonne qualité, des animations sympa quand les unités attaquent où de défendent. Et ca marche sous windows donc vous pouvez le montrer à vos potes windowsiens sceptiques.
Dans l'historique, l'auteur explique que si il est allé si loin, c'est parce qu'il s'était fixé un but modeste au départ, avec un jeu très simple. A méditer !
> QT aura toujours un cran d'avance, mais ça se paye ! (du moins si on développe des applis commerciales)
Justement, dans un contexte commercial, si tu fais gagner un mois de dev a ton developpeur, tu as paye 2 fois ta licence Qt. Je pense honnetement que Qt fait gagner plus que ca sur un projet de quelques mois, et que donc son prix se justifie largement. Dans un contexte commercial !
Qt sous KDE utilise les styles KDE et semble tres natif. Sous Windows XP, il utilise le style windows XP et est natif aussi. Sous MacOsX aussi.
Quand les API de style natif ne sont pas disponibles, il y a des emulations de tres tres bonne qualite, capables de blouser tout le monde sauf le type qui developpe depuis 10 ans sur ladite plateforme.
> C'est vrai pour n'importe quel logiciel multiplateforme.
J'ai fait pas mal de portages Qt windows / linux dans les deux sens. Zero probleme, zero bug, en dehors des conneries du compilateur de Visual.
<< C'est vrai qu'à l'usage wxWidgets oblige à un peu de debug pénible pour lisser les différences de comportement Windows/Linux/..., mais c'est plutôt dû à un très gros manque de finition de wx
>>
S'il y a un manque de finition, c'est justement parce qu'il faut un travail tres important pour arriver a un bon resultat. Avec wxWidget, plus le toolkit progresse, plus il y a de boulot puisqu'il faut valider tous les widgets et tous les changements sur toutes les plateformes (etant donne que leur implementation varie de plateforme en plateforme).
Sous Qt, a l'inverse, plus le toolkit progresse, moins il y a de boulot. Une fois que tu as porte QWidget, tu as porte Qt sur une autre plateforme. Ensuite, tous le reste de Qt ne depend que de fonctionnalites Qt et n'expose pas de bug specifique plateforme.
En plus, avec les plateformes recentes comme KDE, Windows XP ou MacOS X, l'api de style des widgets est accessible et Qt prend donc une apparence native, exactement comme avec le toolkit de la plateforme.
> > vouloir faire ça c'est s'imposer un surcroit de travail important
> Pour qui ? Pour les développeurs de wxWidgets, peut-être, mais ils l'ont choisi et tant mieux pour nous ;)
Les utilisateurs payent puisque plus de travail pour les developpeurs, ca veut dire plus de risque de prendre du retard, d'intreoduire des bugs, etc etc.
Pour prendre une analogie, avant les bindings gtk etaient generes "a la main". C'etait l'horreur puisque ceux-ci avaient tous du retard sur Gtk ou Gnome, etaient super difficile a maintenir, etc etc. Maintenant, il y a un moteur de generation de binding pour Gtk et il suffit de faire le travail une fois sur le moteur pour recuperer des bindings pour la derniere version de Gtk dans une plethore de langage. C'est beaucoup plus efficace et de meilleure qualite.
Tu me rassures. Enfin, la documentation que j'ai survole n'en parle pas trop. La FAQ parle de "ne mettez pas les coordonnees de vos widgets en durs, utilisez la methode compliquee" et c'est tout.
> Gérer des signaux sans utiliser des templates évolués (façon gtkmm) ou un précompilateur (façon QT) ca relève de la gageur.
Dans la mesure ou wxWidget ne se gene pas pour utiliser des macros pour ses evenments, je trouve l'argument un peu faible.
> Il faut sans doute rappeller que wxWidgets à été développé avec l'idée de la portabilité de plateformes mais aussi de compilateurs.
Qt aussi. Et ils ont tres bien reussi.
Ce que je retiens, c'est qu'on peut utiliser des outils exterieurs pour rendre le style de programmation un peu plus moderne mais que ca reste un melange de deux styles, pas toujours tres agreable a manipuler.
Ca plus les problemes specifiques plateformes, ca fait quand meme un bagage assez charge pour un toolkit "moderne".
Je continue a preferer Qt ou tout est super bien integre et on a pas l'impression de remonter dans le temps quand on developpe.
> Pour développer en C++ propre, utiliser gcc 2.95 serait une erreur.
Je dirai meme, pour developpe en C++ standard, utiliser n'importe quel compilateur est une erreur. En effet, il n'existe a ce jour aucun compilateur qui supporte completement et correctement l'integratlite de la norme C++.
Est-ce que ca se fait dans la pratique ? J'imagine quand meme que les mecs qui font du wxWidgets sont intoxices de notions evenementielles et ont du mal a voir l'interet des signaux / slots.
[^] # Re: Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 2.
Donc l'interet d'avoir Gnome en C, c'est de ne pas programmer en C. Super ! C'est con pour tous les mecs naifs qui ont ecrit des programmes Gnome/Gtk en C. En fait, ils se sont trompes, il fallait qu'ils utilisent plutot un binding.
Je prefere le choix de KDE: pour programmer des bonnes applis, on prend un bon langage. Le C++ offrait et offre toujours beaucoup de possibilites et permettait d'avancer rapidement et proprement dans le developpement d'un bureau de qualite.
Il y avait un petit inconvenient au niveau des bindings mais il faut relativiser : comme le C++ est un langage globalement de bonne qualite, le besoin de binding est beaucoup plus faible (c'est pour ca qu'il n'y a pas d'empoignades sur KDE a propos de C# ou Java. Le C++ satisfait deja une tres grande partie des developpeurs KDE et ils ne ressentent pas autant que Gnome le besoin de passer a un langage plus moderne).
Par ailleurs, malgre cet avantage certain, les bindings de Gtk ont ete certes plus nombreux au depart, mais tres souvent pas maintenu sur le long terme, de qualite inegale, et tres peu ont inclus a la fois les bilbiotheques Gtk et Gnome. L'apparente facilite de generer des bindings en C a ete contrebalancee par la necessite de les generer a la main et donc de les maintenir. L'absence d'infos suffisante dans les .h empechait d'automatiser completement cette tache (cf les problemes cites plus haut) qui ont fait que avoir des bindings a jour sur Gnome a ete une gagure. Il faut attendre gobject pour avoir un truc propre.
Au final, KDE a pondu un systeme de generation de binding qui s'affranchit des problemes du C++ et permet de generer des bindings pour plusieurs langages de facon automatise. Ils ont eu directement la bonne approche.
En choisissant le bon langage des le depart, on a gagne sur les deux tableaux:
- on programme avec KDE dans un langage moderne
- on a une generation de binding automatisee
> Il faut voir aussi qu'à l'époque du choix de C par Gnome le C++ n'était pas vraiment standardisé dans les compilos (je précises dans les compilos)
Pourtant, deja a l'epoque, Qt compilait out-of-the-box sur toutes les architectures majeurs, et tous les compilos majeurs. Donc c'etait peut-etre pas la panacee, mais ca marchait tres bien. C'est sur que un truc comme boost on libsig++ qui utilise les template de facon majeure n'aurait surement pas compile a l'epoque. Ca tombe bien, Qt utilise justement tres peu les template.
Maintenant, qu'on peut se lacher un peu plus au niveau du C++, Qt fournit aussi des trucs sympas, genre :
[^] # Re: Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 3.
De fait, il y a une couche intermediaire en C qui est generee (il me semble).
> Je ne suis pas sûr qu'une couche intermédiaire soit un gage d'efficacité,
Comment tu peux parler d'efficacite d'une couche intermediaire alors que utilise un langage ou tout le framework objet est genere par macro et ne peux donc pas etre optimise par le compilateur. En C++, tu donnes beaucoup d'info sur tes structures au compilateur, qui peut donc les optimiser en consequence. Avec un wrapper objet en C comme on a en Gtk/Gobject, le compilateur ne peut pas faire ce type d'optimisation parce qu'il ne sait pas ce que c'est qu'un objet.
> il faut refaire cette couche pour tous les langages
Ben non, c'est la meme partout. C'est elle justement qui fournit le coeur de binding. Elle fournit tous les services dont le binding va avoir besoin (introspection, typage dynamique pour certains langages, ...) en C.
> les .h suffisent, aussi bien en c++ qu'en C.
Justement, non. Une partie des informations sur un objet en Gtk est contenu dans les structures qui sont definies dans le .c, pas dans le .h
[^] # Re: Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 2.
Parce que comme l'objet ne fait pas partie de la syntaxe C, il est emule a coup de macros et de struct, qui sont beaucoup plus difficile a parser.
Qui plus est, un certain nombre d'information sont tout simplement perdue dans la syntaxe C. Je pense aux signaux Gtk qui acceptent un argument de type void *
cf
http://www.gtk.org/tutorial/sec-theoryofsignalsandcallbacks.html(...)
Tu noteras la presence de gpointer callback_data qui est impossible a interpreter pour un outil de binding automatique.
Au contraire, les signaux et slots Qt sont types et peuvent donc etre pris en compte dans une generation automatique.
De meme, les listes Gtk ne sont pas typees. Elles prennent aussi un gpointer pour la partie data donc tu ne sais pas de quoi est faite la liste. En C++, les listes sont faites avec des templates ou le type est explicitement visible.
[^] # Re: Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 9.
Mais quand je dois faire des objets avec de l'heritage et des methodes virtuelles, ben je choisis un langage objet. C'est etonnant hein ? De meme que si je devais faire de la programmation fonctionnelle, je me tournerai plutot vers un langage fonctionnel.
En toute honnetete, je ne comprends pas comment tu peux a la fois aimer le C et aimer programmer en C avec Gnome. La programmation sous Gnome n'a pour moi rien a voir avec la programmation en C (que j'aime beaucoup, je le reappelle). Quand tu fais des classes, des objets, des methodes virtuelles et de l'heritage et que tu dis que tu programmes en C, tu te mens a toi-meme.
Le C sous Gnome, c'est un mensonge. Tu fais du C++ mais en fait c'est pas du C++. T'as tous les inconvenients de ne pas avoir un langage oriente objet et aucun des avantages du C (langage sobre et efficace).
# Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 10.
Finalement, gnome ne fait que suivre la voie de KDE:
http://dot.kde.org/1032279318/#1032280045(...)
A noter que la news KDE est datee de 2002. Et oui, 3 ans deja que KDE genere une partie de ses bindings de la meme facon.
Et vous savez pourquoi c'est beaucoup plus facile avec KDE ? Le langage ! En C++, en parsant le .h, tu as 99% de l'info dont tu as besoin. Les pointeurs ou les template ont un type precis (pas comme les void * qui sont utilises par exemple dans les listes gnome), la syntaxe est plutot simple (vous avez deja vu le nombre de declarations necessaire a faire l'equivalent d'un class Toto: public QObject en gnome ?).
Bon, on va encore s'offusquer de ma prise de position extreme pro-KDE mais depuis que j'ai decouvert le logiciel libre, je suis persuade que Gnome a fait une grosse erreur en choisissant un toolkit en C et que KDE a fait un bon choix en choisissant du C++.
Ceci n'est qu'un exemple de plus.
[^] # Re: pourquoi spécifiquement ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Anjuta 2.0.0. Évalué à 6.
- le toolkit utilise par anjuta
- les modeles proposes pour faire du dev
Il est evident que anjuta developpe par et pour Gnome utilise a fond les bibliotheques et toutes les possibilites de Gnome.
Il est aussi tout a fait naturel que maitrisant bien Gnome et le developpant pour Gnome, les modeles de projets soient des modeles de projets Gnome.
Mais il ne faut pas y voir la une restriction. Je ne connais pas anjuta mais je serai surpris que l'auteur y aie mis une telle restriction. C'est juste des modeles de projets. Avec le temps et avec les contributions, d'autres modeles seront proposes, qui te permettront de commencer facilement un projet KDE, un projet ncurses, etc.
Si tu prends KDevelop, le concurrent principal, au debut, il n'y avait que des modeles de projets pour KDE ou pour rien du tout. Maintenant, si tu regardes la listes des modeles en C/C++, tu vois qu'il y a beaucoup de KDE, mais pas mal d'autres choses: du ncurses, du gnome, ...
http://webcvs.kde.org/kdevelop/languages/cpp/app_templates/(...)
Donc si tu veux des modeles pour d'autres projets que Gnome, a toi de les proposer.
Si tu veux que anjuta ne s'integre pas dans Gnome, c'est completement debile.
> Mais c'est assez risqué d'intégrer des considérations spécifiques à un environnement graphique (IHM) dans le coeur de gestion
En effet, on devrait faire des applis Gnome qui ne dependent pas de Gnome. Comme ca, pas de considerations IHM dans le coeur de gestion.
Pour faire une reponse plus intelligente, Gnome (ou KDE), c'est bien plus qu'une IHM. C'est un modele de boucle d'evenement, des classes de bases, un modele graphique et une IHM. Si tu developpes avec Gnome, tu utilises au strict minimum le modele de la boucle d'evenement et le modele graphique. En general, il n'y a pas de raison de se priver des autres elements.
> On se retrouve dans des situations à la k3b où les gens n'ont les libs qt que pour cette appli.
Et ? Quel probleme cela pose-t-il ? Avoir Qt pour k3b est une bonne raison d'avoir Qt.
> Résultat, une application aussi fondatrice de GTK+ que Gimp est en train de détacher le core de la GUI.
Au contraire, c'est une bonne chose. En separant bien les fonctionnalites de gimp de son interface, on ouvre la possibilite a une nouvelle communaute de contributeur de proposer des nouvelles interfaces. On pourrait donc avoir un gimp en WxWidgets, un gimp en Qt, un gimp en KDE, un gimp en ncurses (j'deconne!).
Honnetement, je trouve que ca ne devrait pas etre le boulot des developpeurs d'applis de developper le toolkit. Gimp a developpe gtk parce qu'il n'y avait rien qui leur convenait. Si un bon equivalent de Gtk avait ete la a l'epoque, gimp l'aurait utilise.
Developper un toolkit et developper une appli sont deux choses differentes. On a pas necessairement les memes objectifs
> Après tout, les spécifications FreeDesktop, la gestion unifiée des messages (Dbus?) me semblent permettre une description du comportement d'une application sans référer à un toolkit.
Tu fais erreur. DBUS, s'il est adopte par KDE et Gnome permet juste d'envoyer des messages a des applications.
On n'a pas a l'heure actuelle de description d'une application complete independante du toolkit. Et tu sais quoi ? C'est une bonne chose. Pour faire une bonne application (ergonomique, fonctionelle, rapide, optimisee), il faut tirer au maximum avantage des possibilites du toolkit.
> Cependant, c'est très récent ce genre de réflexion, et on peut se demander si le port qt de firefox (ou de son rendu, peu importe, je
> souhaiterais qu'on n'ergote pas sur les termes) ne risque pas de souffrir d'une conception trop conditionnée par GTK+.
Ben justement, le rendu ne depend pas de Gtk, ce qui a permis de le porter rapidement en Qt.
Je pense que tu devrais te renseigner plus sur les questions qui te tarabustent, parce que visiblement, tu es peu informe et du dis des betises.
[^] # Re: Tout ce qui est à toi est à moi, tout ce qui est à moi est à moi.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Une émission de télé en direct sur le libre. Évalué à 3.
La tres grande majorite des logiciels libres que je connais sont developpes sont par des etudiants en info, soit par des ingenieurs.
Je peux prendre KDE comme exemple. De tous les developpeur du coeur, il n'y en a aucun qui soit chercheur. La plupart etaient etudiants quand ils ont commence, et sont maintenant ingenieurs. A part l'auteur de KStart et deux ou trois logiciels extremement mineurs, il y a tres peu de chercheurs developpeurs dans les logiciels libres generaux. Apres, sur quelques cas particulier comme des applis de calcul mathematique, on se doute qu'il y a plus de chercheurs qui les developpent qu'autre chose.
De toute facon, c'est une facon d'ecarter le debat. Qui developpe le logiciel libre n'a pas beaucoup d'importance. La question, c'est est-ce qu'on peut les utiliser, et est-ce qu'on peut contribuer.
[^] # Re: Etonnant
Posté par Philippe F (site web personnel) . En réponse au journal Des nouvelles de l'affaire Milka. Évalué à 9.
Pour que ca passe, il aurait fallu que mlika soit le nom (pas le prenom) de mme Budimir, lui donnant une protection legal autour de son droit. Le coup du mauve, c'est vraiment pas de bol. Pareil, si le site avait ete rouge au depart, les juges auraient surement considere qu'il n'y avait pas de confusion possible. Et si elle avait mis un lien au debut de la page principal "ceci n'est pas la pages de chocolats milka mais vous les trouverez ici", il n'y aurait pas non plus eu de confusion.
On tombe dans un cas de "un particulier depose un truc" contre "un nom commercial". C'est le nom commercial qui a gagne parce qu'il avait plus de trucs depose mais a lire le jugement, c'est vraiment un ensemble de details qui ont joue.
Je rappelle que dans un proces "continent" l'epicerie du coin contre "continent" la chaine etablie, c'est continent la chaine qui a perdu et que pendant deux mois, tous les produits continents de la chaine avaient leurs nom raye au marqueur dans les rayonnage. L'epicier du coin doit maintenant etre aux Bahamas.
Donc il ne faut pas sauter directement au "c'est toujours les plus gros et les plus connus qui gagnent".
Internet etant a la fois un espace ou s'epanouissent particuliers et entreprise, c'est difficile a gerer. Notamment, les entreprises protegent mieux leur marque que les particulier, ce qui leur donne plus d'argument lors de proces.
A lire le jugement, c'est vraiment un ensemble de details qui ont joue contre Mme Budimir, et le poid de la societe milka n'ayant ete qu'un des arguments.
Je suis beaucoup plus inquiet de l'affaire tati / kitetoi qui met vraiment en question la liberte d'expression et le droit de mise en garde.
# Etonnant
Posté par Philippe F (site web personnel) . En réponse au journal Des nouvelles de l'affaire Milka. Évalué à 3.
Est-ce que tu sais ce qui a motive la decision du juge ?
[^] # Re: Qqn aurai un générateur automatique de titre de commentaire ?
Posté par Philippe F (site web personnel) . En réponse au journal un site pour le prior art. Évalué à 2.
Cela dit, en y reflechissant, je crois que ca ne marche que sur du papier. Va falloir imprimer tes paroles et tes arrangements...
# Aucun fix disponible ?
Posté par Philippe F (site web personnel) . En réponse au journal Vulnérabilité critique dans Mozilla Firefox,. Évalué à 2.
[^] # Re: Pas encore ca avec Konqueror
Posté par Philippe F (site web personnel) . En réponse à la dépêche David Hyatt fait passer le test Acid2 à Safari et contribue à Konqueror. Évalué à 8.
La tu reves. Cf les autres remarques, dont le journal de dirk mueller. Les modifs de Safari ne seront jamais integrees dans Konqueror parce que apple a fait un fork sauvage. Ils respectent la licence LGPL de khtml, mais ils ne jouent pas le jeu en ne cooperant pas du tout avec khtml.
Ces corrections de bugs n'arriveront jamais dans khtml, sauf si un mec de KDE les implemente.
Tu peux ecrire a apple si tu n'es pas content.
[^] # Re: trop addictif !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Wesnoth 0.9 est sorti. Évalué à 2.
Mais bon, les graphismes sont la, les caracteristiques des unites, yapuka mettre un moteur de jeu temps reel et une IA temps reel.
[^] # Re: Je me marre
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 2.6 est sorti. Évalué à 2.
Il faudrait trouver une syntaxe qui sois discrete. Surtout que slots: et signals: sont vires a la compilation. Ils ne servent que pour le mocm pour qu'il comprenne de quoi li retourne. Je te suggere de faire un rapport de bug a Trolltech. Le mieux, c'est si tu fais quelques essais pour leur proposer une nouvelle syntaxe. Genre:
class Toto : public QObject {
PSEUDO_TYPE Q_OBJECT; // hey, I look like a variable declaration
/* public slots: */
void activate();
/* signals: */
void activated();
};
Sinon, tu peux probablement "patcher" le moc, ca doit pas etre si complique que ca. Il faut juste trouver la ligne ou il cherche les "signals:" et remplacer ca par autre chose.
[^] # Re: Mouai ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 2.6 est sorti. Évalué à 4.
Ca se passe tres tres bien. Qt fournit un petit plugin pour Visual qui permet de gerer facilement les moc et les fichiers d'interface graphique (generes par Qt Designer). Ca fait plusieurs annees que je developpe avec Qt + Visual et je n'ai aucun probleme. C'est meme mon environnement favori, a cause l'excellente qualite du debugger de Visual (dommage que gdb soit a des annees lumieres).
> on ne fait pas des applis GPL, donc on est obligé d'inverstir si on veut du Qt.
De fait. Mais si vraiment c'est important pour vous d'avoir des applis multi-plateformes, l'investissement est rentable. Avec Qt, non seulement tu vas vite quand tu developpes, mais en plus, ca marche partout sans aucun effort. Je suis vraiment epoustoufle par la qualite de ce toolkit. A mon avis, si tu cherches une alternative moins cher, tu vas au final perdre du temps dans ton developpement. N'oublies pas que un mois-homme, c'est plusieurs licences Qt.
> Si quelqu'un me dit qu'on peut faire la même chose en utilisant Qt,
Qt ne change rien a ca, c'est une fonctionnalite du compilateur de Microsoft. Comme quoi, c'est pas des manchots quans ils veulent.
[^] # Re: Et FOX-toolkit ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 2.6 est sorti. Évalué à 2.
Je ne comprends pas ce qui se cache derriere cette phase. Avec la version commerciale, tu peux utiliser la licence que tu veux pour ton soft, a condition de ne pas exposer l'api Qt. Et tu as les sources, donc si ca evolue pas dans le bon sens, tu as le droit de le faire evoluer toi-meme.
Ton independance reste garantie.
[^] # Re: Je me marre
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 2.6 est sorti. Évalué à 1.
Tu sais, le C++, c'est beaucoup de choses. Il y a au moins 5 a 6 facons completement differentes de programmer en C++. Ca part du mec qui fait du C avec un objet par ci par la pour dire que c'est objet, au mec qui fait de la meta-programmation a coup de template (on peut calculer la suite de fibonacci avec juste une phase de compilation, genial non ?).
Cela dit, je suis d'accord, c'est pas du C++ pur puisqu'on invente un nouveau paradigme de programmation. Mais les template aussi ont apporte un nouveau paradigme de programmation. Je prefere les signaux et slots, parce que au moins, je comprends comment ca marche (j'ai jamais rien compris aux template), et que ca me sert au quotidien.
Pour ce qui est du modeling, je suis d'accord que les "slots:" foutent la merde dans les classes. Pour moi, c'est un probleme inherent au C++. Avec d'un cote les macros, de l'autre cote les template, et d'un troisieme cote les pointeurs un peu tordu, on arrive a une syntaxe qui est hyper complexe, ce qui fait qu'il est tres difficile de l'utiliser avec des outils de meta-programmation. Java au contraire, a une syntaxe tres simple et deterministe, ce qui fait qu'on voit fleurir des outils de toute sorte: refactoring, programmation orientee aspect, introspection, etc etc.
# Fantastique
Posté par Philippe F (site web personnel) . En réponse à la dépêche Wesnoth 0.9 est sorti. Évalué à 10.
Il y a un tutorial graphique (et non pas un bout de pdf dans un coin) qui vous apprend pas à pas les techniques de jeu et les choix à faire.
Apres, c'est un plaisir. Les campagnes ne sont pas faciles, il faut souvent repartir en arriere pour renforcer ses unites pour le scenario suivant.
Il y a de la musique de bonne qualité, des animations sympa quand les unités attaquent où de défendent. Et ca marche sous windows donc vous pouvez le montrer à vos potes windowsiens sceptiques.
Dans l'historique, l'auteur explique que si il est allé si loin, c'est parce qu'il s'était fixé un but modeste au départ, avec un jeu très simple. A méditer !
[^] # Re: Et FOX-toolkit ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 2.6 est sorti. Évalué à 2.
Justement, dans un contexte commercial, si tu fais gagner un mois de dev a ton developpeur, tu as paye 2 fois ta licence Qt. Je pense honnetement que Qt fait gagner plus que ca sur un projet de quelques mois, et que donc son prix se justifie largement. Dans un contexte commercial !
[^] # Re: Mouai ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 2.6 est sorti. Évalué à 2.
Quand les API de style natif ne sont pas disponibles, il y a des emulations de tres tres bonne qualite, capables de blouser tout le monde sauf le type qui developpe depuis 10 ans sur ladite plateforme.
[^] # Re: Mouai ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 2.6 est sorti. Évalué à 4.
J'ai fait pas mal de portages Qt windows / linux dans les deux sens. Zero probleme, zero bug, en dehors des conneries du compilateur de Visual.
<< C'est vrai qu'à l'usage wxWidgets oblige à un peu de debug pénible pour lisser les différences de comportement Windows/Linux/..., mais c'est plutôt dû à un très gros manque de finition de wx
>>
S'il y a un manque de finition, c'est justement parce qu'il faut un travail tres important pour arriver a un bon resultat. Avec wxWidget, plus le toolkit progresse, plus il y a de boulot puisqu'il faut valider tous les widgets et tous les changements sur toutes les plateformes (etant donne que leur implementation varie de plateforme en plateforme).
Sous Qt, a l'inverse, plus le toolkit progresse, moins il y a de boulot. Une fois que tu as porte QWidget, tu as porte Qt sur une autre plateforme. Ensuite, tous le reste de Qt ne depend que de fonctionnalites Qt et n'expose pas de bug specifique plateforme.
En plus, avec les plateformes recentes comme KDE, Windows XP ou MacOS X, l'api de style des widgets est accessible et Qt prend donc une apparence native, exactement comme avec le toolkit de la plateforme.
> > vouloir faire ça c'est s'imposer un surcroit de travail important
> Pour qui ? Pour les développeurs de wxWidgets, peut-être, mais ils l'ont choisi et tant mieux pour nous ;)
Les utilisateurs payent puisque plus de travail pour les developpeurs, ca veut dire plus de risque de prendre du retard, d'intreoduire des bugs, etc etc.
Pour prendre une analogie, avant les bindings gtk etaient generes "a la main". C'etait l'horreur puisque ceux-ci avaient tous du retard sur Gtk ou Gnome, etaient super difficile a maintenir, etc etc. Maintenant, il y a un moteur de generation de binding pour Gtk et il suffit de faire le travail une fois sur le moteur pour recuperer des bindings pour la derniere version de Gtk dans une plethore de langage. C'est beaucoup plus efficace et de meilleure qualite.
[^] # Re: Je me marre
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 2.6 est sorti. Évalué à 3.
[^] # Re: Je me marre
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 2.6 est sorti. Évalué à 3.
Dans la mesure ou wxWidget ne se gene pas pour utiliser des macros pour ses evenments, je trouve l'argument un peu faible.
> Il faut sans doute rappeller que wxWidgets à été développé avec l'idée de la portabilité de plateformes mais aussi de compilateurs.
Qt aussi. Et ils ont tres bien reussi.
Ce que je retiens, c'est qu'on peut utiliser des outils exterieurs pour rendre le style de programmation un peu plus moderne mais que ca reste un melange de deux styles, pas toujours tres agreable a manipuler.
Ca plus les problemes specifiques plateformes, ca fait quand meme un bagage assez charge pour un toolkit "moderne".
Je continue a preferer Qt ou tout est super bien integre et on a pas l'impression de remonter dans le temps quand on developpe.
[^] # Re: À quand son utilisation partout ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 4.0. Évalué à 6.
Je dirai meme, pour developpe en C++ standard, utiliser n'importe quel compilateur est une erreur. En effet, il n'existe a ce jour aucun compilateur qui supporte completement et correctement l'integratlite de la norme C++.
Du coup, on se demande a quoi sert cette norme.
[^] # Re: Je me marre
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 2.6 est sorti. Évalué à 2.
Est-ce que ca se fait dans la pratique ? J'imagine quand meme que les mecs qui font du wxWidgets sont intoxices de notions evenementielles et ont du mal a voir l'interet des signaux / slots.