Philippe F a écrit 2214 commentaires

Je suis d'accord. Je crois que j'ai déjà vu dans KDE un développeur qui ne voulait pas participer à un logiciel, justement si je me souviens bien parce qu'il était sous BSD et pas sous GPL. J'ai jamais revu le cas depuis donc c'est quand même à prendre à la légère.

Il y a vraiment que pour les entreprises ou ça joue beaucoup:

• BSD: pas de contraintes légale, ton soft sera facilement utilisé par l'entreprise mais il est pas sur qu'elle reverse quoi que ce soit. Il faut créer une motivation sous forme par exemple d'exclusion de la communauté si elle ne reverse pas.

• GPL: contraintes légales assez forte pour qu'une entreprise l'utilise mais protection plus ou moins bonne quant au risque de contribuer sans reverser.

Je suis à fond avec toi, on devrait interdire les gens de râler sur quoi que ce soit. Et comme les gens qui parlent toujours en bien des choses, c'est chiant aussi à la longue, on devrait interdire ça aussi.

Vive linuxfr, le forum où on interdira bientôt les commentaires !

Enfin quelqu'un qui répond sur le fond et pas sur le troll des détails de la GPL que je préférais éviter pour ce journal-là. Rien que pour ça: merci !

Je ne m'en prends pas aux rédacteurs de la GPL, je trouve juste que la GPL ne transmet pas les valeurs idéologiques du partage sans condition qui sont les miennes lorsque j'écris du code.

Il faudrait que je relise la lettre de Bill Gates mais c'est sur que j'aurai certainement eu du mal à le convaincre de quoi que ce soit: son opinion était déjà certainement toute formée.

Je fait mon premier commentaire à mon journal: ma réflexion de fond dans ce journal est plutôt philosophique, mais cela fonctionne très bien aussi en pratique.

Les logiciels sous licence type BSD reçoivent tout autant de contributions extérieures que ceux sous GPL. Je pense par exemple à Apache, ou encore à LLVM qui fait concurrence à GCC. Apple contribue à LLVM alors que rien ne l'y oblige dans la licence, et que cette société est connue pour ne pas être philanthropique. Les problèmes brandis par les ardents défenseurs de la GPL n'ont pas l'air d'avoir stoppé ni Apache, ni LLVM, ni les autres projets à base de BSD (X.org , FreeBSD, …).

Si tu mets un programmeur qui ne connait pas Python devant un programme Python, il arrive en général à le comprendre (quoique les "list-comprehensions" ont un peu relevé le niveau). Tu n'a jamais cet effet là devant un programme Perl.

Dans tout langage, tu peux écrire très lisiblement et de façon obtuse. Après, il y a la moyenne et le style encouragé par le langage. Perl clairement encourage un style cryptique pour qui ne parle pas le Perl. La même chose peut être dit du LISP, mais certainement pas du PHP, Java ou C#.

Je suis en train de faire un bricolage en bash pour couvrir exactement ce besoin (mais nous en interne, on fait du mercurial dommage !).

La livraison d'un logiciel sur un serveur est souvent complètement sous-estimée en terme de difficulté, archivage, vérification, etc etc. Surtout quand tu as envie de faire des livraisons fréquentes - cas assez courant dans les applis web.

Donc un outil est le bienvenue, de mon point de vue, dommage que ce soit du git et pas autre chose.

L'autre solution que je regarde de plus près, c'est de faire du PAAS mais l'offre française sur le sujet est très limitée.

C'est une victoire car l'appli est plus performante et mieux foutue que tous les clients lourds que j'ai utilisé pour ce type de besoin. Alors même qu'il est bien plus difficile de faire cela en client léger ou client web dans ce cas.

client lourd, client léger sont des expressions classique pour distinguer des architectures logiciel, tout comme les expressions "client-serveur" ou "peer-to-peer".

En fait, je dis que j'ai un besoin précis que Lucidchart remplit et que je n'ai jamais trouvé d'autre logiciels pour le faire et tu me dis en essence que je suis trop con, je ne comprends pas mon besoin, Inkscape et Dia le remplissent très bien. Et bien non, une application c'est plus qu'une liste de check box devant des fonctionnalités. As-tu lu ce que je dis sur l'ergonomie, le temps de prise en main, la qualité du rendu, la disponibilités de formes prêtes adaptées à mon besoin ?

