Oui. On utilise quand meme KDE pour la partie graphique, ncurses pour le texte donc ca nous epargne pas mal de probleme.
Comme on le disait dans l'annonce, le syntax highlighting est pique a kate.
Pour ce qui est de l'immonde langage de script de vim, on remplacera ca avantageusement par un truc moderne, genre lua (www.lua.org)
Pour la gestion des regexp, de l'unicode et des polices, on s'en remet a Qt. Pour la communication multi-fenetre, peut-etre qu'on utilisera un bout de dcop ou de dbus.
Donc le moteur lui-meme est re-ecrit a la mano mais tout ce qui est autour utilise les technos existantes.
Pour la gestion des options, je vois gros comme une patate qu'on va utiliser le dernier generateur automatique de dialogue de configuration de KDE (ou bien on se recoder a un truc a la main).
Faut voir que dans vim, il y a du code bas-niveau X pour gerer la communication vim-server / vim-client, il y a vim_strcmp et vim_strdup. On peut pas maximiser correctement une fenetre parce que vim pense etre plus fort que le window manager (plus precisement, il marche dans des environnements sans window manager), etc etc.
On peut voir vim un peu comme OpenOffice. Il y a tout dedans donc c'est hyper portable. Mais niveau code, il y a prix qui est tres cher a payer.
Trolltech donne plusieurs raisons pour lesquelles distribuer Qt sous GPL pour windows leur poserait des problemes.
Le moins que tu puisses faires si tu pretends leur apprendre a faire leur business, c'est au moins de t'interesser a leur problematique. Ton post actuel ne merite qu'un moinssage, vu qu'il n'apporte rien au debat a part le fait que tu rales.
> Là ou c'est pernicieux , c'est que la communté libre leur a permis de
> se développer grâce notamment au support de KDE
Ah ouai ? Je suis un fan de KDE mais faudrait pas croire que c'est le centre du monde. C'est pas KDE qui a permis a Trolltech d'etre populaire sur windows et sur MacOS, ou de faire une version embarquee. C'est pas les devs de KDE qui fournissent les tonnes de doc et de code de Qt.
Il y a des interactions mais Trolltech a une existence en dehors de KDE.
Quant a la version non-commercial, c'est carrement l'inverse. Ca a fait perdre de l'argent a Trolltech et donc ca ne les a pas aide a se developpe (d'ou le fait qu'ils n'ont pas renouvele l'experience).
Pour que KDE accepte de se passer de DCOP, il faudra que DBUS propose des avantages nets, ce qui n'est pas encore le cas. DBUS pour l'instant n'est meme pas adopte pas Gnome, et ne permet pas de faire tout ce que fait dcop.
J'espere aussi que la transition se fera mais faut pas croire que ca sera rapide. Peut-etre pour KDE4. Il n'a pas fallu beaucoup de temps pour faire DCOP, mais certaines finitions prennent du temps et de l'experience d'utilisation. Il faut laisser DBUS maturer encore.
Il existe un petit projet permettant a gtk d'utiliser le theme Qt courant. Sinon, la problematique de la couleur de fond a normalement ete resolu depuis longtemp. Maintenant, la couleur de fond est mise a jour pour gtk quand tu changes de theme/style sous KDE. Je suis surpris que ca ne soit pas le cas chez toi.
Pourquoi ce serait pas Gnome qui utiliserait kconfig ? kconfig lui-meme n'a aucune dependance avec KDE et il est facile a une appli exterieure de relire les fichires de conf KDE qui sont bien organises.
Pour resume, c'est difficile d'avancer parce que les deux solutions sont toutes les deux techniquement valables et en changer aurait d'une part des gros impacts en architectures, d'autre part un gros impact sur le bureau qui changerait.
La semaine derniere, un mec a propose sur la liste freedesktop un autre systeme de configuration global. Ce qui est ressorti de la facon dont il s'est fait allume, c'est que kconfig et gconf sont tous les deux des solutions bien eprouvees techniquement, qu'on ne peut pas remplacer facilement.
Les developpeurs ont bien la volonte de faire un systeme de configuration commun, pour partager des choses comme la bases de donnees mime, des themes, la configuration d'applications communes mais la solution technique n'a pas encore ete trouvee.
En general, Trolltech n'aime pas faire du vaporware et est assez protecteur de ses sources tant qu'elle n'ont pas atteint un etat stable. A vue de nez, je dirai qu'on devrait voir des snapshots arriver a partir de cet ete.
> des millions de soft mineurs en shareware que personne n'utilise.
Je crois que tu t'illusionnes gravement sur le succes du libre sous windows. Il y a bien plus de gens qui utilisent winzip ou irfan view que tous les utilisateurs de Mozilla, OpenOffice et psi cumules.
> Je peux comprendre leur peur de non-respect de la GPL mais c'est gênant.
La dessus, on est tous d'accord, Mathias y compris. Mais il y a un moment ou tu dois gagner ta croute avec le logiciel que tu vends et ils n'ont pas le choix. Trolltech n'est pas ferme, l'histoire le montre et l'ouverture recente de Qt sous Apple le rappelle. Mais sous windows, c'est la qu'ils gagnent une part importante de leurs revenus, qu'ils perdraient sinon.
Je pense que le monde du libre a plus a gagner avec Trolltech beneficiaire et continuant a developper Qt, que avec Trolltech en faillite et Qt en GPL sous windows.
Pour reprendre tes reponses:
- sisi, ca sert. La preuve en a ete donne par le passe.
- oui, mais ce serait deja un gros progres. Mathias avait l'air ouvert a l'idee d'avoir un moyen pour les projets open source de beneficier de Qt pour windows.
- oui et non. Il y a deux projets, un projet par cygwin/x11 et un projet pour porter Qt en natif.
> C'est un risque minime ca permet de faire connaitre la GPL.
Non, c'est un risque majeur pour Qt et ils font deja connaitre la GPL a des gens que ca interesse, a savoir la communaute Linux et la communaute Mac.
Quand ils ont sorti Qt non commercial, leurs ventes ont baisse dramatiqueemnt. Pourtant, je n'ai pas entendu parle de projet libre ou de freeware ayant achete Qt. Donc la baisse des ventes est bien liee a des boites qui n'ont pas achete Qt quand elles auraient du le faire.
> 1. Utilisation illicite volontaire (vente de produit commerciaux lié avec Qt
> version GPL), c'est possible mais si le produit marche ils payeront
> rapidement la license Qt pour ne pas rester dans l'illegalité.
C'est pas a Trolltech de financer le developpement de societe de logiciel. Surtout que pour une boite, c'est pas tres cher. En plus, beaucoup de ces societes servent des marches ultra-specialise dont personne n'entendra jamais parle. Trolltech ne recuperera pas le manque a gagner dans cette situation.
> 2. Utilisation illicite involontaire, c'est pas bien grave.
> firefox, thunderbird, gaim (ainsi que abiword et gnumeric dans un futur proche j'espère)
Tout ce ne fait pas une communaute suffisante pour interesser Trolltech. Ccompare au nombre de logiciels KDE, Qt, Gtk ou au nombre de logiciels disponibles sous Windows en shareware.
Pour que ca soit vraiment interessant pour Trolltech, il faut une communaute de developpeur pret a utiliser Qt, comme on en voit sous KDE.
Face a ce probleme de Qt/Windows, il y a trois solutions:
- continuer a faire chier Trolltech pour qu'ils releasent Qt sous GPL sous windows.
- demander comme l'a fait psi une licence speciale juste pour leur projet Open Source
- aider le portage en natif windows de Qt (kde-cygwin.sf.net)
- utiliser PyQt qui est abordable en prix (mais toujours pas gratuit)
- acheter le dernier bouquin sur Qt et obtenir Qt 3 non commercial pour windows.
- qui a dit que je savais compter ?
A) -> non, pas mal de boites feraient du GPL mais pas vraiment. C'est a dire qu'elles utiliseraient du code GPL mais "oublieraient" de publier les sources de leur code et d'utiliser la GPL comme licence.
Pourtant quand ils ont mis Qt disponible en version non commerciale, les ventes de Qt version commercial ont chute dramatiquement. Se pourrait-il que, o sacrilege, des boites ne respectent pas la licence des produits qu'ils utilisent ?
Finalement, les devs chez Microsoft sont des gens comme les autres. Enfin quelques uns.
Je rapproche l'attitude sympatique de ce developeur de celle d'un des mecs qui avait ete cite malgre lui dans les premiers documents halloween. Si je me souviens bien, il faisait une analyse de l'open source pour Bill Gates mais semblait pret a basculer du cote clair de la force:
<<
I'm a poorly skilled UNIX programmer but it was immediately obvious to me how to incrementally extend the DHCP client code (the feeling was exhilarating and addictive).
>>
Ce qui me parait suprenant, c'est qu'il a developpe le logiciel sur son temps libre en dehors de ses attributions professionelles, mais que malgre cela, le copyright est assigne a Microsoft. De la description qu'il fait de son travail, il etait tout a fait fonde pour lui de conserver le copyright.
Maintenant, si il change de boite et qu'il veut recuperer son soft pour y faire des modifs, il peut dans une certaine mesure en etre empeche par Microsoft.
Je placerai ca sur le manque d'habitude du logiciel libre.
Il s'agit plus que d'integration visuelle. Les integrations prevues sont:
- utilisation du theme courant KDE pour dessiner les widget (ok, ca, c'est visuel)
- utilisation du dialogue de fichier KDE: consequence, tous les protocoles reseau supportes par KDE (ssh, ftp, http, ....) seront supportes
- utilisation du dialogue d'impression KDE
- integration sous forme de composant dans d'autres applications: oo pour ouvrir des documents words dans konqueror, c'est deja possible
Le terme analyse est mal adapte. Ce dont on parle, c'est l'idee que se font certains professionnels du metier que a partir du moment ou tu as les specs, tu peux faire ta conception UML, et a partir du moment ou ta conception UML marche, le produit est pratiquement developpe. Je pense que cette approche ignore de nombreux facteurs importants, comme le fait que le client ne sait pas ce qu'il veut, qu'il change d'avis, que les specs ne sont pas parfaites et que les bugs sont incontrolables.
> si tu codes pendant 6 mois et que le client change d'avis ?
Et bien comme tu as privilegie des releases courtes, on va dire de trois mois, le client a deja eu deux versions sous les yeux. Donc il a eu beaucoup plus le temps de se faire son avis. Notamment apres la permiere version, il a probablement change un peu d'avis et oriente la version suivante differamment. C'est le client qui choisit les fonctionnalites les plus prioritaires.
Comme tu as privilegie dans tes premieres versions les fonctionnalites qui avaient le plus de valeurs pour le client, il y a aussi toutes les chances que meme si il arrete le projet au bout de 6 mois pour raisons variees (budget en general), ce que tu as developpe est utilisable pour lui donc il va probablement le payer. Ca fait une grosse difference avec la methode UML ou le client sera peu enclin a te payer pour tes diagrammes UML.
Pour ce qui est de l'analyse, elle se fait dans un bureau avec tous les developpeurs et tous les clients. En revanche, la conception complete se fait plus tard. Dans la mesure ou on avance par iteration, ceratines parties de l'analyse n'ont pas besoin d'etre extermement pousee pour la premiere iteration ce qui allege la charge initiale et laisse plus de marge au client pour se faire une idee apres la premiere version.
Donc non seulement, le client peut changer d'avis au bout de 6 mois, mais meme on l'encourage.
Note aussi que comme tu as des suites de tests blindees, unitaires et fonctionelles, tu es beaucoup plus cool face au changement. Si la moitie des fonctionnalites change, l'autre moitie sera surement impactee mais tu seras en mesure de faire tourner les suites de tests deja developpee pour remettre l'ancienne moitie en etat avec les nouvelles fonctionnalites.
Globalement, XP te rend plus zen face aux problemes classiques de developpement. Si tu trouves un bug 1h avant de livrer la version finale au client, tu n'as pas peur de patcher comme un malade et de toute peter, car tu as tes suites de tests qui sont la pour te dire quand tu fais une connerie. Evidemment, dans ce cas, ca suppose aussi d'avoir un processus automatique de generation de release, ce qui, meme si il n'est pas presente dans la medhode, s'inscrit tout a fait dans l'esprit.
Je n'ai pas pretendu que XP avait invente les tests. En revanche, la methode a popularise ou repopulairser les suite de tests automatises. La seule methode academique de dev dont j'ai entendu parle (ma formation est plutot pratique) est le diagramme en V ou on specifie les tests dans la partie descente, on code en creux du V et on fait tourner les tests dans la remontee du V. Dit comme ca, les tests sont ecrits apres le code et ne pourront pas etre utilise par le developpeur pendant son cycle de developpement. Dans cette methode classique, les tests sont repousses a la fin, ce qui garantit des gros problemes d'integration. Tout ca pour dire que dans certaines methodes "classiques", les tests ne jouent pas un role aussi important que sous XP, d'ou la distinction.
Je tiens aussi a attirer l'attention sur le fait que "faire un test" n'a pas la meme signification pour tout le monde. Pour beaucoup, ca signifie avoir lance le logiciel et teste manuellement quelques patterns. Pour moi, ca signifie avoir developpe une suite de test que n'importe qui peut lancer pour valider ce tout marche. Donc quand on dit "mais je fais deja des tests", il est possible qu'on ne parle pas de la meme chose.
Sinon, je suis heureux de voir que ta boite a deja une bonne politique de tests. Cela qui contredit ta remarque initiale comme quoi XP est la somme des mauvaises pratiques du metier.
> si le code produit n'est pas immédiatement testable
C'est beaucoup beaucoup plus rare qu'on ne pense. Pour l'instant, je n'ai pas encore rencontre de situation ou c'est le cas. Pourtant, je travaille dans la carte a puce ou la seule facon de tester du code (avec une approche naive), c'est de le mettre dans un emulateur a 10000 euro et de lancer le debugger. Mais on a reussi sans probleme, avec un peu d'imagination, a tester toutes les couches de notre systeme d'exploitation pour carte a puce et tous les outils logiciels qui l'utilisent. Et en bonus, on a des tests securitaires impossible a mettre en place sur une vraie carte.
C'est possible de tester du code meme quand les couches basses ne sont pas encore disponibles et la-dessus, je suis sur que vous pourriez vous ameliorer. Evidemment, ca demande de repenser en general un peu l'architecture, mais le logiciel dans mon experience en sort grandement ameliore, en plus d'etre plus fiable. Je suis a ta disposition pour tout conseil si ca t'interesse (c'est gratuit)
Bien sur, on t'enseigne dans toutes les ecoles qu'il faut faire des tests. Mais combien prennent le temps d'introduire des methodologies de tests ? Combien montrent par la pratique ce que c'est qu'un bon test ? Combien t'introduisent a des bibliotheques de tests ? Combien font la difference entre un test exhaustif et juste un test a la con ? Combien font la difference entre un test et un test automatise que tu dois lancer toutes les 5 minutes de developpement ?
Au dela du blabla sur les tests, la methodologie XP a fait naitre ou renaitre des bibliotheques permettant de faire des suites de tests. Si tu cherches sur sourceforge, toutes les libs de test que tu trouveras font references a XP: cppunit, junit, javaunit, mock, easymock, mockobjects, pyunit, ...
Pour ce qui est de l'analyse, il faut mettre ca en relation avec les nombreux projets professionnels ou tu dois pondre 6 mois de diagrammes UML avant de commencer la moindre ligne de code. Pas de bol, au bout de 7 mois, le client a change d'avis et tu peux mettre tous tes diagramme a la poubelle. C'est en ce sens la qu'il faut lire la priorite au code.
XP prone plutot que de faire 6 mois de diagramme, de faire une conception rapide et de trouver ensuite la fonctionnalite qui a le plus de valeur pour le client, et qu'on peut delivrer le plus rapidement. C'est celle la qui aura la priorite pour les premieres iterations.
Dans ton exemple de compte en banque, non, on ne commencerai pas par faire la gestion des comptes. On discuterai avec le client pour voir ce dont il a le plus besoin. Ca pourrait etre par exemple que le GUI de leur application actuelle est horrible et que c'est ce qui a motive la demande pour un nouveau systeme. Dans ce cas, on commencerai par refaire le GUI tout en s'appuyant sur l'ancien systeme, pour apporter un benefice immediat. Tu as un chance sur 10 avec une telle approche que le client te dise que finalement, avec le nouveau GUI, plus besoin de changer le systeme...
C'est pas bon pour ton job :-), mais le client a eu ce qu'il voulait. Ce que ca risque d'induire, c'est pas qu'on ne change pas le systeme, mais qu'on fasse des modifications moins drastiques que ce qui etait prevu.
Ben moi j'ai deja vu des projets reussir (bien que|parce que|où) on avait applique une partie des methodes d'extrem programming. De la conclure que la methode a elle seule ne peut en rien garantir ni le succes, ni l'echec d'un projet, il n'y a qu'un pas qu'apparamment, tu ne franchis pas.
On peut planter ou reussir n'importe quel projet donc quelle que soit la methode de dev utilisee si on y met la volonte qu'il faut: un mauvais manager, des developpeurs qui s'en foutent ou imcomptents, des problemes qui ne sont pas remontes a temps, ... Dans ce cas, c'est pas Extrem Programming ou le methode machin-chose qu'il faut blamer.
> c'est un chateau de cartes constitué par toutes les mauvaises
> pratiques du développement logiciel
Je ne suis pas du tout d'accord. On parle bien de la meme methode la ? Ce que j'ai retenu d'XP:
- une tres forte pression sur les tests
- faire des releases courtes centrees sur le fonctionnalites les plus importantes pour le client
- de la transparence: faire une remontee tres rapide vers le client
- des tests encore
- faire un suivi pousse de la realisation des taches
Pour moi, ces methodes ne meritent pas le qualificatif "mauvaises pratiques de developpement". Au contraire, je pense qu'elles sont garantes de robustesse et pas mal de projet libre devrait s'en inspirer.
Pour l'instant, j'ai surtout applique le principe des tests a toutes les sauces, et tous mes projets logiciels en sont sortis plus fiables. J'ai commence sur un projet de 5000 lignes ou on a trouve un bug en 6 mois (pour l'implementation d'un protocole de transport). Le fais d'avoir fait des tests de toutes les couches de transport m'a permis de simuler des conditions normalement difficilement realisables par une approche de test 'classique' et m'a permis de lever des bugs assez sournois.
La, je suis sur un projet de 100 000 lignes a peu pres. Je suis tout seul et je dois avancer le plus vite possible sans pour autant me gourer. Mes partenaires apprecient _beaucoup_ mon emphase sur les tests et sont rassures quant a la qualite du projet justement a cause de ca. Ca m'a permis aussi de leur trouver beaucoup de bugs sur leur partie, qui ont ete mis en evidence la encore par les tests.
Bref, pour moi, XP a permis de faire des projets beaucoup plus solides et je n'envisage pas de developper sans reflechir en meme temps aux tests et aux fonctionnalites.
Si, ca change ton message, tu vois bien qu'il existe des masochistes.
Plus serieuseement, pour la personne qui disait vouloir utiliser gimp sous windows, voila la reponse. Certe, il faut installer cygwin mais tout linuxien sous windows l'a en general deja. Bon, sinon, niveau utilisabilite, je crois que c'est super lourd et lent.
KDE->Utilities->Amor (Amusing Misuse Of Resources)
te donne le choix entre divers personnages qui se baladent sur la barre de tes fenêtres. Il y a notamment un petit chat qui saute dans tous les sens et qui te regarde en battant de la queue.
Il y a quelques années, je me souviens qu'il était possible de le faire utilise des personnages de quake 2. Je ne sais pas si c'est encore possible mais j'ai un copain qui l'avait fait a l'époque et c'était sympa.
Pour ton histoire de noyau, si il permet de faire qqs trucs, c'est suffisant. Il faut voir aussi que les gens les plus interesses par une contriubtion seront peut-etre tes clients. Il faut leur donner les moyens de s'approprier la techno en allant plus que simple utilisateurs. Evidemment, tous les clients n'ont en general pas le profil developpeur mais il suffit d'un bon client qui peut te faire des patchs sur les bugs qu'il a trouve pour que l'equation soit positive.
En ce qui concerne les problemes de licence, tu es l'auteur donc tu choisis vraiment la licence que tu veux. La GPL n'est pas toujours la plus adaptee quand on fait du business. C'est pas pour rien que Trolltech l'a evite pendant si longtemp. FAut voir que en tant qu'auteur, tu peux ne liberer qu'une partie de ton produit, sous la licence que tu veux. En general, ca laisse sufiisamment de souplesse.
Il faut aussi estimer l'interet pour la communaute. Si tu crois vraiment qu'une equipe de dev libres va s'interesser a ton produit, il ne faut pas que la licence soit du foutage de gueule. Mais si c'est le cas, ils te le diront et vous pourrez regler le probleme a ce moment-la.
Oui, c'est vrai que ca ne ressort pas dans mon message. Les portages que j'ai faits ont ete faits avec une licence commerciale.
Pour ce qui est d'un portage d'application libre sous windows, on peut tenter l'aventure cygwin mais c'est quand meme assez lourd puisqu'il faut faire tourner un serveur XFree.
Cependant, une fenetre d'espoir s'est ouverte recmment: si vous achetez le bouquin sur Qt3, vous obtenez en prime Qt en version non commerciale pour windows. Je ne sais pas quelle licence y est attache, notamment en ce qui concerne la redistribution.
Donc pour resumer, Qt sous windows en logiciel libre, c'est Qt 2 non commercial ou bien la galere, au moins autant et probablement plus que pour faire du Gtk sous windows.
C'est pour ca que je recommendais plus haut d'utilise wxWidgets pour ce genre de chose. Cependant, wxWidgets reste quand meme inferieur a Gtk ou Qt en terme de paradigme de programmation. Donc vous allez galerer plus.
J'ai monte deux boites logicielles, donc je te donne mon point de vue tenant compte des realites de la vie reelle :-)
Faire de l'argent en vendant un service sur du logiciel libre, c'est possible.
Faire de l'argent en vendant sous forme de logiciel libre une bibliotheque logicielle indispensable a la realisation d'un autre logiciel, c'est possible mais il faut bien faire attention.
Faire de l'argent en vendant un produit fini en tant que logiciel libre, ca n'est pas a mon avis viable economiquement.
Il semble que tu sois dans le deuxieme cas. Pour que ca marche, il faut que tes clients soient au final forces d'acheter la licence si ils ont l'intention d'utiliser le produit de facon majeure. En revanche, c'est une bonne idee d'encourager le particulier a developper avec votre appli chez lui le soir (si c'est a sa portee) pour favoriser la diffusion de votre outil.
Il y a pas de miracle, pour faire de l'argent, il faut quand meme a un moment forcer la main au client. Si tu donnes tout, il n'achetera rien.
[^] # Re: Yzis, un nouveau clone de vi
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis, un nouveau clone de vi. Évalué à 3.
Comme on le disait dans l'annonce, le syntax highlighting est pique a kate.
Pour ce qui est de l'immonde langage de script de vim, on remplacera ca avantageusement par un truc moderne, genre lua (www.lua.org)
Pour la gestion des regexp, de l'unicode et des polices, on s'en remet a Qt. Pour la communication multi-fenetre, peut-etre qu'on utilisera un bout de dcop ou de dbus.
Donc le moteur lui-meme est re-ecrit a la mano mais tout ce qui est autour utilise les technos existantes.
Pour la gestion des options, je vois gros comme une patate qu'on va utiliser le dernier generateur automatique de dialogue de configuration de KDE (ou bien on se recoder a un truc a la main).
Faut voir que dans vim, il y a du code bas-niveau X pour gerer la communication vim-server / vim-client, il y a vim_strcmp et vim_strdup. On peut pas maximiser correctement une fenetre parce que vim pense etre plus fort que le window manager (plus precisement, il marche dans des environnements sans window manager), etc etc.
On peut voir vim un peu comme OpenOffice. Il y a tout dedans donc c'est hyper portable. Mais niveau code, il y a prix qui est tres cher a payer.
[^] # Re: Yzis, un nouveau clone de vi
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis, un nouveau clone de vi. Évalué à 2.
http://svn.freenux.org/xml/yzis/trunk/README(...)
Voir aussi notre discussion sur vim-dev il y a deux ans pour essayer de corriger le probleme.
http://marc.theaimsgroup.com/?l=vim-dev&m=103648575424303&w(...)
[^] # Re: Une longue interview de Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 1.
Trolltech donne plusieurs raisons pour lesquelles distribuer Qt sous GPL pour windows leur poserait des problemes.
Le moins que tu puisses faires si tu pretends leur apprendre a faire leur business, c'est au moins de t'interesser a leur problematique. Ton post actuel ne merite qu'un moinssage, vu qu'il n'apporte rien au debat a part le fait que tu rales.
> Comment je fais pour downloader Qt 3.3 pour Windows pour mon projet GPL
http://kde-cygwin.sf.net(...)
> Là ou c'est pernicieux , c'est que la communté libre leur a permis de
> se développer grâce notamment au support de KDE
Ah ouai ? Je suis un fan de KDE mais faudrait pas croire que c'est le centre du monde. C'est pas KDE qui a permis a Trolltech d'etre populaire sur windows et sur MacOS, ou de faire une version embarquee. C'est pas les devs de KDE qui fournissent les tonnes de doc et de code de Qt.
Il y a des interactions mais Trolltech a une existence en dehors de KDE.
Quant a la version non-commercial, c'est carrement l'inverse. Ca a fait perdre de l'argent a Trolltech et donc ca ne les a pas aide a se developpe (d'ou le fait qu'ils n'ont pas renouvele l'experience).
Tu dis vraiment n'importe quoi.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Qt 4 à l'horizon !. Évalué à 3.
J'espere aussi que la transition se fera mais faut pas croire que ca sera rapide. Peut-etre pour KDE4. Il n'a pas fallu beaucoup de temps pour faire DCOP, mais certaines finitions prennent du temps et de l'experience d'utilisation. Il faut laisser DBUS maturer encore.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Qt 4 à l'horizon !. Évalué à 1.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Qt 4 à l'horizon !. Évalué à 4.
Pour resume, c'est difficile d'avancer parce que les deux solutions sont toutes les deux techniquement valables et en changer aurait d'une part des gros impacts en architectures, d'autre part un gros impact sur le bureau qui changerait.
La semaine derniere, un mec a propose sur la liste freedesktop un autre systeme de configuration global. Ce qui est ressorti de la facon dont il s'est fait allume, c'est que kconfig et gconf sont tous les deux des solutions bien eprouvees techniquement, qu'on ne peut pas remplacer facilement.
Les developpeurs ont bien la volonte de faire un systeme de configuration commun, pour partager des choses comme la bases de donnees mime, des themes, la configuration d'applications communes mais la solution technique n'a pas encore ete trouvee.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Qt 4 à l'horizon !. Évalué à 5.
[^] # Re: Une longue interview de Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 3.
Je crois que tu t'illusionnes gravement sur le succes du libre sous windows. Il y a bien plus de gens qui utilisent winzip ou irfan view que tous les utilisateurs de Mozilla, OpenOffice et psi cumules.
> Je peux comprendre leur peur de non-respect de la GPL mais c'est gênant.
La dessus, on est tous d'accord, Mathias y compris. Mais il y a un moment ou tu dois gagner ta croute avec le logiciel que tu vends et ils n'ont pas le choix. Trolltech n'est pas ferme, l'histoire le montre et l'ouverture recente de Qt sous Apple le rappelle. Mais sous windows, c'est la qu'ils gagnent une part importante de leurs revenus, qu'ils perdraient sinon.
Je pense que le monde du libre a plus a gagner avec Trolltech beneficiaire et continuant a developper Qt, que avec Trolltech en faillite et Qt en GPL sous windows.
Pour reprendre tes reponses:
- sisi, ca sert. La preuve en a ete donne par le passe.
- oui, mais ce serait deja un gros progres. Mathias avait l'air ouvert a l'idee d'avoir un moyen pour les projets open source de beneficier de Qt pour windows.
- oui et non. Il y a deux projets, un projet par cygwin/x11 et un projet pour porter Qt en natif.
[^] # Re: Une longue interview de Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 2.
Non, c'est un risque majeur pour Qt et ils font deja connaitre la GPL a des gens que ca interesse, a savoir la communaute Linux et la communaute Mac.
Quand ils ont sorti Qt non commercial, leurs ventes ont baisse dramatiqueemnt. Pourtant, je n'ai pas entendu parle de projet libre ou de freeware ayant achete Qt. Donc la baisse des ventes est bien liee a des boites qui n'ont pas achete Qt quand elles auraient du le faire.
> 1. Utilisation illicite volontaire (vente de produit commerciaux lié avec Qt
> version GPL), c'est possible mais si le produit marche ils payeront
> rapidement la license Qt pour ne pas rester dans l'illegalité.
C'est pas a Trolltech de financer le developpement de societe de logiciel. Surtout que pour une boite, c'est pas tres cher. En plus, beaucoup de ces societes servent des marches ultra-specialise dont personne n'entendra jamais parle. Trolltech ne recuperera pas le manque a gagner dans cette situation.
> 2. Utilisation illicite involontaire, c'est pas bien grave.
Ben si, c'est grave!
[^] # Re: Une longue interview de Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 1.
Tout ce ne fait pas une communaute suffisante pour interesser Trolltech. Ccompare au nombre de logiciels KDE, Qt, Gtk ou au nombre de logiciels disponibles sous Windows en shareware.
Pour que ca soit vraiment interessant pour Trolltech, il faut une communaute de developpeur pret a utiliser Qt, comme on en voit sous KDE.
Face a ce probleme de Qt/Windows, il y a trois solutions:
- continuer a faire chier Trolltech pour qu'ils releasent Qt sous GPL sous windows.
- demander comme l'a fait psi une licence speciale juste pour leur projet Open Source
- aider le portage en natif windows de Qt (kde-cygwin.sf.net)
- utiliser PyQt qui est abordable en prix (mais toujours pas gratuit)
- acheter le dernier bouquin sur Qt et obtenir Qt 3 non commercial pour windows.
- qui a dit que je savais compter ?
[^] # Re: Une longue interview de Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 1.
[^] # Re: Une longue interview de Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 1.
# Re: Une longue interview de Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 3.
http://linuxfr.org/2001/07/08/4170.html(...) et http://dot.kde.org/994553595/(...)
J'ai laisse peu de questions de cote.
[^] # Re: Traduction rapide de ce passage interressant, les motivations de l'auteur.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Microsoft se met à l'open-source. Évalué à 2.
Je rapproche l'attitude sympatique de ce developeur de celle d'un des mecs qui avait ete cite malgre lui dans les premiers documents halloween. Si je me souviens bien, il faisait une analyse de l'open source pour Bill Gates mais semblait pret a basculer du cote clair de la force:
<<
I'm a poorly skilled UNIX programmer but it was immediately obvious to me how to incrementally extend the DHCP client code (the feeling was exhilarating and addictive).
>>
[^] # Re: Traduction rapide de ce passage interressant, les motivations de l'auteur.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Microsoft se met à l'open-source. Évalué à 2.
Maintenant, si il change de boite et qu'il veut recuperer son soft pour y faire des modifs, il peut dans une certaine mesure en etre empeche par Microsoft.
Je placerai ca sur le manque d'habitude du logiciel libre.
[^] # Re: OpenOffice 1.1.1 française est sortie
Posté par Philippe F (site web personnel) . En réponse à la dépêche OpenOffice 1.1.1 française est sortie. Évalué à 4.
- utilisation du theme courant KDE pour dessiner les widget (ok, ca, c'est visuel)
- utilisation du dialogue de fichier KDE: consequence, tous les protocoles reseau supportes par KDE (ssh, ftp, http, ....) seront supportes
- utilisation du dialogue d'impression KDE
- integration sous forme de composant dans d'autres applications: oo pour ouvrir des documents words dans konqueror, c'est deja possible
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rencontre AFUP sur l'Extreme Programming. Évalué à 1.
> si tu codes pendant 6 mois et que le client change d'avis ?
Et bien comme tu as privilegie des releases courtes, on va dire de trois mois, le client a deja eu deux versions sous les yeux. Donc il a eu beaucoup plus le temps de se faire son avis. Notamment apres la permiere version, il a probablement change un peu d'avis et oriente la version suivante differamment. C'est le client qui choisit les fonctionnalites les plus prioritaires.
Comme tu as privilegie dans tes premieres versions les fonctionnalites qui avaient le plus de valeurs pour le client, il y a aussi toutes les chances que meme si il arrete le projet au bout de 6 mois pour raisons variees (budget en general), ce que tu as developpe est utilisable pour lui donc il va probablement le payer. Ca fait une grosse difference avec la methode UML ou le client sera peu enclin a te payer pour tes diagrammes UML.
Pour ce qui est de l'analyse, elle se fait dans un bureau avec tous les developpeurs et tous les clients. En revanche, la conception complete se fait plus tard. Dans la mesure ou on avance par iteration, ceratines parties de l'analyse n'ont pas besoin d'etre extermement pousee pour la premiere iteration ce qui allege la charge initiale et laisse plus de marge au client pour se faire une idee apres la premiere version.
Donc non seulement, le client peut changer d'avis au bout de 6 mois, mais meme on l'encourage.
Note aussi que comme tu as des suites de tests blindees, unitaires et fonctionelles, tu es beaucoup plus cool face au changement. Si la moitie des fonctionnalites change, l'autre moitie sera surement impactee mais tu seras en mesure de faire tourner les suites de tests deja developpee pour remettre l'ancienne moitie en etat avec les nouvelles fonctionnalites.
Globalement, XP te rend plus zen face aux problemes classiques de developpement. Si tu trouves un bug 1h avant de livrer la version finale au client, tu n'as pas peur de patcher comme un malade et de toute peter, car tu as tes suites de tests qui sont la pour te dire quand tu fais une connerie. Evidemment, dans ce cas, ca suppose aussi d'avoir un processus automatique de generation de release, ce qui, meme si il n'est pas presente dans la medhode, s'inscrit tout a fait dans l'esprit.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rencontre AFUP sur l'Extreme Programming. Évalué à 2.
Je tiens aussi a attirer l'attention sur le fait que "faire un test" n'a pas la meme signification pour tout le monde. Pour beaucoup, ca signifie avoir lance le logiciel et teste manuellement quelques patterns. Pour moi, ca signifie avoir developpe une suite de test que n'importe qui peut lancer pour valider ce tout marche. Donc quand on dit "mais je fais deja des tests", il est possible qu'on ne parle pas de la meme chose.
Sinon, je suis heureux de voir que ta boite a deja une bonne politique de tests. Cela qui contredit ta remarque initiale comme quoi XP est la somme des mauvaises pratiques du metier.
> si le code produit n'est pas immédiatement testable
C'est beaucoup beaucoup plus rare qu'on ne pense. Pour l'instant, je n'ai pas encore rencontre de situation ou c'est le cas. Pourtant, je travaille dans la carte a puce ou la seule facon de tester du code (avec une approche naive), c'est de le mettre dans un emulateur a 10000 euro et de lancer le debugger. Mais on a reussi sans probleme, avec un peu d'imagination, a tester toutes les couches de notre systeme d'exploitation pour carte a puce et tous les outils logiciels qui l'utilisent. Et en bonus, on a des tests securitaires impossible a mettre en place sur une vraie carte.
C'est possible de tester du code meme quand les couches basses ne sont pas encore disponibles et la-dessus, je suis sur que vous pourriez vous ameliorer. Evidemment, ca demande de repenser en general un peu l'architecture, mais le logiciel dans mon experience en sort grandement ameliore, en plus d'etre plus fiable. Je suis a ta disposition pour tout conseil si ca t'interesse (c'est gratuit)
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rencontre AFUP sur l'Extreme Programming. Évalué à 2.
Au dela du blabla sur les tests, la methodologie XP a fait naitre ou renaitre des bibliotheques permettant de faire des suites de tests. Si tu cherches sur sourceforge, toutes les libs de test que tu trouveras font references a XP: cppunit, junit, javaunit, mock, easymock, mockobjects, pyunit, ...
Pour ce qui est de l'analyse, il faut mettre ca en relation avec les nombreux projets professionnels ou tu dois pondre 6 mois de diagrammes UML avant de commencer la moindre ligne de code. Pas de bol, au bout de 7 mois, le client a change d'avis et tu peux mettre tous tes diagramme a la poubelle. C'est en ce sens la qu'il faut lire la priorite au code.
XP prone plutot que de faire 6 mois de diagramme, de faire une conception rapide et de trouver ensuite la fonctionnalite qui a le plus de valeur pour le client, et qu'on peut delivrer le plus rapidement. C'est celle la qui aura la priorite pour les premieres iterations.
Dans ton exemple de compte en banque, non, on ne commencerai pas par faire la gestion des comptes. On discuterai avec le client pour voir ce dont il a le plus besoin. Ca pourrait etre par exemple que le GUI de leur application actuelle est horrible et que c'est ce qui a motive la demande pour un nouveau systeme. Dans ce cas, on commencerai par refaire le GUI tout en s'appuyant sur l'ancien systeme, pour apporter un benefice immediat. Tu as un chance sur 10 avec une telle approche que le client te dise que finalement, avec le nouveau GUI, plus besoin de changer le systeme...
C'est pas bon pour ton job :-), mais le client a eu ce qu'il voulait. Ce que ca risque d'induire, c'est pas qu'on ne change pas le systeme, mais qu'on fasse des modifications moins drastiques que ce qui etait prevu.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rencontre AFUP sur l'Extreme Programming. Évalué à 4.
On peut planter ou reussir n'importe quel projet donc quelle que soit la methode de dev utilisee si on y met la volonte qu'il faut: un mauvais manager, des developpeurs qui s'en foutent ou imcomptents, des problemes qui ne sont pas remontes a temps, ... Dans ce cas, c'est pas Extrem Programming ou le methode machin-chose qu'il faut blamer.
> c'est un chateau de cartes constitué par toutes les mauvaises
> pratiques du développement logiciel
Je ne suis pas du tout d'accord. On parle bien de la meme methode la ? Ce que j'ai retenu d'XP:
- une tres forte pression sur les tests
- faire des releases courtes centrees sur le fonctionnalites les plus importantes pour le client
- de la transparence: faire une remontee tres rapide vers le client
- des tests encore
- faire un suivi pousse de la realisation des taches
Pour moi, ces methodes ne meritent pas le qualificatif "mauvaises pratiques de developpement". Au contraire, je pense qu'elles sont garantes de robustesse et pas mal de projet libre devrait s'en inspirer.
Pour l'instant, j'ai surtout applique le principe des tests a toutes les sauces, et tous mes projets logiciels en sont sortis plus fiables. J'ai commence sur un projet de 5000 lignes ou on a trouve un bug en 6 mois (pour l'implementation d'un protocole de transport). Le fais d'avoir fait des tests de toutes les couches de transport m'a permis de simuler des conditions normalement difficilement realisables par une approche de test 'classique' et m'a permis de lever des bugs assez sournois.
La, je suis sur un projet de 100 000 lignes a peu pres. Je suis tout seul et je dois avancer le plus vite possible sans pour autant me gourer. Mes partenaires apprecient _beaucoup_ mon emphase sur les tests et sont rassures quant a la qualite du projet justement a cause de ca. Ca m'a permis aussi de leur trouver beaucoup de bugs sur leur partie, qui ont ete mis en evidence la encore par les tests.
Bref, pour moi, XP a permis de faire des projets beaucoup plus solides et je n'envisage pas de developper sans reflechir en meme temps aux tests et aux fonctionnalites.
[^] # Re: Qt3 libre sous win
Posté par Philippe F (site web personnel) . En réponse à la dépêche Novell choisit Qt comme environnement de développement.. Évalué à 2.
Plus serieuseement, pour la personne qui disait vouloir utiliser gimp sous windows, voila la reponse. Certe, il faut installer cygwin mais tout linuxien sous windows l'a en general deja. Bon, sinon, niveau utilisabilite, je crois que c'est super lourd et lent.
[^] # Re: XCockroach ou comment les bugs envahissent le réseaux
Posté par Philippe F (site web personnel) . En réponse à la dépêche XCockroach ou comment les bugs envahissent le réseaux. Évalué à 1.
te donne le choix entre divers personnages qui se baladent sur la barre de tes fenêtres. Il y a notamment un petit chat qui saute dans tous les sens et qui te regarde en battant de la queue.
Il y a quelques années, je me souviens qu'il était possible de le faire utilise des personnages de quake 2. Je ne sais pas si c'est encore possible mais j'ai un copain qui l'avait fait a l'époque et c'était sympa.
[^] # Re: L'OpenSource par Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche L'OpenSource par Trolltech. Évalué à 1.
En ce qui concerne les problemes de licence, tu es l'auteur donc tu choisis vraiment la licence que tu veux. La GPL n'est pas toujours la plus adaptee quand on fait du business. C'est pas pour rien que Trolltech l'a evite pendant si longtemp. FAut voir que en tant qu'auteur, tu peux ne liberer qu'une partie de ton produit, sous la licence que tu veux. En general, ca laisse sufiisamment de souplesse.
Il faut aussi estimer l'interet pour la communaute. Si tu crois vraiment qu'une equipe de dev libres va s'interesser a ton produit, il ne faut pas que la licence soit du foutage de gueule. Mais si c'est le cas, ils te le diront et vous pourrez regler le probleme a ce moment-la.
[^] # Re: L'OpenSource par Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche L'OpenSource par Trolltech. Évalué à 1.
Pour ce qui est d'un portage d'application libre sous windows, on peut tenter l'aventure cygwin mais c'est quand meme assez lourd puisqu'il faut faire tourner un serveur XFree.
Cependant, une fenetre d'espoir s'est ouverte recmment: si vous achetez le bouquin sur Qt3, vous obtenez en prime Qt en version non commerciale pour windows. Je ne sais pas quelle licence y est attache, notamment en ce qui concerne la redistribution.
Donc pour resumer, Qt sous windows en logiciel libre, c'est Qt 2 non commercial ou bien la galere, au moins autant et probablement plus que pour faire du Gtk sous windows.
C'est pour ca que je recommendais plus haut d'utilise wxWidgets pour ce genre de chose. Cependant, wxWidgets reste quand meme inferieur a Gtk ou Qt en terme de paradigme de programmation. Donc vous allez galerer plus.
[^] # Re: L'OpenSource par Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche L'OpenSource par Trolltech. Évalué à 2.
Faire de l'argent en vendant un service sur du logiciel libre, c'est possible.
Faire de l'argent en vendant sous forme de logiciel libre une bibliotheque logicielle indispensable a la realisation d'un autre logiciel, c'est possible mais il faut bien faire attention.
Faire de l'argent en vendant un produit fini en tant que logiciel libre, ca n'est pas a mon avis viable economiquement.
Il semble que tu sois dans le deuxieme cas. Pour que ca marche, il faut que tes clients soient au final forces d'acheter la licence si ils ont l'intention d'utiliser le produit de facon majeure. En revanche, c'est une bonne idee d'encourager le particulier a developper avec votre appli chez lui le soir (si c'est a sa portee) pour favoriser la diffusion de votre outil.
Il y a pas de miracle, pour faire de l'argent, il faut quand meme a un moment forcer la main au client. Si tu donnes tout, il n'achetera rien.