Honnetement, au lieu de sauter sur le troll proprio/libre, vous devriez reflechir a la facon d'augmenter la qualite des logiciels libres.
Ce que je partage avec l'auteur de cette news comme point de vue, c'est que les tests unitaires ne sont pas assez utilise en logiciel libre. C'est un tort car ca permet de faire evoluer tres rapidement l'architecture d'un logiciel tout en conservant sa qualite. Si je prends une appli comme grisbi, il y a eu des versions completement inutilisables tellement elles etaient buggees. Pourtant, c'est pas dur d'ecrire des tests unitaires pour les fonctionnalites qui posaient probleme.
Depuis que je suis devenu un integriste du test unitaire, je constate que j'ai beaucoup moins de bugs sur mes projets et qu'ils sont beaucoup plus faciles a faire evoluer. Constation corroboree par d'autres convertis du test unitaire.
Alors le test unitaire, mangez-en. On peut en faire en C (cunit), en C++ (cppunit), en pyton (unittest), en java (junit, easymock), et C#, en ruby et en tout ce que vous voulez. L'important est d'avoir une suite de test automatisee.
Le contre-argument classique est "mais on ne peut pas tester cette partie-la". Avec un peu d'astuce, on peut tout tester mais il faut s'en donner les moyens. Par exemple, j'ai peu tester un protocole de communication radio ou il fallait simuler des conditions radio anormales. Je travail aussi sur du code embarque ou il faut tester le comportement d'un programme compile avec de l'overlay (pas de notion de fonctionr re-entrante, les variables locales ne sont pas sur la piles mais a des emplacements fixes). Ca aussi, on a put tester sans probleme a condition de reflechir a la facon d'aborder le probleme.
Ce qui est genial, c'est qu'une fois que les briques de bases ont beaucoup de tests unitaires, c'est tres tres facile de faire des tests fonctionnels de tres haut niveau, en assemblant des briques de tests unitaires.
Par exemple, une fois que j'ai eu mon protocole de communication debugge, j'ai pu teste l'ensemble de mon programme avec introdution de conditions radio anormales et autres petits problemes. J"etais doublement confiant dans sa qualite.
Moi j'ai des contre-exemples. Par exemple, depuis 2 ans, il y a un bug avec patch attache sur kmail pour utiliser le composant editeur de KDE au lieu d'utiliser systematiquement l'editeur de kmail. Ca nous permettrait d'utiliser yzis ou vi dans kmail.
Bah, les developpeurs s'en foutent. Pourtant le bugs a pas mal de votes, et j'ai rencontre plein de gens interesses par la fonctionnalite.
Au final, si personne ne veux corriger un probleme, il ne sera pas corrige. Le developpeur ne considere que ce n'est pas important et puis voila.
> Entretenir la confusion, c'est propager l'idee que le libre veut dire gratuit,et forcement gratuit. Malheureusement, c'est souvent l'idee que le grand public a du libre.
Oui, bien sur. Je sais que tout le monde ici est persuade que c'est le cas mais quand on regarde les cas concrets on se marre.
Combien de boite font du libre commercial ? Disons MySql, Trolltech, Mandrake, Red Hat, Suse pour les tres gros. En cherchant parmi les petits, on doit arriver a une 20aine ou une 30aine.
A cote de ca, combien de logiciels libres ? Tu ne sens pas comme un decalage ?
Combien de gens savent que quelques produits de TheKompany sont GPL mais dont les sources ne sont pas distribuees ? Dans ce cas, ces softs sont des bides, les gens ont hurle parce que ce n'etait pas gratuit mais GPL et personne n'a jamais contribue.
J'ai cree avec succes deux entreprises et ca fait aussi pas mal d'annees que je fais du logiciel libre. Je suis intimement persuade que faire de l'argent avec du libre reste extremement difficile et ne peut se faire quand des conditions tres particulieres sont reunies.
Le commercial + libre reste une exception exceptionelle, et j'en suis desole mais c'est comme ca. Dans mes boites on fait entre 100% et 95% de logiciel proprio et c'est ce qui nous permet de vivre.
> Les développeurs d'applications GPL seraient bien marrons si Trolltech décidait de passer les prochaines versions de QT en non libre !
Ben non, Qt passerai automatiquement en licence BSD. cf commentaire plus bas et cf la Free-Qt Foundation.
Gtk est la, donc c'est un peu bete de se dire qu'on ne doit plus l'utiliser. Cela dit, je reste persuade qu'ecrire un toolkit graphique en C est une anerie et fait perdre un temps monstreux en dev aux developpeurs.
Si MDI et consorts poussent d'autres langage de programmation (mono, java, python, ...) c'est bien parce qu'il semble que le C soit un peu depasse.
Ca me faisait marrer de lire le blog de MDI qui etait epate de la vitesse avec laquelle ils developpaient en C# + gnome. Et oui, bienvenu de le monde de l'objet, du polymorphisme, des garbage collector, des constructeurs et des destructeurs et de l'heritage.
Si vous voulez vous marrer un jour, regardez la quantite de code Gtk qu'il faut pour ecrire l'equivalent:
class MyWidget: public QWidget
{
public:
MyWidget( QWidget * p) : QWidget(p) {}
public slots:
void my_slot(int p1, int p2, int p3);
};
D'apres mes souvenirs (en gtk1), ca tape dans les 50 lignes de code, dont la moitie compose de macro sur des structures sans aucune verification de type.
> Trolltech fait l'amalgame entre "commecial" et "proprietaire"
Mouai. Prenons le nombre d'applis open source commerciales et divisons le par le nombre d'appli open source benevoles. Maintenant, faisons la meme operation avec le nombre d'appli open source commerciale que nous divisons par le nombre d'appli close source commerciales.
Je serai surpris qu'un seul de ces chiffres depasse les 0.01% . Certe, Trolltech fait un amalgame, mais il peut se defendre par les chiffres.
> Concernant la gestion des evenements (cf. lien) Fox offre plus de souplesse (mais moins que Gnustep & co : Aie un troll est laché) pour des langages comme python
Mouai. Je code tous les jours en PyQt (c'est mon boulot) et je n'ai pas eu la sensation de manquer de souplesse, au contraire. Le systeme signal/slot porte a python est beaucoup plus souple que celui du C++ puisque n'importe quelle methode ou fonction python peut servir de slot (callback).
<< b) Si tu savais utiliser CreateProcess et avais la la doc de cet API, tu saurais que nombre de ces arguments peuvent etre a NULL et qu'au final c'est pas plus complique a utiliser qu'un API equivalent sur Linux
>>
Desole, mais meme si tous les arguments sont a NULL, l'api reste plus compliquee. C'est un probleme de l'api windows que tu ne peux pas nier.
Sous qt, je peux lancer un processus sans consuler la doc. Sous windows, je dois la relire trois fois pour etre sur que j'ai pas mis un NULL au mauvais endroit.
<<c) CreateProcess c'est un des nombreux APIs te permettant de lancer des processus, t'es libre d'utiliser d'autres APIs qui te permettent de faire des choses plus simples, plus simplement. >>
Ah ouai ? Et tu peux me dire ou on trouve cette api miracle ? Parce que quand on cherche sur le msdn, on tombe toujours sur CreateProcess.
Faux. Qt >= 3.1 utilise des widgets natifs sous Aqua, windows et KDE. Pour les versions inferieur, c'est aussi le cas, mais pas sur toutes les plateformes.
Enfin, quand je dis widgets natifs, c'est un peu exagere. Ils utilisent l'api de style natif du systeme d'exploitation pour dessiner leurs widgets. Mais normalement, ca ne doit faire aucune difference visuelle.
Quand j'installe gimp sous windows, il me demande si je veux utiliser le style wimp. Je suppose que gtk est donc exactement comme qt, ils utilisent au mieux le style de la plateforme et au pire,un style similaire recode a la main.
euh, j'ai du mal lire. Le hurd etait tres attendu quand Linus a commence Linux. Depuis, plus personne ne l'attend...
Ok, c'est gratuit et ca n'enleve rien au respect que j'ai pour les developpeurs du Hurd. C'est juste que le monde ne s'arrete pas de tourner en attendant leur prochaine version.
Pour des petits patchs, correction de bugs, il est communement accepte que ce n'est pas un "travail derive" et que la licence n'entre pas en compte.
En revanche, tu as raison, si tu veux coder une fonctionnalite qui interesse Trolltech, te devras le faire soit avec une licence type BSD, soit renoncer a ton copyright, soit autoriser aussi la licence commerciale.
Dans la pratique, ce n'est pas un gros probleme pour Trolltech. Comme ils ont des revenus, ils peuvent embaucher une armee de developpeurs super competents et recoder eux-meme ce qu'ils ont envie d'avoir dans Qt. Ca fait une grosse difference par rapport aux projets open source qui ne fonctionnent que par contribution.
Exemple, les qcanvas de Qt ont d'abord ete developpe par Varwick Allison en dehors de Trolltech. Ils ont ete rajoute dans Qt quand il a ete embauche. Autre exemple, QSA, le moteur javascript de Qt a ete code par le mec qui a code le moteur javascript de KDE. Trolltech l'a embauche pour qu'il refasse ce qu'il avait deja fait, mais en mieux (il avait des contraintes differentes).
Pour finir, si tu veux fournir une version de Qt avec des modifs a toi qui ne sont que GPL, tu peux faire un fork ou fournir un patch.
Sinon, contrairement a toi, je trouve leur modele excellent. Grace a leur revenus, ils peuvent payer 80 programmeurs a plein temps pour faire un super boulot sur Qt, et tous les developpeurs Open Source en beneficient. Marier son metier et l'open source, c'est un peu le reve de tous les programmeurs de logiciel libre.
<< Rely only on low-level system facilities. FOX relies only on core system facilities, and does NOT wrap native GUI libraries or toolkits. This has the following benefits: >>
Ben justement, Qt fait la meme chose. Ca c'est une difference avec wxWidget.
Bon, si tu enleves les classes non graphiques de Qt (qui sont super pratiques, plus faciles a utiliser que la STL) et le systeme de signaux/slot qui est une des plus belle reussite de Qt, il ne reste pas grand chose.
J'ai pas essaye, mais tel que tu le decris, fox, c'est qt en moins bien.
Non. Le choix de passer par un pre-processeur apporte plus que juste les signaux et les slots. On gagne les proprietes, de l'introspection et une generation dynamique de slots. Tout ca, tu ne l'as pas par les template.
C'est un sujet debattu et rebattu. Trolltech repond regulierement qu'ils ont envisage le passage en template mais que le moc presente de nombreux avantages techniques qui font qu'ils gardent cette approche.
Tu utilises quoi quand tu n'utilises pas qmake ? Avec tous les generateurs de projets/makefile, gerer les mocs est trivial donc je suis curieux de voir ou ca te pose probleme.
> les boîtes commerciales programmant des applis proprio vont
> continuer à l'utiliser, préférant surement recoder 2 fois l'interface (win, X) que des payer des redevance a Qt...
Tu reves. 1500 $ par plateforme et par developpeur, ce n'est rien pour une boite. Si tu gagnes un mois de dev, tu t'es rembourse. Pour ce prix, tu peux obtenir un toolkit avec un support 24h, des developpements custom, un moteur javascript pour scripter tes applications, integrations complete dans microsoft windows (objets ActiveX) et tu programmes en C++ (pour votre info, l'industrie a laissee tombe le C il y a longtemp). Gtk n'a aucune chance. Va voir les success story du site de trolltech pour t'en convaincre.
C'est marrant, il y a un mosfet qui est un excellent developpeur et qui a bosser sur KDE. Bon, apparamment, ce n'est pas toi
> Je trouve que wxwidgets est un tres bon toolkit
On a pas dit qu'il etait mauvais, on a dit qu'ils avaient fait le mauvais choix.
> et un de ses enormes avantages que tu condamnes justement est le
> fait qu'il est tres proche des MFC
Ca presente un interet pour toi parce que tu programme en MFC. Maintenant, l'approche mutli-toolkit pose de nombreux problemes. Par exemple, un widget dispo un gtk mais pas en MFC devra etre recode en MFC avant d'etre disponible en wxWidget. Et plus il y a de toolkit supportes, plus la maintenance devient difficile.
Il y a ensuite les bugs specificques plateformes, qui alourdissent encore la maintenance.
Ensuite, il a les optimisations. Typiquement, le mec qui developpe sous linux se fait un super rich text control qu'il utilise pour stocker 2000 lignes de log. Il est content, ca marche bien et il pense que ca marche bien partout. Seulement pas de bol, le rich text control des MFC est _tres_ lent donc son appli sous windows est inutilisable.
Au contraire, l'approche de Trolltech enleve tous ces problemes. Le portage se reduit a porter les trois classes qui decrivent la plateforme. Les optimisations sur le rendu sont faites une fois pour toute et il n'y a pas de bugs specifique plate-formes. Ensuite, tous les widgets foncitonnent de la meme facon sur toutes les plateformes, le portage est vraiment une affaire de minutes.
Autres remarques:
- je ne sais pas comment tu peux preferer MFC a gtk. J'aime pas beaucoup gtk mais au moins, leur API est logique, deterministe, facile a comprendre, exempts de bugs bizarre et tres bien documentee. Aucun de ces adjectifs ne s'appliquent a MFC a mon avis.
- l'interface graphique en XML, gtk a ca depuis 7 ou 8 ans (cf glade) et Qt aussi (cf Qt Designer)
Tu devrais essayer Qt, ca te changera de paradigme et tu verras que tu seras plus efficace qu'en MFC.
Un soft peut avoir plusieurs licences tout comme un citoyen peut avoir plusieurs nationalite. Quand il passe la frontiere, il choisit le passport qu'il a envie de montrer et quand tu utilises un soft, tu choisis (si il a plusieurs licences) la licence avec laquelle tu veux l'utiliser.
Ce que je constate, c'est que la confiance qu'ont toujours eu les developpeurs KDE dans Trolltech est une fois de plus justifiee.
Quand KDE s'est lance, tout le monde a critique la licence de Qt mais les developpeurs KDE sont restes confiants que cela ne serait pas un obstacle pour le futur. Deux ans plus tard, Trolltech sortait la QPL qui resolvait tous ces problemes-la.
Ensuite, apres les seances de ralage industrialises, Trolltech est passe de la QPL a la GPL.
Et maintenant le GPL sous windows. Vraiment, c'est des gars bien !
Cette haine peut avoir de nombreuses explications et la rattacher a de l'incompetence, c'est le racourci ideologique facile qui t'evitera d'etre intelligent.
J'ai decouvert au bout de 2 heures que ca fait partie de gcc, et ca me semble le plus robuste comme approche. Mais tu peux essayer les autres, ca peut etre interessant (enfin, ceux qui sont libres).
La methode bourrin ou tu pre-process tes sources et ou tu rajoutes des macros de couveture de code, tu peux aussi te la redevelopper a la main.
> Essayer de couvrir tout le code d'une classe pour chaque état de l'objet reviendrait à explorer un arbre de possibilité infinie
Je ne suis pas d'accord. Le principe de la programmation objet est bien d'isoler les composants de facon a pouvoir les faire evoluer de facon autonome. Le corollaire, c'est que tu peux aussi les tester de facon autonome et donc de facon relativement finie.
S'il y a des conditions difficile a reproduire, c'est peut-etre aussi celle-la qui peuvent s'averer dangereuses. Par exemple, j'ai un protocole de communication sans-contact. C'est dur de simuler la perte de paquet dans le protocole, mais c'est hyper important de le faire, quitte a modifier un peu l'architecture de la gestion du protocole.
> Je trouve ça plus logique qu'on code une fonction à partir des spécifs
Dans le monde ideal, c'est comme ca. Dans le monde reel, il faut s'adapter. Moi je preconise deux approches:
- une approche black-box ou le testeur se base sur les specifs et test ce qui lui parait le plus important
- une approche transparent box ou le developpeur titille son programme la ou il sait que ca peut faire mal. Dans l'exemple que j'ai donne plus haut, un testeur ne pensera pas forcement a tester avec a = -b mais le developpeur lui saura que c'est une valeur cle a verifier.
Le plus proche d'un outil de couverture de code et couverture de chemin d'execution, c'est le cerveau du programmeur. Faire des tests uniquement en black-box (a partir des specifs), c'est se passer de cet outil.
> Il s'agit de générer des mutants
Super idee. Je vais chercher des references et voir si je peux mettre ca en pratique. En c, ca va etre un peu lourd...
En fait, il y a deux niveau. Le premier but d'un test, c'est de montrer que ton appli fait ce qu'elle doit faire. C'est le test fonctionnel, ou unitaire lorsqu'on se concentre sur un bout de code.
Moi j'interesse ici a la fiabilite (j'avais pas realise en ecrivant le journal, mais c'est vraiment le sujet). Comment prouver que l'appli ne fait jamais ce qu'elle ne doit pas faire. En gros, comment eviter a tout prix le segfault. Un utilisateur peut comprendre qu'une fonction ne fontionne pas bien. Mais un crash, ca reste incomprehensible et ca donne une tres tres mauvaise impression.
Apres, l'extension de "comment prouver que l'appli ne fait jamais ce qu'il faut pas meme quand on a la torture" peut etre vu comme "comment trouver le jeu de test qui torture l'appli suffisamment pour etre sur qu'elle resiste bien". On peut penser au cas simpliste du mec qui se code son strlen et qui est tout content parce que il marche. Sauf que quand tu lui passes un pointeur nul, paf, ca plante.
La preuve formelle, je ne connais que de nom mais apparemment, c'est tres difficile a conciler avec le travail quotidien du developpeur. Il faut y consacrer des resources et une intelligence non negligeable pour un resultat qui peut sembler minimal a cote de ce qu'on est capable de coder avec les memes resources.
Je developpe un OS pour carte a puce (proprietaire, mais aussi open source, cf jayacard.sf.net) et je voudrai etre sur qu'il est securise.
La technique de la mutation de code me parait une bonne approche. En plus de la couverture de code, ca permet de localiser des zones sombres. Je suis preneur d'autres trucs.
Les methodes que tu proposes pour peter le systeme sont plutot minables. La methode du bulldozer, ca se faisait au Bresil, ca ne se fait plus en France. Le plus simple, c'est de mettre un mini-lecteur de bande magnetique sur la fente ou tu enfonces ta carte, ou de mettre une webcam en fibre optique derrier le mec qui tape (sur le plafond du distributeur).
En plus, le besoin, ce n'est pas de casser une carte donnee, c'est de faire des fausses cartes. Ca tombe bien parce que c'est beaucoup plus facile. Donc ce qui devrait faire rire les professionnels, ce n'est pas la carte.
Le rapport un mois / 1h est aussi tres fantaisiste.
Bref, tes affirmations sont plutot a cote de la plaque, ce qui me fait dire que tu ne connais pas grand chose sur le sujet a part les trucs que tu as entendu a gauche et a droite.
Le gros probleme du systeme de paiement francais, c'est qu'il y a des vieux terminaux de paiement encore presents chez les commercants, donc on ne peut pas faire evoluer le systeme facilement. Si il suffisait de changer les cartes, il y a longtemp que ce serait fait, on les change tous les 4 ans. Il faut voir que les commercants payent pour le terminal de paiement et qu'ils n'ont pas envie de le changer tous les ans (an 2000, euro, moneo, EMV 2000, bon voyons !)
Pour vous consoler,on a le systeme le plus securise du monde pour la gestion de cartes bancaires. Je vous laisse imaginer ce que c'est ailleurs...
[^] # Re: GTK et Gnome n'ont plus de raison d'être !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 4.
Une appli proprio n'etait pas libre mais le deviendra peut-etre. Je vois pas le rapport ni avec gtk, ni avec qt, ni avec la choucroute.
[^] # Re: Ah oui mais...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 10.
Ce que je partage avec l'auteur de cette news comme point de vue, c'est que les tests unitaires ne sont pas assez utilise en logiciel libre. C'est un tort car ca permet de faire evoluer tres rapidement l'architecture d'un logiciel tout en conservant sa qualite. Si je prends une appli comme grisbi, il y a eu des versions completement inutilisables tellement elles etaient buggees. Pourtant, c'est pas dur d'ecrire des tests unitaires pour les fonctionnalites qui posaient probleme.
Depuis que je suis devenu un integriste du test unitaire, je constate que j'ai beaucoup moins de bugs sur mes projets et qu'ils sont beaucoup plus faciles a faire evoluer. Constation corroboree par d'autres convertis du test unitaire.
Alors le test unitaire, mangez-en. On peut en faire en C (cunit), en C++ (cppunit), en pyton (unittest), en java (junit, easymock), et C#, en ruby et en tout ce que vous voulez. L'important est d'avoir une suite de test automatisee.
Le contre-argument classique est "mais on ne peut pas tester cette partie-la". Avec un peu d'astuce, on peut tout tester mais il faut s'en donner les moyens. Par exemple, j'ai peu tester un protocole de communication radio ou il fallait simuler des conditions radio anormales. Je travail aussi sur du code embarque ou il faut tester le comportement d'un programme compile avec de l'overlay (pas de notion de fonctionr re-entrante, les variables locales ne sont pas sur la piles mais a des emplacements fixes). Ca aussi, on a put tester sans probleme a condition de reflechir a la facon d'aborder le probleme.
Ce qui est genial, c'est qu'une fois que les briques de bases ont beaucoup de tests unitaires, c'est tres tres facile de faire des tests fonctionnels de tres haut niveau, en assemblant des briques de tests unitaires.
Par exemple, une fois que j'ai eu mon protocole de communication debugge, j'ai pu teste l'ensemble de mon programme avec introdution de conditions radio anormales et autres petits problemes. J"etais doublement confiant dans sa qualite.
[^] # Re: De la criticité des bugs
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 6.
Bah, les developpeurs s'en foutent. Pourtant le bugs a pas mal de votes, et j'ai rencontre plein de gens interesses par la fonctionnalite.
Au final, si personne ne veux corriger un probleme, il ne sera pas corrige. Le developpeur ne considere que ce n'est pas important et puis voila.
[^] # Re: GPL != Libre
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
[^] # Re: c'est toujours pas libre ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
Oui, bien sur. Je sais que tout le monde ici est persuade que c'est le cas mais quand on regarde les cas concrets on se marre.
Combien de boite font du libre commercial ? Disons MySql, Trolltech, Mandrake, Red Hat, Suse pour les tres gros. En cherchant parmi les petits, on doit arriver a une 20aine ou une 30aine.
A cote de ca, combien de logiciels libres ? Tu ne sens pas comme un decalage ?
Combien de gens savent que quelques produits de TheKompany sont GPL mais dont les sources ne sont pas distribuees ? Dans ce cas, ces softs sont des bides, les gens ont hurle parce que ce n'etait pas gratuit mais GPL et personne n'a jamais contribue.
J'ai cree avec succes deux entreprises et ca fait aussi pas mal d'annees que je fais du logiciel libre. Je suis intimement persuade que faire de l'argent avec du libre reste extremement difficile et ne peut se faire quand des conditions tres particulieres sont reunies.
Le commercial + libre reste une exception exceptionelle, et j'en suis desole mais c'est comme ca. Dans mes boites on fait entre 100% et 95% de logiciel proprio et c'est ce qui nous permet de vivre.
[^] # Re: Desole, certaines entreprises programment encore en C
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
Aujourd'hui demarrer un projet non embarque en C est une pure aberration dans l'industrie, en pariculier dans le cas de logiciels graphiques.
Meme le C++ devient obsolete.
[^] # Re: GTK et Gnome n'ont plus de raison d'être !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 6.
Ben non, Qt passerai automatiquement en licence BSD. cf commentaire plus bas et cf la Free-Qt Foundation.
Gtk est la, donc c'est un peu bete de se dire qu'on ne doit plus l'utiliser. Cela dit, je reste persuade qu'ecrire un toolkit graphique en C est une anerie et fait perdre un temps monstreux en dev aux developpeurs.
Si MDI et consorts poussent d'autres langage de programmation (mono, java, python, ...) c'est bien parce qu'il semble que le C soit un peu depasse.
Ca me faisait marrer de lire le blog de MDI qui etait epate de la vitesse avec laquelle ils developpaient en C# + gnome. Et oui, bienvenu de le monde de l'objet, du polymorphisme, des garbage collector, des constructeurs et des destructeurs et de l'heritage.
Si vous voulez vous marrer un jour, regardez la quantite de code Gtk qu'il faut pour ecrire l'equivalent:
class MyWidget: public QWidget
{
public:
MyWidget( QWidget * p) : QWidget(p) {}
public slots:
void my_slot(int p1, int p2, int p3);
};
D'apres mes souvenirs (en gtk1), ca tape dans les 50 lignes de code, dont la moitie compose de macro sur des structures sans aucune verification de type.
[^] # Re: c'est toujours pas libre ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
Mouai. Prenons le nombre d'applis open source commerciales et divisons le par le nombre d'appli open source benevoles. Maintenant, faisons la meme operation avec le nombre d'appli open source commerciale que nous divisons par le nombre d'appli close source commerciales.
Je serai surpris qu'un seul de ces chiffres depasse les 0.01% . Certe, Trolltech fait un amalgame, mais il peut se defendre par les chiffres.
[^] # Re: et wxWidgets dans tout ça ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
Mouai. Je code tous les jours en PyQt (c'est mon boulot) et je n'ai pas eu la sensation de manquer de souplesse, au contraire. Le systeme signal/slot porte a python est beaucoup plus souple que celui du C++ puisque n'importe quelle methode ou fonction python peut servir de slot (callback).
[^] # Re: Peur...
Posté par Philippe F (site web personnel) . En réponse au journal Qt 4.0 en GPL sous Windows. Évalué à 4.
>>
Desole, mais meme si tous les arguments sont a NULL, l'api reste plus compliquee. C'est un probleme de l'api windows que tu ne peux pas nier.
Sous qt, je peux lancer un processus sans consuler la doc. Sous windows, je dois la relire trois fois pour etre sur que j'ai pas mis un NULL au mauvais endroit.
<<c) CreateProcess c'est un des nombreux APIs te permettant de lancer des processus, t'es libre d'utiliser d'autres APIs qui te permettent de faire des choses plus simples, plus simplement. >>
Ah ouai ? Et tu peux me dire ou on trouve cette api miracle ? Parce que quand on cherche sur le msdn, on tombe toujours sur CreateProcess.
[^] # Re: 1 de perdu...
Posté par Philippe F (site web personnel) . En réponse au journal Qt 4.0 en GPL sous Windows. Évalué à 2.
Enfin, quand je dis widgets natifs, c'est un peu exagere. Ils utilisent l'api de style natif du systeme d'exploitation pour dessiner leurs widgets. Mais normalement, ca ne doit faire aucune difference visuelle.
Quand j'installe gimp sous windows, il me demande si je veux utiliser le style wimp. Je suppose que gtk est donc exactement comme qt, ils utilisent au mieux le style de la plateforme et au pire,un style similaire recode a la main.
[^] # Re: 1 de perdu...
Posté par Philippe F (site web personnel) . En réponse au journal Qt 4.0 en GPL sous Windows. Évalué à 3.
euh, j'ai du mal lire. Le hurd etait tres attendu quand Linus a commence Linux. Depuis, plus personne ne l'attend...
Ok, c'est gratuit et ca n'enleve rien au respect que j'ai pour les developpeurs du Hurd. C'est juste que le monde ne s'arrete pas de tourner en attendant leur prochaine version.
[^] # Re: et wxWidgets dans tout ça ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
- sous windows, Qt utlise l'api de style de windows, donc les widgets ont exactement la meme tete que les widgets MFC
- idem sous aqua/mac os X, et sous KDE.
[^] # Re: c'est toujours pas libre ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 6.
En revanche, tu as raison, si tu veux coder une fonctionnalite qui interesse Trolltech, te devras le faire soit avec une licence type BSD, soit renoncer a ton copyright, soit autoriser aussi la licence commerciale.
Dans la pratique, ce n'est pas un gros probleme pour Trolltech. Comme ils ont des revenus, ils peuvent embaucher une armee de developpeurs super competents et recoder eux-meme ce qu'ils ont envie d'avoir dans Qt. Ca fait une grosse difference par rapport aux projets open source qui ne fonctionnent que par contribution.
Exemple, les qcanvas de Qt ont d'abord ete developpe par Varwick Allison en dehors de Trolltech. Ils ont ete rajoute dans Qt quand il a ete embauche. Autre exemple, QSA, le moteur javascript de Qt a ete code par le mec qui a code le moteur javascript de KDE. Trolltech l'a embauche pour qu'il refasse ce qu'il avait deja fait, mais en mieux (il avait des contraintes differentes).
Pour finir, si tu veux fournir une version de Qt avec des modifs a toi qui ne sont que GPL, tu peux faire un fork ou fournir un patch.
Sinon, contrairement a toi, je trouve leur modele excellent. Grace a leur revenus, ils peuvent payer 80 programmeurs a plein temps pour faire un super boulot sur Qt, et tous les developpeurs Open Source en beneficient. Marier son metier et l'open source, c'est un peu le reve de tous les programmeurs de logiciel libre.
[^] # Re: et wxWidgets dans tout ça ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
Ben justement, Qt fait la meme chose. Ca c'est une difference avec wxWidget.
Bon, si tu enleves les classes non graphiques de Qt (qui sont super pratiques, plus faciles a utiliser que la STL) et le systeme de signaux/slot qui est une des plus belle reussite de Qt, il ne reste pas grand chose.
J'ai pas essaye, mais tel que tu le decris, fox, c'est qt en moins bien.
[^] # Re: preprocessing
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 3.
C'est un sujet debattu et rebattu. Trolltech repond regulierement qu'ils ont envisage le passage en template mais que le moc presente de nombreux avantages techniques qui font qu'ils gardent cette approche.
Tu utilises quoi quand tu n'utilises pas qmake ? Avec tous les generateurs de projets/makefile, gerer les mocs est trivial donc je suis curieux de voir ou ca te pose probleme.
> les boîtes commerciales programmant des applis proprio vont
> continuer à l'utiliser, préférant surement recoder 2 fois l'interface (win, X) que des payer des redevance a Qt...
Tu reves. 1500 $ par plateforme et par developpeur, ce n'est rien pour une boite. Si tu gagnes un mois de dev, tu t'es rembourse. Pour ce prix, tu peux obtenir un toolkit avec un support 24h, des developpements custom, un moteur javascript pour scripter tes applications, integrations complete dans microsoft windows (objets ActiveX) et tu programmes en C++ (pour votre info, l'industrie a laissee tombe le C il y a longtemp). Gtk n'a aucune chance. Va voir les success story du site de trolltech pour t'en convaincre.
[^] # Re: et wxWidgets dans tout ça ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 3.
> Je trouve que wxwidgets est un tres bon toolkit
On a pas dit qu'il etait mauvais, on a dit qu'ils avaient fait le mauvais choix.
> et un de ses enormes avantages que tu condamnes justement est le
> fait qu'il est tres proche des MFC
Ca presente un interet pour toi parce que tu programme en MFC. Maintenant, l'approche mutli-toolkit pose de nombreux problemes. Par exemple, un widget dispo un gtk mais pas en MFC devra etre recode en MFC avant d'etre disponible en wxWidget. Et plus il y a de toolkit supportes, plus la maintenance devient difficile.
Il y a ensuite les bugs specificques plateformes, qui alourdissent encore la maintenance.
Ensuite, il a les optimisations. Typiquement, le mec qui developpe sous linux se fait un super rich text control qu'il utilise pour stocker 2000 lignes de log. Il est content, ca marche bien et il pense que ca marche bien partout. Seulement pas de bol, le rich text control des MFC est _tres_ lent donc son appli sous windows est inutilisable.
Au contraire, l'approche de Trolltech enleve tous ces problemes. Le portage se reduit a porter les trois classes qui decrivent la plateforme. Les optimisations sur le rendu sont faites une fois pour toute et il n'y a pas de bugs specifique plate-formes. Ensuite, tous les widgets foncitonnent de la meme facon sur toutes les plateformes, le portage est vraiment une affaire de minutes.
Autres remarques:
- je ne sais pas comment tu peux preferer MFC a gtk. J'aime pas beaucoup gtk mais au moins, leur API est logique, deterministe, facile a comprendre, exempts de bugs bizarre et tres bien documentee. Aucun de ces adjectifs ne s'appliquent a MFC a mon avis.
- l'interface graphique en XML, gtk a ca depuis 7 ou 8 ans (cf glade) et Qt aussi (cf Qt Designer)
Tu devrais essayer Qt, ca te changera de paradigme et tu verras que tu seras plus efficace qu'en MFC.
[^] # Re: Double licence ?
Posté par Philippe F (site web personnel) . En réponse au journal Qt 4.0 en GPL sous Windows. Évalué à 5.
# Nous avons eu raison de croire en Qt
Posté par Philippe F (site web personnel) . En réponse au journal Qt 4.0 en GPL sous Windows. Évalué à 10.
Quand KDE s'est lance, tout le monde a critique la licence de Qt mais les developpeurs KDE sont restes confiants que cela ne serait pas un obstacle pour le futur. Deux ans plus tard, Trolltech sortait la QPL qui resolvait tous ces problemes-la.
Ensuite, apres les seances de ralage industrialises, Trolltech est passe de la QPL a la GPL.
Et maintenant le GPL sous windows. Vraiment, c'est des gars bien !
[^] # Re: surtout pas
Posté par Philippe F (site web personnel) . En réponse au journal Besoin d'arguments de chocs contre Microsoft. Évalué à 2.
[^] # Re: surtout pas
Posté par Philippe F (site web personnel) . En réponse au journal Besoin d'arguments de chocs contre Microsoft. Évalué à 6.
Nan, je plaisante
[^] # Re: Un truc en C++ qui fait ca
Posté par Philippe F (site web personnel) . En réponse au journal couverture de code. Évalué à 2.
http://ltp.sourceforge.net/coverage/lcov.php(...)
http://www.semdesigns.com/Products/TestCoverage/CppTestCoverage.htm(...)
Bon, en fait, il n'y a pas grand chose.
J'ai decouvert au bout de 2 heures que ca fait partie de gcc, et ca me semble le plus robuste comme approche. Mais tu peux essayer les autres, ca peut etre interessant (enfin, ceux qui sont libres).
La methode bourrin ou tu pre-process tes sources et ou tu rajoutes des macros de couveture de code, tu peux aussi te la redevelopper a la main.
[^] # Re: Pas si simple...
Posté par Philippe F (site web personnel) . En réponse au journal couverture de code. Évalué à 2.
Je ne suis pas d'accord. Le principe de la programmation objet est bien d'isoler les composants de facon a pouvoir les faire evoluer de facon autonome. Le corollaire, c'est que tu peux aussi les tester de facon autonome et donc de facon relativement finie.
S'il y a des conditions difficile a reproduire, c'est peut-etre aussi celle-la qui peuvent s'averer dangereuses. Par exemple, j'ai un protocole de communication sans-contact. C'est dur de simuler la perte de paquet dans le protocole, mais c'est hyper important de le faire, quitte a modifier un peu l'architecture de la gestion du protocole.
> Je trouve ça plus logique qu'on code une fonction à partir des spécifs
Dans le monde ideal, c'est comme ca. Dans le monde reel, il faut s'adapter. Moi je preconise deux approches:
- une approche black-box ou le testeur se base sur les specifs et test ce qui lui parait le plus important
- une approche transparent box ou le developpeur titille son programme la ou il sait que ca peut faire mal. Dans l'exemple que j'ai donne plus haut, un testeur ne pensera pas forcement a tester avec a = -b mais le developpeur lui saura que c'est une valeur cle a verifier.
Le plus proche d'un outil de couverture de code et couverture de chemin d'execution, c'est le cerveau du programmeur. Faire des tests uniquement en black-box (a partir des specifs), c'est se passer de cet outil.
> Il s'agit de générer des mutants
Super idee. Je vais chercher des references et voir si je peux mettre ca en pratique. En c, ca va etre un peu lourd...
[^] # Re: pas une preuve
Posté par Philippe F (site web personnel) . En réponse au journal couverture de code. Évalué à 3.
Moi j'interesse ici a la fiabilite (j'avais pas realise en ecrivant le journal, mais c'est vraiment le sujet). Comment prouver que l'appli ne fait jamais ce qu'elle ne doit pas faire. En gros, comment eviter a tout prix le segfault. Un utilisateur peut comprendre qu'une fonction ne fontionne pas bien. Mais un crash, ca reste incomprehensible et ca donne une tres tres mauvaise impression.
Apres, l'extension de "comment prouver que l'appli ne fait jamais ce qu'il faut pas meme quand on a la torture" peut etre vu comme "comment trouver le jeu de test qui torture l'appli suffisamment pour etre sur qu'elle resiste bien". On peut penser au cas simpliste du mec qui se code son strlen et qui est tout content parce que il marche. Sauf que quand tu lui passes un pointeur nul, paf, ca plante.
La preuve formelle, je ne connais que de nom mais apparemment, c'est tres difficile a conciler avec le travail quotidien du developpeur. Il faut y consacrer des resources et une intelligence non negligeable pour un resultat qui peut sembler minimal a cote de ce qu'on est capable de coder avec les memes resources.
Je developpe un OS pour carte a puce (proprietaire, mais aussi open source, cf jayacard.sf.net) et je voudrai etre sur qu'il est securise.
La technique de la mutation de code me parait une bonne approche. En plus de la couverture de code, ca permet de localiser des zones sombres. Je suis preneur d'autres trucs.
[^] # Re: URL
Posté par Philippe F (site web personnel) . En réponse au journal Carte d'identité biométrique. Évalué à 4.
Les methodes que tu proposes pour peter le systeme sont plutot minables. La methode du bulldozer, ca se faisait au Bresil, ca ne se fait plus en France. Le plus simple, c'est de mettre un mini-lecteur de bande magnetique sur la fente ou tu enfonces ta carte, ou de mettre une webcam en fibre optique derrier le mec qui tape (sur le plafond du distributeur).
En plus, le besoin, ce n'est pas de casser une carte donnee, c'est de faire des fausses cartes. Ca tombe bien parce que c'est beaucoup plus facile. Donc ce qui devrait faire rire les professionnels, ce n'est pas la carte.
Le rapport un mois / 1h est aussi tres fantaisiste.
Bref, tes affirmations sont plutot a cote de la plaque, ce qui me fait dire que tu ne connais pas grand chose sur le sujet a part les trucs que tu as entendu a gauche et a droite.
Le gros probleme du systeme de paiement francais, c'est qu'il y a des vieux terminaux de paiement encore presents chez les commercants, donc on ne peut pas faire evoluer le systeme facilement. Si il suffisait de changer les cartes, il y a longtemp que ce serait fait, on les change tous les 4 ans. Il faut voir que les commercants payent pour le terminal de paiement et qu'ils n'ont pas envie de le changer tous les ans (an 2000, euro, moneo, EMV 2000, bon voyons !)
Pour vous consoler,on a le systeme le plus securise du monde pour la gestion de cartes bancaires. Je vous laisse imaginer ce que c'est ailleurs...