Sinon, xfig faisait déjà ça il y a 15 ans, et je l'utilisais déjà. Je suis vraiment trop con de pas continuer vraiment… D'ailleurs, je vois pas pourquoi des débiles développent Dia et Inkscape, xfig fait déjà tous ce qu'ils prétendent faire, et ce depuis bien longtemps.

Je connais pas la pile technologique utilisée par l'appli. Il m'a pas semblé voir de flash, mais il peut y avoir tellement de raisons pour qu'une appli ne marche pas sous Linux… Surtout une appli réactive comme ça, je peux imaginer qu'elle ailler cherche le max de perf du navigateur et qui dit max de perf dit risque d'incomaptibilité…

Par contre elle marche sous FreeBSD, mais je suis toujours pas "on-topics" sur LinuxFR. Ah zut alors… Bon en fait je déconne, j'ai aucune idée si ça marche sous BSD.

Tu galères sous Windows:
* parce que tu fais des optimisations à deux balles. A part les agités du linux, aujourd'hui, télécharger 200 Mo, c'est rien du tout. Je travaille régulièrement avec des utilisateurs lambda qui téléchargent une JVM pour faire tourner une appli. No problem ! Et je te parles bien du papy qui est sur le web. Donc exit la compilation statique ! Fait juste un installeur qui compresse à mort tes binaires et basta.

• parce qu'il y a du savoir-faire spécifique à Windows que tu n'as pas. Mais c'est pas lié à Windows, c'est juste lié au fait que tu es un développeur inexpérimenté sous Windows. Un développeur inexpérimenté sous Linux galerera (à mon avis beaucoup plus que tu ne le fais pour Windows). Et idem pour MacOs. Oui, il y a des choses à savoir pour déployer sous Windows, mais infiniment moins à mon avis que pour déployer sous Linux.

• parce que tu fais des choix techniques douteux. Compiler avec mingw sous Windows, c'est un peu comme installer un .deb sur une Fedora. C'est faisable mais vaut mieux pas. Les compilateurs de Windows sont disponibles en ligne de commande gratuitement, ça s'appelle les versions Express: http://www.microsoft.com/visualstudio/fra/products/visual-studio-express-products . De même sous MacOs, il est fortement recommandé de compiler avec le gcc livré avec ta version de MacOs. Sinon … problèmes subtils et pénibles. Et c'est pas la dernière version de gcc, tu peux me croire…

• tu penses que tu ne galères pas sous Linux, mais as-tu fais un paquet qui s'installe déjà sur toutes les distributions majeures, en LTS et dernière version ? Ton application a-t-elle survecue à la mise à jour de la distrib lancée par le geek bleeding edge ? Reviens nous voir Zenitram et moi quand tu te seras farcie la réalité de la distribution sous Linux on reparlera du "je galère que sous Linux".

• une autre raison pour galérer sous Windows, c'est d'utiliser des technos pas portable. Genre au hasard Gtk (ouh le petit troll) mais il y en a d'autres… . La plupart des applis Gtk ne sont plus packagées sous Windows, tous les développeurs ont jeté l'éponge… Et je te dit ça, c'est quand elles sont pas carrément passées à Qt.

1) Un client lourd : peut être simple à installer […]

Euh, c'est une blague ?

A part sous Windows où un client lourd est effectivement simple à installer la première fois, l'installation d'un client lourd est le problème numéro 1 des clients lourds.

Allons-y:
1. Sous Linux, c'est un tel bordel de distribution, version de la libc, version compatible de ta pile graphique que tu peux y passer des mois. Cf tous les posts de Zenitram sur le sujet.

1. Sous Windows, c'est relativement simple si ton utilisateur n'est pas dans un environnement professionnel contraint (genre pas les droits administrateurs). Sinon, c'est vite la zone.

2. Sous Mac, je crois que c'est relativement simple mais il faut découvrir la plate-forme et acquérir du savoir Apple.

3. Quand tu veux faire une mise à jour, le début du cauchemar commence. Comment encourager -forcer- ses utilisateurs à utiliser la bonne version ?

4. Au final, vive les App Store, qui ont au moins la vertu de permettre des mises à jour faciles.

On savait tous que traduire une interface en français pose un problème de place, mais là on a des stats concrètes.

Je note que en gros, il faut doubler la place pour faire tenir la majorité des textes anglais en français dans une interface graphique. Oups…

