> 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.
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.
> 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
- 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.
> 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.
[^] # Re: GPL
Posté par Philippe F (site web personnel) . En réponse à la dépêche Version 2 de la licence CeCILL. Évalué à 7.
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.
# links ?
Posté par Philippe F (site web personnel) . En réponse au journal conkeror: une extension Mozilla pour les alergiques de la souris. Évalué à 6.
[^] # Re: URL
Posté par Philippe F (site web personnel) . En réponse au journal Lua, ca assure. Évalué à 8.
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.
[^] # 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.
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.
[^] # 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.
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.
[^] # Re: GPL et shareware, en résumé...
Posté par Philippe F (site web personnel) . En réponse au journal Faire du GPL avec du Shareware. Évalué à 2.
- 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.
# autotools ?
Posté par Philippe F (site web personnel) . En réponse au journal X.org et la modularisation. Évalué à 5.
A l'heure ou KDE envisage de se debarasser d'autotools, j'espere qu'ils ont bien reflechi a la chose.
[^] # 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é à 4.
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.
[^] # 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.
> 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.
[^] # 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é à 5.
>>
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.
[^] # 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.