L'auteur a cité par exemple le côté assez dynamique des composants, que tu peux plus ou moins ajouter et retirer à la volée. Est-ce que les traits permettent ce niveau de flexibilité ?
Il ne s'agit pas de fonctions qui n'ont pas le même nom. Je m'en serai sorti sans problème, d'autant plus que LO/OO convertit ajuste les noms au moment de charger le fichier.
J'ai testé la version installé sur mon poste, 3.5 et la fonction ne marche pas et n'existe pas. L'aide de mon LO n'en parle pas. L'aide officielle de LO n'en parle pas non plus. Je télécharge vite fait la dernière version pour voir si c'est une addition récente.
SOMMEPROD ne fait pas la même chose que SOMME.SI.ENS même si au final, on arrive au même résultat, l'approche est assez déroutante.
Donc la prochaine fois que tu diras à quelqu'un de migrer de MSO à LO/OO, rappelle toi bien que ce n'est peut-être tout simplement pas possible…
Je l'utilise sous Windows XP. Globalement, il me semble qu'il marche bien, et mieux avec des fichiers OOXML quand tu le pousses dans ses retranchements. Et il est pas exempt de bugs non plus, seulement je trouve que le produit tient bien la route. De l'eau a coulé sous les ponts depuis le temps où je flippais à chaque sauvegarde sur disquette de mes rapports en école d'ingé…
Sinon, pour le jour où je dois faire la transition vers Python + autre chose, des recommendations ? J'aimerai faire des graphiques vraiment sexy (marketing) et pas juste des graphiques scientifiques. Il me semble que matplotlib est plutôt très orienté scientifique.
Je suis développeur Python et Qt. Si je pense que développer un programme est une bonne approche, je le fais. Sauf que là, Excel / OO a résolu en deux fois deux heures, un problème que j'aurai mis plusieurs jours à résoudre en python. Donc oui, Excel n'est pas forcément le meilleur outil pour un tel volume de donnée, mais force est de constater qu'il s'en sort à merveille et que j'ai pu passer 1,5 jours de ma vie sur d'autres sujets que ce problème là.
J'utilise OpenOffice puis LibreOffice depuis des années. Je suis par contre passé à Office 2010 en raison de la supériorité technique (que je trouve personellement incontestable) de la suite. J'ai encore des anciens documents en OOCalc et OOWrite et vraiment, c'est à chaque fois pénible de travailler dessus.
Je n'ai pas fait une étude objective argumentée de LibreOffice vs Office 2010. Simplement, des fonctions que j'utilise au quotidien parce qu'elles sont bien pratiques sont manquantes dans OO. La prétention d'avoir une compatibilité avec Office est simplement un mensonge. Il existe apparamment une fonction incompatible, que je n'ai pas trouvé dans la doc, qui peut faire la même chose dans la plupart des cas. Bof ! J'ai mis environ 5 minutes pour découvrir la fonction SOMME.SI.ENS sous Office (grâce à l'aide qui est bien foutue) et je l'utilise intensément, et ça m'a permis de découvir NB.SI.ENS que j'utilise tout aussi intensément. Mais bon, il est vrai que ce que j'ai fait un 5 minutes sous Office, j'aurai pu le faire en une demi-journée de recherche dans l'aide de OpenOffice et des forums. Car au départ, je ne connaissais pas le nom de la fonction que je cherchais, c'est l'aide qui m'a orienté.
OpenOffice fournit les fonctions SOMME.SI et NB.SI (compatibles Excel) mais oublie SOMME.SI.ENS et NB.SI.ENS . Dommage, ça encourage pas les utilisateurs à migrer facilement.
Je n'ai jamais dit que OO est de la m**** et jamais je ne me permettrai ce genre d'agression, contrairement à l'auteur de ce journal. Par contre, je dis que de mon point de vue Office 2010 est très largement supérieur à LibreOffice. Et l'écart va continuer à se creuse à mon avis, malgré toutes les bonnes volonté derrière LO.
Je suis pas super convaincu par tes liens. J'ai pas l'impression que SOMMEPROD soit une fonction portable. Que se passera-t-il si j'exporte mon fichier OO en xlsx ?
Pour les 100 000 lignes, c'est juste que il me faudrait une à deux journées pour écrire un programme en python que me fasse des graphiques aussi simples à produire que Excel. Il faut aussi que je puisse le mettre à jour de façon simple et là j'utilise un export CSV d'un autre logiciel.
A partir de ces 100 000 lignes, je produis une dizaines de graphiques, semaine par semaine: ça m'a une demi-journée à mettre en place. Quand je serai à 500 000 lignes, je réfléchirai à une meilleure solution.
Cela dit, j'ai pas exploré tout LucidChart. Il sait faire des diagrammes UML et deux trois autres trucs classiques, il y a peut-être des tableaux là-dedans.
C'est un peu original ton besoin de faire des tableaux, tu peux expliciter un peu comment tu t'en sers. Dans mon cas, c'était juste pour faire un mockup de rapport avec lignes et colonnes.
Plutôt oui (Dia fait plutôt des trucs moches). C'est pas tant qu'il ne soit pas possible de faire des jolies choses avec Dia, c'est que une tanche en graphisme comme moi n'arrivera pas à faire un truc beau avec.
Parmi les autres aspects importants, citons :
* l'ergonomie
* la courbe d'apprentissage qui doit décoller très vite
* l'accès à une bibliothèque riche de formes cohérentes
* les fonctionnalités intrinsèque.
Après, il y a des détails comme le fonctionnement sous Windows qui ne sont jamais complètement négligeable dans un cadre professionnel.
Pas de tableau de base en effet, mais je viens d'en faire un pour un autre besoin. Tu groupes des rectangles, et tu peux bien avoir un point d'ancrage intelligent : mileu ou bord du rectangle. C'est pas la panacée mais ça marche très bien.
Je ne parle pas de bases de données, je parle d'un logiciel qui marche bien Excel, que j'utilises avec succès pour mes besoins alors que LibreOffice n'y arrive pas. L'article original disait que MSO, c'est de la m****. Je prétends que c'est un bon logiciel pour ce type de raison.
Et sans même entrer dans les bugs, il manque à LOCalc des fonctions de calculs de base
Question: vaut il mieux plus de fonctions mathematiques fausse ou moins de fonctions juste?
Quel est le rapport avec le choucroute ? Il manque une fonction de base dans LibreOffice, une fonction que j'utilise à peu près sur toutes mes feuilles de calcul et qu'il n'est pas possible d'émuler. Cette fonction est mathématiquement juste dans Excel, et mathématiquement absente dans LibreOffice.
Curieux, je suis allé voir la techno derrière cette appli qui a l'air sympatique et portable partout. Je me serai attendu à du Qt, mais c'est du XUL. Est-ce que ça veut dire que l'appli est écrite en javascript ?
Je la lance sous Windows et hop, elle se positionne de sorte que la barre de fenêtre et barre de menu est en dehors de mon écran. Impossible de la déplacer ou de la redimensionner avec des moyens classiques. Il y a pas à dire, XUL, c'est de la techno solide !
Il y a longtemps, il y avait aussi un logiciel sur Mac qui s'appelait Draw et qui était aussi d'une convivialité inégalée. Je sais qu'en école d'ingé, on allait sur le Mac juste pour pouvoir l'utiliser et taper le reste de notre rapport sous Word.
Une confirmation de plus qu'il y a plus de designers sour Mac (en tout cas à l'époque) que sous PC.
Je réagis juste sur la partie "Canal carpien". Je constate au quotidien que je passe beaucoup moins de temps à déplacer ma souris quand je travaille sous Word ou Excel que sous LibreOffice. Oui, le ruban est un peu déroutant de prime abord, tout comme peut l'être une première utilisation de Linux après n'avoir fait que du Windows toute sa vie. Mais toutes les fonctions communes sont groupées, facilement accessibles, avec une logique assez raisonnable.
J'imagine qu'ils ont dépensé quelques centaines de milliers de dollar à mesurer le temps de parcours de la souris avec et sans ruban avant de l'accepter définitivement. De mon côté en tout cas, c'est LibreOffice qui me nique le canal carpien.
A chaque fois que j'installe un nouveau LibreOffice / OpenOffice, je passe d'ailleurs 10 minutes à rajouter les fonctions les plus utilisées sur la barre d'outil, mais je suis ennuyé car celle-ci commence à prendre une place monstrueuse et que je ne peux plus visualiser mon document correctement. Je trouve la solution de Ms astucieuse.
En tout cas, quand c'est blender ou Gimp ou xfig (bienvenue aux papys) qui a une interface atypique, la plupart des libristes se battent pour reconnaître l'utilité, l'originalité et l'efficacité de l'interface atypique et râle sur ceux qui veulent un truc classique avec des menus et des boutons. Mais si jamais c'est Microsoft qui fait le même choix, oula, c'est forcément de la m***** . Faudrait sortir un peu de votre unité centrale de temps en temps.
LibreOffice vs Office 2010, c'est un peu LXDE vs KDE. L'un marche beaucoup mieux, mais il ne fait pas le dixième de ce que fait l'autre. Donc c'est sur, ça marche, mais ça met pas la barre très haut.
De mon côté par exemple, Excel 2010 absorbe sans problèmes des tableaux croisés de 100 000 lignes alors que sur LibreOffice, ça rame ça rame ça rame.
Et sans même entrer dans les bugs, il manque à LOCalc des fonctions de calculs de base ( somme.si.ens par exemple ) qui font qu'il est simplement pas utilisable pour des feuilles de calcul un peu complèxes. Pas de bol, j'utilise cette fonction à tort et à travers (ca permet de faire une somme sur plusieurs critères, au lieu de un seul critère avec somme.si ).
LODraw est à des années lumières de PowerPoint en terme de facilité d'utilisation.
Office n'est pas exempt de bugs ni d'incohérences, mais à part les libristes que se lavent le cerveau eux-même, il est facile de se rendre compte que Office est tout simplement un produit de meilleur qualité.
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.
[^] # Re: Et les traits ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 3.
L'auteur a cité par exemple le côté assez dynamique des composants, que tu peux plus ou moins ajouter et retirer à la volée. Est-ce que les traits permettent ce niveau de flexibilité ?
[^] # Re: PS
Posté par Philippe F (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 2.
Il ne s'agit pas de fonctions qui n'ont pas le même nom. Je m'en serai sorti sans problème, d'autant plus que LO/OO convertit ajuste les noms au moment de charger le fichier.
Il s'agit de fonctions qui sont tout simplement absentes. D'ailleurs, elles ne sont pas dans l'aide :
https://help.libreoffice.org/Calc/Mathematical_Functions/fr#SOMME.SI
J'ai testé la version installé sur mon poste, 3.5 et la fonction ne marche pas et n'existe pas. L'aide de mon LO n'en parle pas. L'aide officielle de LO n'en parle pas non plus. Je télécharge vite fait la dernière version pour voir si c'est une addition récente.
SOMMEPROD ne fait pas la même chose que SOMME.SI.ENS même si au final, on arrive au même résultat, l'approche est assez déroutante.
Donc la prochaine fois que tu diras à quelqu'un de migrer de MSO à LO/OO, rappelle toi bien que ce n'est peut-être tout simplement pas possible…
[^] # Re: PS
Posté par Philippe F (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 3.
Je l'utilise sous Windows XP. Globalement, il me semble qu'il marche bien, et mieux avec des fichiers OOXML quand tu le pousses dans ses retranchements. Et il est pas exempt de bugs non plus, seulement je trouve que le produit tient bien la route. De l'eau a coulé sous les ponts depuis le temps où je flippais à chaque sauvegarde sur disquette de mes rapports en école d'ingé…
[^] # Re: PS
Posté par Philippe F (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 4.
Sinon, pour le jour où je dois faire la transition vers Python + autre chose, des recommendations ? J'aimerai faire des graphiques vraiment sexy (marketing) et pas juste des graphiques scientifiques. Il me semble que matplotlib est plutôt très orienté scientifique.
[^] # Re: PS
Posté par Philippe F (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 7.
Alors, il y a clairement une méprise.
Je suis développeur Python et Qt. Si je pense que développer un programme est une bonne approche, je le fais. Sauf que là, Excel / OO a résolu en deux fois deux heures, un problème que j'aurai mis plusieurs jours à résoudre en python. Donc oui, Excel n'est pas forcément le meilleur outil pour un tel volume de donnée, mais force est de constater qu'il s'en sort à merveille et que j'ai pu passer 1,5 jours de ma vie sur d'autres sujets que ce problème là.
J'utilise OpenOffice puis LibreOffice depuis des années. Je suis par contre passé à Office 2010 en raison de la supériorité technique (que je trouve personellement incontestable) de la suite. J'ai encore des anciens documents en OOCalc et OOWrite et vraiment, c'est à chaque fois pénible de travailler dessus.
Je n'ai pas fait une étude objective argumentée de LibreOffice vs Office 2010. Simplement, des fonctions que j'utilise au quotidien parce qu'elles sont bien pratiques sont manquantes dans OO. La prétention d'avoir une compatibilité avec Office est simplement un mensonge. Il existe apparamment une fonction incompatible, que je n'ai pas trouvé dans la doc, qui peut faire la même chose dans la plupart des cas. Bof ! J'ai mis environ 5 minutes pour découvrir la fonction SOMME.SI.ENS sous Office (grâce à l'aide qui est bien foutue) et je l'utilise intensément, et ça m'a permis de découvir NB.SI.ENS que j'utilise tout aussi intensément. Mais bon, il est vrai que ce que j'ai fait un 5 minutes sous Office, j'aurai pu le faire en une demi-journée de recherche dans l'aide de OpenOffice et des forums. Car au départ, je ne connaissais pas le nom de la fonction que je cherchais, c'est l'aide qui m'a orienté.
OpenOffice fournit les fonctions SOMME.SI et NB.SI (compatibles Excel) mais oublie SOMME.SI.ENS et NB.SI.ENS . Dommage, ça encourage pas les utilisateurs à migrer facilement.
[^] # Re: PS
Posté par Philippe F (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 1.
Je suis pas super convaincu par tes liens. J'ai pas l'impression que SOMMEPROD soit une fonction portable. Que se passera-t-il si j'exporte mon fichier OO en xlsx ?
Pour les 100 000 lignes, c'est juste que il me faudrait une à deux journées pour écrire un programme en python que me fasse des graphiques aussi simples à produire que Excel. Il faut aussi que je puisse le mettre à jour de façon simple et là j'utilise un export CSV d'un autre logiciel.
A partir de ces 100 000 lignes, je produis une dizaines de graphiques, semaine par semaine: ça m'a une demi-journée à mettre en place. Quand je serai à 500 000 lignes, je réfléchirai à une meilleure solution.
[^] # Re: Tableau
Posté par Philippe F (site web personnel) . En réponse au journal LucidChart - deux mois après. Évalué à 2.
Cela dit, j'ai pas exploré tout LucidChart. Il sait faire des diagrammes UML et deux trois autres trucs classiques, il y a peut-être des tableaux là-dedans.
C'est un peu original ton besoin de faire des tableaux, tu peux expliciter un peu comment tu t'en sers. Dans mon cas, c'était juste pour faire un mockup de rapport avec lignes et colonnes.
[^] # Re: Retour sur investissement
Posté par Philippe F (site web personnel) . En réponse au journal LucidChart - deux mois après. Évalué à 7.
Plutôt oui (Dia fait plutôt des trucs moches). C'est pas tant qu'il ne soit pas possible de faire des jolies choses avec Dia, c'est que une tanche en graphisme comme moi n'arrivera pas à faire un truc beau avec.
Parmi les autres aspects importants, citons :
* l'ergonomie
* la courbe d'apprentissage qui doit décoller très vite
* l'accès à une bibliothèque riche de formes cohérentes
* les fonctionnalités intrinsèque.
Après, il y a des détails comme le fonctionnement sous Windows qui ne sont jamais complètement négligeable dans un cadre professionnel.
[^] # Re: Tableau
Posté par Philippe F (site web personnel) . En réponse au journal LucidChart - deux mois après. Évalué à 1.
Pas de tableau de base en effet, mais je viens d'en faire un pour un autre besoin. Tu groupes des rectangles, et tu peux bien avoir un point d'ancrage intelligent : mileu ou bord du rectangle. C'est pas la panacée mais ça marche très bien.
[^] # Re: PS
Posté par Philippe F (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 3.
Je ne parle pas de bases de données, je parle d'un logiciel qui marche bien Excel, que j'utilises avec succès pour mes besoins alors que LibreOffice n'y arrive pas. L'article original disait que MSO, c'est de la m****. Je prétends que c'est un bon logiciel pour ce type de raison.
Quel est le rapport avec le choucroute ? Il manque une fonction de base dans LibreOffice, une fonction que j'utilise à peu près sur toutes mes feuilles de calcul et qu'il n'est pas possible d'émuler. Cette fonction est mathématiquement juste dans Excel, et mathématiquement absente dans LibreOffice.
[^] # Re: Retour sur investissement
Posté par Philippe F (site web personnel) . En réponse au journal LucidChart - deux mois après. Évalué à 2.
Curieux, je suis allé voir la techno derrière cette appli qui a l'air sympatique et portable partout. Je me serai attendu à du Qt, mais c'est du XUL. Est-ce que ça veut dire que l'appli est écrite en javascript ?
Je la lance sous Windows et hop, elle se positionne de sorte que la barre de fenêtre et barre de menu est en dehors de mon écran. Impossible de la déplacer ou de la redimensionner avec des moyens classiques. Il y a pas à dire, XUL, c'est de la techno solide !
[^] # Re: Retour sur investissement
Posté par Philippe F (site web personnel) . En réponse au journal LucidChart - deux mois après. Évalué à 1.
Il y a longtemps, il y avait aussi un logiciel sur Mac qui s'appelait Draw et qui était aussi d'une convivialité inégalée. Je sais qu'en école d'ingé, on allait sur le Mac juste pour pouvoir l'utiliser et taper le reste de notre rapport sous Word.
Une confirmation de plus qu'il y a plus de designers sour Mac (en tout cas à l'époque) que sous PC.
[^] # Re: Ergonomie
Posté par Philippe F (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 2.
Je réagis juste sur la partie "Canal carpien". Je constate au quotidien que je passe beaucoup moins de temps à déplacer ma souris quand je travaille sous Word ou Excel que sous LibreOffice. Oui, le ruban est un peu déroutant de prime abord, tout comme peut l'être une première utilisation de Linux après n'avoir fait que du Windows toute sa vie. Mais toutes les fonctions communes sont groupées, facilement accessibles, avec une logique assez raisonnable.
J'imagine qu'ils ont dépensé quelques centaines de milliers de dollar à mesurer le temps de parcours de la souris avec et sans ruban avant de l'accepter définitivement. De mon côté en tout cas, c'est LibreOffice qui me nique le canal carpien.
A chaque fois que j'installe un nouveau LibreOffice / OpenOffice, je passe d'ailleurs 10 minutes à rajouter les fonctions les plus utilisées sur la barre d'outil, mais je suis ennuyé car celle-ci commence à prendre une place monstrueuse et que je ne peux plus visualiser mon document correctement. Je trouve la solution de Ms astucieuse.
En tout cas, quand c'est blender ou Gimp ou xfig (bienvenue aux papys) qui a une interface atypique, la plupart des libristes se battent pour reconnaître l'utilité, l'originalité et l'efficacité de l'interface atypique et râle sur ceux qui veulent un truc classique avec des menus et des boutons. Mais si jamais c'est Microsoft qui fait le même choix, oula, c'est forcément de la m***** . Faudrait sortir un peu de votre unité centrale de temps en temps.
[^] # Re: Ça fait envie
Posté par Philippe F (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 4.
LibreOffice vs Office 2010, c'est un peu LXDE vs KDE. L'un marche beaucoup mieux, mais il ne fait pas le dixième de ce que fait l'autre. Donc c'est sur, ça marche, mais ça met pas la barre très haut.
[^] # Re: PS
Posté par Philippe F (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 4.
De mon côté par exemple, Excel 2010 absorbe sans problèmes des tableaux croisés de 100 000 lignes alors que sur LibreOffice, ça rame ça rame ça rame.
Et sans même entrer dans les bugs, il manque à LOCalc des fonctions de calculs de base ( somme.si.ens par exemple ) qui font qu'il est simplement pas utilisable pour des feuilles de calcul un peu complèxes. Pas de bol, j'utilise cette fonction à tort et à travers (ca permet de faire une somme sur plusieurs critères, au lieu de un seul critère avec somme.si ).
LODraw est à des années lumières de PowerPoint en terme de facilité d'utilisation.
Office n'est pas exempt de bugs ni d'incohérences, mais à part les libristes que se lavent le cerveau eux-même, il est facile de se rendre compte que Office est tout simplement un produit de meilleur qualité.
[^] # Re: Ça fait envie
Posté par Philippe F (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à -1.
Pour le coup, c'est vraiment un problème d'OS: Windows ne permet pas d'écraser un fichier déjà ouvert, alors que Linux si…
[^] # Re: Sérieux ?
Posté par Philippe F (site web personnel) . En réponse au journal La GPL est une licence immonde qui ne devrait pas exister. Évalué à 1.
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.
[^] # Re: gpl ... seulement si tu veux
Posté par Philippe F (site web personnel) . En réponse au journal Licences logicielles : Je t'offre une bière, mais tu dois m'en offrir une après !. Évalué à -4.
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 !
[^] # Re: Mauvaise cible
Posté par Philippe F (site web personnel) . En réponse au journal Licences logicielles : Je t'offre une bière, mais tu dois m'en offrir une après !. Évalué à -2.
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.
# Et ça marche aussi en pratique
Posté par Philippe F (site web personnel) . En réponse au journal Licences logicielles : Je t'offre une bière, mais tu dois m'en offrir une après !. Évalué à -4.
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, …).
[^] # Re: euh?!
Posté par Philippe F (site web personnel) . En réponse au journal Retour d'expérience avec le langage J. Évalué à 1.
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#.
# Excellent !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Git-deliver. Évalué à 4.
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.
[^] # Re: le pasclient, c'est encore mieux!
Posté par Philippe F (site web personnel) . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 3.
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.
[^] # Re: " et je sais pas si ça marche bien sous Linux"
Posté par Philippe F (site web personnel) . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 2.
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.
[^] # Re: Un choix à faire
Posté par Philippe F (site web personnel) . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 2.
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.