c'est plus de la comparaison GTK vs Qt, c'est de la comparaison C vs C++.

Je vais faire mon Zenitram : c'est vraiment de le pure mauvaise foi pour ne pas reconnaître une très grosse faiblesse de Gtk: c'est fait en C et ça pue pour l'héritage et plus généralement les fonctionnalités Objet.

On parle bien de comparer Gtk avec son implémentation de référence et Qt avec son implémentation de référence. Et pas d'un binding Gtk quelconque avec Qt, ou d'un binding Qt quelconque avec Gtk.

Et de fait, Gtk utilise une sur-couche par dessus le C pour faire de l'objet, et bien que ce soit fait intelligemment, ça reste très moche et limité. Il faut écrire un km de code pour faire de l'héritage, et on en a besoin de l'héritage si on fait une application évoluée.

Pour faire un reproche équivalent à Qt (et me dédouaner de toute accusation de partialité), on peut reprocher à Qt le fait de n'être pas du C++ mais du C++ avec une surcouche gérée par l'outil Moc.

Je ne te répondrai pas que le reproche est débile, et qu'il faudrait comparer boost.signal avec Qt pour être honnête (comme tu viens de le faire). Ou bien que tu n'as qu'à faire du PyQt où le moc n'est pas utilisé.

C'est vrai que Moc est indispensable pour faire du Qt, mais ça permet de pallier avec élégance (et une petite complexité à la compilation) à un manque de fond du C++.

Un des clients mercurial les mieux foutus que j'ai rencontré a aussi migré de Gtk a Qt. On vous l'avait dit il y a 10 ans, vous ne vouliez pas nous croire !

Pour moi, l'argument no 1 de Qt reste la portabilité. Il y a beaucoup d'autres atouts mais pour une application moyenne développée en Gtk, la partie graphique de Qt même si elle est plus simple ne fera pas un tel différentiel. La différence se voit surtout :
- pour des applis complexes
- dès que tu veux porter sous Windows

Là, c'est assez violent. Le portage de Gtk sous Windows reste une grosse grosse difficulté.

C'est plus juste en effet, en ajoutant que c'est un bureau Gnome portable sous Windows, MacOs, tous les unix et Android, avec un look natif sur toutes les plate-formes citées.

Développeur / testeur, c'est un peu limité. J'aurai plutôt mis une option "développement logiciel", avec la possibilité pour les développeurs, les testeurs, les chefs de projets, les architectes logiciels de faire ce choix.

lpod est très intéressant mais semble très léger sur les exemples de fichier spreadsheet. Les tutoriaux ne repondent pas aux questions suivantes :
- comment inclure une formule
- comment formatter une cellule
- comment faire immobiliser des lignes dans l'affichage

Mais en tout cas, il y a une base et c'est intéressant.

Merci pour ces réponses claires.

Désolé de ne pas participer au développement de ODF et LO mais pour le coup, je me place dans la position d'un simple utilisateur. J'ai mentionné SOMMESIENS mais ce n'est pas la seule fonction Excel 2010 qui manque à LibreOffice. Je pense que des gens plus calés que moi sauront en sortir une liste exhaustive, c'est pas comme si la documentation Microsoft sur ce sujet n'était pas accessible en ligne.

Honnêtement, je n'utilise pas LibreOffice car j'ai besoin d'être très productif à mon travail et que il n'est pas à la hauteur des solutions Microsoft. Autant il y a 10 ans, je faisais tout sous OO et je perdais presque rien par rapport à Word, Excel et autres, autant aujourd'hui, en terme de convivialité, LibreOffice est très très loin du compte et je convertis tous mes documents sxc et sxw en fichiers Office.

Pour la barre de statut, je ferai la demande par les voies officielles.

Je suis d'accord.

Pour prendre un exemple pratique, les 3/4 de mes feuilles de calcul utilisent des sommes avec condition. J'utilise donc la fonction très pratique SOMME.SI.ENS() qui permet de faire la somme d'une plage de données en fonction d'une multitude de critères provenant de plusieurs autres plages de données. Mais cette fonction n'est pas présente sous LO, quel dommage…

L'autre truc pratique, c'est par exemple de sélectionner une plage de valeur et de regarder sur la barre de statut la somme, le nombre de valeurs et leur moyenne en un coup d'oeil. Et de comparer ça vite fait avec une autre plage. Sous LO, c'est vaguement possible, mais tu ne peux voir que une seule information à la fois: soit la somme, soit la moyenne, soit le nombre de valeurs. Bof bof bof.

Et des détails comme ça, il y en a des tonnes. C'est un somme de détails qui fait un bon produit et on peut dire que dans l'ensemble LO a les fonctionnalités de bases, mais sur la somme de détails, il est à la rue!

Est-ce qu'il y a un bon lecteur et générateur de feuilles de calcul en Python ? J'utilise http://www.python-excel.org/ mais j'ai l'impression que côté format libre, c'est un peu la misère. Et pitié, pas de solution à la "tu fais tourner libreoffice et …", c'est pour mettre sur un serveur où il n'y a pas X.

Tu oublies l'immense pollution que génère leur fabrication et leur rapide obsolescence. Malheureusement, les fours qui font le café et qui poste sur twitter commencent à leur faire de la concurrence en terme de pollution !

Ca prouve que ceux qui défendaient Gnome avaient tort et qu'ils devraient immédiatement faire des excuses à tous les développeurs KDE et tous les trolleurs KDE / Qt de LinuxFr. Quand je vois d'ailleurs le ton agressif avec lequel ils se sont débattus, je me demande d'ailleurs si il y aurait pas là un sujet de mise en demeure ! Ils ont clairement nuit à la réputation d'un projet honorabl. Je vais de ce pas en parler à KDE et vous pouvez vous attendre à un avis d'huissiers fissa !

Si je ne m'abuse, ça fait plusieurs logiciels qui passent de Gtk à Qt ces derniers temps, principalement pour cause des problèmes sur le port Windows.

Ahhh… si j'avais pu sortir ces exemples il y a 10 quand on trollais sur Qt, Gtk, KDE et Gnome, ça en aurait fait taire plus d'un !

C'est écologique au moins sur l'aspect durée de vie: perso, je fais de temps en temps du pain (à peu près sans recette) et il dure facilement 4 jours, voire une semaine si t'as des bonnes dents. Ca fait pas mal de trajets éliminés l'air de rien.

Quand je dis faire des trucs façon printf, je mets la barre un peu plus haut que afficher juste un float:

QString s; s.sprintf("Nous sommes le %02d/%02d/%04d, le total de votre facture est %0.2f", day, month, year, totalTtc );

La version recommandée est plutôt:

QString s("Nous sommes le %1/%2/%3, le total de votre facture est %4").arg(day,2,'0').arg(month,2,'0').arg(year,4,'0').arg(totalTtc,0,'f',2,'0')

Vas-y en STL, je compte les lignes.

Je veux bien voir la conversion d'encodage aussi, juste pour rire.

La STL, ça reste quand même un truc limite académique, avec une utilité pratique très limitée. Dès que tu fais un programme qui intéragit avec le monde extérieur, ce sera très très très insuffisant. Heureusement, il y a des framework qui tiennent la route pour boucher les trous, comme boost. D'ailleurs si tu regardes de près dans boost, il doit plus rester beaucoup de STL, je pense qu'on peut lui faire le même procès qu'à Qt.

Je voulais surtout souligner que pour faire du GUI et pour faire de l'asynchrone, le besoin n'est pas comme semble l'indiquer le commentaire précédent "les threads" mais une bonne boucle d'évenement.

Les threads sont utiles pour gérer une tâche longue sans bloquer le GUI (calcul, IO), mais pas pour faire un bon GUI réactif.

Trop de gens pensent que les threads sont la panacée de l'asynchrone, à tort !

Pour ce qui est de l'intégration des threads dans Qt, j'ai un peu décroché depuis Qt3 mais à l'époque, je trouvais ça pas très naturel vis a vis du fonctionnement du reste du framework. Il y avait des limitations. Beaucoup de progrès ont été fait depuis et c'est très bien !

Tu as besoin d'asynchrone. Tu as besoin de thread.

Tu as surtout et avant tout besoin d'une bonne boucle d'évènement. D'ailleurs les threads ont été rajoutés très tardivement dans Qt, genre dans Qt 3. Et globalement, ca reste peu recommandé.

Par contre, avoir un évènement "rappelle-moi quand il y a des données sur ma socket sans bloquer le GUI en attendant", c'est top et ca se fait sans threads…