Je n'ai pas regardé plus loin, mais juste en vidant mes cookies, je peux voter deux fois :/
Ah. Je n'ai pas testé. On avait vu qu'on ne pouvait pas voter avec un second ordinateur dans le même appart (donc même IP) donc j'ai supposé que ça se base vraiment sur l'IP. Mais si tu dis que juste vider ses cookies suffit, alors c'est vraiment programmé n'importe comment.
Déjà que même de base la logique d'un vote par IP n'est pas très bonne, déjà parce que ça interdit à plusieurs personnes de voter si derrière la même IP (typiquement la famille derrière une même box, ou ses collègues au boulot), mais surtout car — comme tu l'indiques — ça rend le bourrage facile. Beaucoup de fournisseurs d'accès ne garantissent pas d'IP stable, en particulier avec des connexions 3G.
(et vu leur remontée fulgurante depuis hier, je soupçonne assez fortement les deux premiers actuels)
Le second, c'est nous. Et si on est second (et on a même été premier pendant un moment), c'est grâce à linuxfr! Merci Linuxfr. :-)
On était genre 5ème, puis j'ai publié ce journal, et en une demi journée, on a passé tout le monde (c'est simple, j'ai publié en début de soirée, le lendemain au réveil, on était premier). Ça a continué sur la lancée pendant une bonne journée ou plus, et à un moment on a même eu plus de 200 votes d'écart avec le second! Mais là ça s'est calmé; les votes pour GIMP Motion augmentent encore régulièrement, mais plus très vite. :-/
Donc notre remontée fulgurante, c'est pas du bourrage, c'est du linuxfrage (le site avec un lectorat de libriste si grand qu'il est connu pour faire des DDOS involontaires de petits serveurs lorsque certains liens sont si intéressants que tout le monde clique!). ;-)
Le premier, on s'est posé la question, en effet. Surtout que hier soir, quand ils nous ont dépassé, on a lancé des messages sur les réseaux sociaux pour activer nos soutiens; lorsqu'on a difficilement grimpé à leur niveau et dépassé de quelques votes, ils ont soudainement fait un bon de plus de 100 votes en genre 30 minutes. Ça m'a paru suspect.
Ensuite je veux pas médire sans savoir. Ils ont peut-être une communauté très vaste aussi et savent bien faire jouer leur communication. Apparemment ils ont une "app" de téléphone et poussent les utilisateurs à voter en promettant de débloquer des fonctionnalités lorsqu'ils atteignent des paliers de vote.
Au final, même s'ils utilisent vraiment des techniques de changement d'IP (mais j'en sais rien), ce n'est certes pas fair-play, mais peut-être pas contre les règles. Le règlement n'indique pas que les votes doivent être limités à un par personne physique. Il dit juste:
limité à un seul vote par adresse IP
Nous on va continuer à la jouer cool, ne serait-ce que parce que j'ai pas que ça à faire que de piper les dés. On va se contenter de lancer quelques appels comme on l'a fait sur linuxfr et espérer que la communauté du libre saura être plus importante en nombre. Pour moi, LinuxFR a encore fait (il y a 2 jours, avec le nombre de vote impressionnant qu'on a eu) une démonstration épatante du pouvoir de la communauté du logiciel libre… et en plus seulement à l'échelle francophone!
Le premier gagne automatiquement 1500€ ?
Oui. Par contre, le gagnant du prix du public est "disqualifié" automatiquement des prix du jury (ce que je trouvais totalement idiot au début, soit dit en passant car le grand prix est de 5000 €! Mais maintenant que je me rends compte que c'est si simple de "bourrer les urnes", c'est peut-être la raison).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui y a encore plein de trucs avec lesquels je suis pas tout à fait heureux. En plus le fait d'être bloqué sur GTK+2 n'aide pas. J'ai hâte qu'on passe à GIMP 3 pour profiter de certaines nouvelles widgets.
Ceci dit, quand tu parles de "manipulation de fenêtres", j'imagine que tu parles des divisions en panneaux que l'on peut redimensionner en cliquant-déplaçant la bordure. Peut-être que ça se voit pas bien en vidéo, mais c'est en fait assez simple et intuitif car ce type de GUI est très classique. En plus j'ai fait ce screencast juste avant d'uploader, sur mon ordi portable qui a un écran assez restreint. Avec un grand écran, voire plusieurs écrans (configuration classique chez les graphistes et animateurs), ce type de problème se poserait beaucoup moins.
Mais ça n'empêche pas que plein de choses doivent être améliorés quand même. :-)
Pour le moment, j'essaie de me concentrer surtout sur le cœur de certaines fonctionnalités, et accélérer les chargements, etc. (ça se voit pas dans la vidéo, car c'est pas le but; le traitement d'image pour la vidéo, c'est pas facile pour obtenir un bon compromis entre une prévisualisation fluide, ce qui veut en général dire qu'il y a eu du préchargement, et une GUI qui soit réactive malgré le dit-préchargement).
Donc bon, oui y a du boulot! Par conséquent merci pour avoir cliqué! Si on gagne, ça me donnera du temps pour pouvoir travailler dessus. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je ne peux pas te donner de réponse avisée sur ton problème exact. Par contre, dans tous les cas : sauvegarde tes données. Quand tu fais ce genre de manips, il ne faut jamais supposer qu'il n'y aura aucun problème. voilà pour mon conseil du jour. ;)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Très bon (ou mauvais) code qui sera juger… par des développeurs (dont c'est le métier)
Dont c'est le métier? Pas forcément. On ne regarde que la qualité du code, pas le CV. La personne pourrait être éboueur de profession ou pilote de course qu'on ne le saurait même pas. Si le code est bon, on l'intègre, sinon on propose des améliorations possibles pour intégration ultérieure potentielle (on appelle cela de la "revue de code" et on en reçoit tous, même les mainteneurs des plus gros projets demandent aux autres qu'ils revoient leur code).
Ça me va si celui qui me dit ça est à même de l'évaluer
…
(vous par un développeur, nous par un designer)
Donc un projet qui n'a aucun designer ne pourra alors jamais en avoir puisque les designers ne pourront jamais être jugé par un designer déjà présent? Là y a comme un problème de poule et d'œuf, non?
ça peut être des devs s'ils savent
C'est déjà mieux. Pourtant tu continues à faire bien trop de distinction, à classer les gens et les mettre dans une case ('dév', 'designer'…), à confondre qualité et profession/métier (comme je l'ai dit et je le répète ça joue, bien entendu, mais c'est loin d'être du 100%)… Et surtout tu dis ça, mais clairement en vrai tu juges sans savoir si ce sont des gens qui "savent". As-tu fait un background check sur l'ensemble des gens que tu as cité et moqué (pour ne pas dire craché dessus, disons le clairement) dans ton post de blog? J'ai quand même l'impression que tu me classeras direct dans la catégorie "sale développeur qui y comprend rien" si on a affaire sur un projet. Or j'ai fait de l'ergonomie à l'université, avec des projets où j'ai fait des tests utilisateurs, etc. Ensuite je n'ai pas poursuivi du tout dans ce domaine et suis le premier à dire que je suis loin d'un expert design ou ergonome. Mais ça n'en reste pas moins un sujet qui m'intéresse, je lis sur le sujet, je veux en savoir plus, etc. Alors dans quelle catégorie je rentre? Suis-je quand même un "dév qui sait"?
C'est une question bien rhétorique car je ne m'attends pas à ce que tu me répondes direct. Enfin… j'espère que tu n'allais pas le faire. Ce serait bien présomptueux. Et c'est là mon point d'argument: tu ne peux pas avoir d'avis sur chaque contributeur à un projet avec juste quelques messages en arrivant sur un nouveau projet. Et ce que ce soit pour la programmation ou le design.
Je pense que tu accepterais moins ces "refus de patches" et de contributions si elles étaient repoussées par des non devs sur des prétextes fallacieux. "Tenez j'ai codé un système pour améliorer la sécu" "lol non on en veut pas et on aime pas ton indentation".
L'indentation dans le code est importante et on intègre les problèmes d'indentation dans la revue de code. On appelle cela le "style" du code, il doit rester cohérent dans l'ensemble du code pour que celui-ci reste lisible et compréhensible. Ce n'est absolument pas une sorte de réaction de kikoolol comme tu sembles le penser, est même potentiellement insultant (comme beaucoup de choses que tu sembles penser des développeurs) et montre une incompréhension du travail de développeur.
Bien sûr si c'est l'unique problème, on pourrait simplement intégrer le patch et corriger l'indentation ensuite nous-même, ce qu'on fait parfois. Mais c'est important de le dire et de demander au contributeur de corriger lui-même son indentation. Si on veut garder les contributeurs et les pousser à continuer, ils doivent savoir quelles sont nos règles pour améliorer leurs patchs au fur et à mesure. En plus ce genre de choses sont très bien prises par les contributeurs justement. Tout revue de code est en générale bien reçue (en tous cas par les développeurs qui n'ont pas un égo surdimensionné, qui veulent vraiment aider, qui veulent aussi apprendre parfois, etc.) et montre bien qu'on s'intéresse au patch et qu'on veut l'intégrer.
Donc très mauvais exemple. Et ça montre que tu ne comprends pas du tout ce que font les développeurs encore une fois.
Pour te donner un exemple plus artistique (car il se trouve que j'ai un certain bagage dans le milieu artistique, moi-même déjà, mais aussi en collaboration technique avec des artistes). C'est un peu comme si un dessinateur utilisait son propre style dans un film d'animation au lieu d'utiliser le style du film (donc y aurait un perso différent stylistiquement des autres dans la scène). Tu peux transposer ça avec des arts plastiques où plusieurs artistes travaillent sur une même œuvre, sur la musique aussi avec des musiciens qui jouent ensemble, etc. Bien sûr, je parle pas d'œuvres où mélanger des styles très différent est justement le but (type cadavre exquis!), mais de trucs plus classiques. Il y a un moment où l'harmonisation du style des intervenants est tout aussi important que la compétence intrinsèque de chacun si on veut que l'œuvre finale soit belle. [*] On appelle cela du travail d'équipe!
Sur ces belles paroles, je pense que ce sera mon dernier message. J'ai pas l'impression que la discussion va vraiment évoluer et surtout j'ai le sentiment que tu as juste une dent contre les développeurs de logiciel libre, voire contre le logiciel libre dans son ensemble (à la façon dont tu as l'air d'attaquer quasi chaque projet).
C'est vraiment dommage car on a en effet vraiment besoin de designers. Ce pourquoi j'essayais de donner mon avis sur la question pour voir si on pouvait amender les choses. J'ai pas l'impression. :-/
[*] P.S.: après réflexion, mon parallèle n'est pas idéal car l'indentation n'influe pas directement sur le logiciel final (contrairement au style d'un dessin pour une œuvre dessinée). L'indentation en programmation est plus une histoire d'organisation. Un meilleur parallèle serait alors simplement des gens qui travaillent ensemble mais quelqu'un qui refuserait de suivre l'organisation du groupe. Genre il range des dossiers par date alors que tout le monde a décidé de ranger par ordre alphabétique (car c'est son style d'organisation, il veut pas qu'on lui impose un autre, vous comprenez!). Bien sûr, on peut quand même arriver à un travail acceptable, mais cela met clairement des bâtons dans les roues de la dynamique globale.
Je garde quand même l'autre exemple car plus artistique et te parlera peut-être plus, et je pense que c'est pas si différent au final, car la conclusion est la même: il s'agit au final de travail d'équipe et il faut savoir parfois faire des concessions sur son style le temps d'un projet.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Hmm… J'ai répondu sur le blog par correction, mais je me rends compte que la vraie discussion se passe apparemment ici. Même l'auteur d'origine ne semble plus répondre qu'ici. Allez hop! Je recopie ma réponse (rédigée en s'adressant à ce designer).
Bonjour,
Ce billet dit des choses justes, mais aussi d'autres qui me font peur, notamment après avoir vécu une mauvaise expérience avec un designer dans le libre justement.
Globalement je suis totalement d'accord avec le fait que l'on doit laisser le designer bosser et qu'il est le boss dans son domaine. Il est celui qui doit avoir le dernier mot dans ce qu'il fait.
Par contre, il est normal qu'il y ait une étape intermédiaire entre "inconnu au bataillon" et "mainteneur de tout l'aspect design du logiciel". C'est la même chose pour les développeurs. Dans beaucoup de logiciels libres, si un contributeur fait un très bon code dans une zone que personne n'a touché depuis des lustres, non seulement ce code sera accepté et intégré au logiciel, mais en plus si ce contributeur reste dans le coin et continue à contribuer, il sera considéré comme le "mainteneur" de ce bout de code et celui qui décide. Mais la condition, c'est bien: "si un contributeur fait un très bon code".
Parce que du mauvais code, y en a aussi plein (développeur pro ou pas), et si un développeur se ramène dans un projet avec comme intro "J’ai 11 ans d’expérience dans le développement, j’ai réglé des problématiques conceptuelles sur des sites et des projets stratégiques gargantuesques impliquant des dizaines de personnes juste pour la partie logicielle, donc chill, je peux gérer ton projet", ben ça me fera ni chaud ni froid. Et la réponse sera la même que pour un autre: ok on accepte les patchs, on attend le tien.
Note que j'ai croisé des professionnels qui ont des années d'expérience et dont les compétences m'impressionnent absolument pas, tout comme j'ai croisé des étudiants ou très jeunes développeurs qui trouvaient vraiment des solutions extrêmement pertinentes et qualitatives sur des problèmes très complexes. L'expérience, c'est important, mais ce n'est pas tout. Et ceci s'applique quel que soit le métier.
Donc oui, je suis totalement d'accord sur le fait qu'il faut laisser travailler et avoir le dernier mot au designer, mais il faut d'abord que ce dernier passe l'étape où on l'accepte comme un designer du projet. Tu ne peux absolument pas critiquer la décision de l'équipe SPIP comme tu le fais, par exemple. Note que je l'aime bien cette proposition de design, mais bon voilà, je contribue/décide pas chez SPIP. J'ai aussi eu des patchs refusés dans ma vie dans divers projets. Souvent j'y ai passé des heures et des heures. Mais voilà, c'est la vie. Je vais pas en faire une sorte de conclusion générale (et négative) sur le processus de développement dans le logiciel libre, ni me faire une opinion générale (et très négative aussi) sur une équipe de gens que je ne connais simplement pas, encore moins aller la diffuser dans un post.
Il y a aussi cette dualité stricte entre designer et développeur, que je n'aime pas. Comme je disais, je suis tout à fait d'accord que le designer doit décider des choses du design. Mais cela ne doit pas l'empêcher de pouvoir écouter les développeurs. Un développeur, c'est pas non plus un abruti qui a du caca dans les yeux, comme tu le dis si poétiquement. Ce n'est pas parce qu'on est développeur qu'on est forcément un débile du design ou qu'on ne peut pas avoir de bonne idées. De même qu'un designer peut aussi avoir de très bonnes idées pour les développeurs (il n'est pas toujours nécessaire de savoir programmer pour comprendre le boulot du développeur, ce n'est qu'une — parfois minime même — partie du boulot de développeur, ce que certains designers ne semblent pas voir).
Je parlais de mauvaise expérience, c'était justement avec un designer qui marquait une triple et très stricte catégorisation des gens: designer, développeur et utilisateur. Je me rappelle même qu'en réunion, une fois, il commence en notant un triangle sur tableau blanc pour noter les 3 catégories clairement séparées (la base de sa philosophie de contribution quoi). Il nous disait alors très clairement que les développeurs étaient des abrutis qui ne devaient absolument pas toucher ou parler du design. Un peu comme toi. Super expérience [ironique], je le dis tout de suite. Comme quoi, y a pas que les designers qui se font mal traiter par les dévs et peuvent mal vivre la collaboration (franchement j'ai très mal vécu cette collaboration et je suis très heureux qu'il soit parti, ça a débloqué beaucoup de choses car justement on le considérait comme le boss du design et on avait accepté son leadership dans ce domaine! Selon moi une erreur puisque c'était ce genre de personne, mais ça montre bien que c'est tout à fait possible). L'inverse existe donc aussi.
Le fait est que le designer est en effet celui avec l'expérience, la connaissance théorique, etc. sur le design. Il est celui qui aura le dernier mot. Ça ne l'empêche pas de pouvoir parfois avoir tort (voire d'être mauvais, comme un développeur peut être mauvais, etc. Le fait d'être un professionnel n'empêche pas cela) ou de pouvoir revoir ses idées en prenant en compte des contre-propositions. Le dév, c'est un techos; mais ça l'empêche pas d'avoir des idées dans le champs du design, et parfois bonnes, qui sait! Quant à l'utilisateur (non parce que ce designer considérait aussi que les gens ne savaient pas ce qui était bon pour eux et qu'il ne fallait donc pas les écouter, ce avec quoi je ne suis absolument pas d'accord non plus; je ne sais pas quelle est ta position sur le sujet, mais puisque tu considères qu'il ne faut écouter que le designer dont c'est le métier, j'imagine que tu te positionnes donc aussi pareil?)… les designers et développeurs sont pas aussi des utilisateurs potentiels? Pourquoi faire une sorte de limite stricte? Au final, les "utilisateurs", ben c'est des gens. Et ils ont aussi le droit à une opinion (même si — encore une fois — oui ils sont pas des designers pros et le(s) designer(s) du projet sera celui avec le dernier mot).
Ensuite dans ma vie, j'ai aussi eu de très bonnes interactions avec des designers (dans le logiciel propriétaire, c'est triste à dire!). Je me souviens de jobs où je lisais une spéc, puis j'allais m'asseoir à côté du designer et faisais quelques commentaires. Parfois il m'expliquait pourquoi mes idées n'allaient pas, puis après une discussion, je comprenais et remballais l'idée. D'autres fois, il comprenait mes idées, était d'accord, et faisait évoluer sa spéc. Franchement, ça se passait super bien, extrêmement bonne collaboration et très bon souvenir. Et c'était aussi un designer avec des années d'expériences, etc. etc. Mais la question n'est pas là!
Au final, je conclurai généralement: le logiciel libre, c'est comme partout, c'est fait d'humains avant tout. Et comme tout entre humains, la collaboration, ça veut aussi dire discuter et savoir prendre un peu sur soi de temps de temps. Aussi savoir accepter les critiques d'ailleurs (du moment qu'elles sont constructives et pas agressives, bien sûr!).
Je trouve que le libre est un très bon environnement pour se former à la fois une estime de soi, mais aussi une forme d'humilité.
Je travaille sur des logiciels libres, dont un très gros, et je suis constamment à la recherche de designers qui accepteraient de prendre la charge du design (ou d'une partie de celui-ci) parce que c'est un très vieux logiciel qui a vraiment une vieille GUI basée sur des paradigmes d'il y a plus de 20 ans (22 ans cette année). Une fois qu'on se sera mis d'accord, on considérera leurs choix comme des décisions. Mais ça ne doit pas empêcher les discussions et clairement je suis à la recherche de quelqu'un qui ne considérera pas les développeurs comme des sous-hommes. Je ne dis pas que c'est nécessairement ton cas. Je n'ai aucune idée de comment se passerait la collaboration avec toi et ne connais pas ton travail, ni n'ai aucun moyen de juger vraiment juste par cet article de blog. Peut-être que ça se passerait super bien, qui sait! Mais j'avoue que ça fait un peu peur de lire ton avis sur la collaboration avec les développeurs, ou du moins ce que je crois en comprendre. :-/
Ensuite je lis peut-être mal entre les lignes et me plante peut-être sur tes dires et intentions. Donc bah j'espère que tu trouveras ton bonheur dans le design de logiciel libre! Car oui, beaucoup de logiciels en ont vraiment besoin (ceux auxquels je contribue aussi sont clairement du lot!). Je suis d'accord sur ce point.
Donc bonne continuation!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Du coup si on veut installer un logiciel qui utilise une dépendance du runtime GNOME et que l'on a pas ce dernier il faudra tout de même tirer les 250 dépendances (200 de Freedesktop et 50 de GNOME) ?
Non. :-)
Ça se répond en petits morceaux.
1/ Déjà en vrai y a un runtime et un SDK faits en même temps. Le runtime ne contient que ce qui est nécessaire pour exécuter les logiciels (librairies partagées, etc.) alors que le SDK contient aussi les trucs de développement (headers de lib, mais aussi des outil divers comme les autotools, etc.). Les dévs doivent bien sûr installer tout, mais les autres n'installent que le runtime. Ça fait déjà beaucoup moins de dépendances que la liste "naïve" que j'ai faite précédemment avec un grep et un wc pour compter les lignes.
2/ Un runtime comme celui de freedesktop va contenir énormément de libs que beaucoup de logiciels utilisent sans même forcément s'en rendre compte (car pas en dépendance directe). Que ce soit libpng, ou les libs X11 ou Wayland, si votre appli a une GUI, vous en aurez vraisemblablement besoin. Beaucoup de cas d'usage "bureau" feront aussi des appels DBus, même si vous n'en avez aucune connaissance dans votre code. Vous voudrez forcément les libs alsa et pulseaudio pour le son, les diverses libs de Desktop ou d'affichage de texte, etc.
Au final ce sont des libs de base qui sont nécessaires pour quasi toute appli graphique (même si la dépendance n'est pas directe). Il faut bien voir que le "bureau linux" est lui-même vraiment stratifié sur de nombreux niveaux sur lesquels la plupart des logiciels graphiques s'appuient. Dire un chiffre genre "200" bibliothèques peut paraître énorme, mais je vous assure, pour faire tourner votre ordi super-moderne, ça ne l'est pas du tout! Même en espace disque, ce ne sera pas énorme. Beaucoup de libs de base sont très simples et ne tiendront que sur quelques Ko une fois compilés. Le fameux "faire une seule chose et le faire bien".
3/ Si vraiment vous êtes dans un cas exceptionnel où vous pouvez faire tourner l'application sur quasi aucune dépendance, vous êtes libre de faire votre propre runtime super-minimal.
Si vous voulez dépendre du runtime Freedesktop, mais pas de celui de GNOME: supposons qu'il y a une seule lib que vous voulez qui est dans le runtime GNOME, vous pouvez aussi bien l'ajouter dans votre Flatpak et vous baser sur le runtime Freedesktop. Il n'est pas nécessaire de tirer le runtime GNOME.
4/ Aussi il faut bien se rendre compte que si les gens se mettent à installer Flatpak, ils auront probablement déjà les principaux runtimes, dont celui de GNOME (et celui de KDE). Celui-ci est partagé entre les applications et téléchargé une seule fois, donc pas téléchargé pour une application unique. C'est plutôt efficace et permet des Flatpaks de taille réduite.
En outre, côté sécurité, ça signifie que vous bénéficierez de la réactivité de l'équipe de Flatpak (contenu du runtime Freedestop) ainsi que de l'équipe GNOME (runtime GNOME) donc des mises-à-jour de sécurité de ces 2 runtimes. En tant que développeur d'application, c'est autant de dépendances dont on n'aura pas à s'inquiéter.
Au final, je trouve ce système de niveaux de runtime les uns au dessus des autres assez bien et cela permet de bien diluer le travail entre les packageurs de divers projets, de garantir une sécurité plutôt bonne tout en ayant des mises-à-jour fonctionnelles régulières.
Pour le moment, mon expérience est assez positive. Je n'ai que des problèmes d'accès de fonctionnalités du bureau qui ne sont pas encore possible parfois à cause de la problématique "sandbox". Mais ce sont des problèmes connus et sur lesquels l'équipe de Flatpak travaille. Mon interaction avec eux est plutôt constructive jusqu'à présent (GIMP étant un logiciel avec pas mal de dépendances, et qualifiable de relativement complexe, j'ai forcément rencontré plusieurs petits embêtements ici et là).
P.S.: je conclurai avec un truc auquel je viens juste de penser; le fait d'installer des apps KDE est toujours très ennuyeux dans les distribs classiques, car cela va souvent tirer des dizaines d'autres applications graphiques (souvent pas parce que ce sont de vrais dépendances, mais parce que les packageurs de distribs veulent se simplifier la vie et "supposent" que si vous voulez une application KDE, ça veut dire que vous les voulez toutes) qui vont notamment polluer mon overview lors d'une recherche d'application (ou les menus d'application pour ceux qui en ont encore). Cela ne sera — je pense bien — pas possible avec Flatpak et si j'installe une application KDE qui aura été packagé en Flatpak, je pense que je n'aurai que cette app dans mon overview/menu ce qui améliorera le confort d'utilisation. Et au besoin, désinstaller le runtime Flatpak KDE sera 1000 fois plus simple, minimal en taille et propre que me débarrasser des dépendances multiples dans mon système principal. C'est aussi un gros avantage!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
P.S.: en tous cas pour Flatpak. Pour Docker, je sais pas, mais comme c'est orienté plutôt services et système de prob, j'en doute. Et pour d'autres alternatives de bureau, type Snap, aucune idée non plus du modèle adopté.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tu cites déjà la réponse dans ton journal. Je pense que Flatpak, si le projet continue dans la bonne direction (ça a l'air d'être le cas pour l'instant), peut être la solution au problème cité.
Note que je ne considère absolument pas que le système de paquet par distribution est cassé pour autant, ni qu'il disparaîtra. C'est simplement complémentaire. L'écosystème logiciel GNU est simplement devenu trop important pour que tous les logiciels intéressants soient inclus dans les paquets gérés par la distrib (on peut voir cela comme un succès du "bureau Linux" si on veut alimenter le troll! :P). Donc il faut trouver des solutions pour répartir mieux le travail, et ça veut en général dire que les développeurs doivent s'y mettre. Par contre — on le sait bien depuis le temps — faire un paquet par distribution n'est pas gérable, surtout si ce sont des logiciels faits sur le temps libre (cas non rare dans le logiciel libre!). Un format standard comme flatpak, utilisable sur toute distribution GNU/Linux, est donc une très bonne alternative.
Mais là, qui va s'assurer que tout vos containers utilisent bien la dernière version patchée d'une bibliothèque critique ?
Alors je sais pas comment ça marche pour Docker que tu cites aussi, mais j'imagine bien qu'y a pas de mise-à-jour automatique (surtout parce que c'est fait pour les serveurs et on veut pas voir des trucs genre maj auto en prod!). Par contre Flatpak a un système de dépôt. En gros, chaque projet aura désormais un mini-dépôt de paquets pour ses logiciels et mettra à jour ses dépendances (note: il est aussi possible de faire des Flatpak standalone, sans dépôt, mais ce n'est pas la procédure conseillée).
Ainsi quand le projet mettra à jour son paquet, l'ensemble des gens qui auront installé ce paquet recevront des notifications qu'une mise-à-jour est dispo. Personne ne se baladera avec des applis et dépendances trouées (tant que le projet upstream est maintenu). Note que le projet n'a même pas à maintenir l'ensemble des dépendances possibles d'un logiciel puisque Flatpak fonctionne par "niveaux" de runtime. Ainsi le projet Flatpak lui-même maintient un runtime "Freedesktop" qui à lui seul contient déjà environ 200 dépendances de base qui vont suffire pour énormément de projets. Le projet GNOME aussi maintient un runtime, basé sur celui Freedesktop et qui ajoute environ 50 dépendances. Le projet KDE aussi maintient un runtime. Un logiciel doit simplement choisir un runtime sur lequel se baser.
Pour énormément de projet, celui signifie qu'il n'y aura peut-être aucune dépendance supplémentaire à ajouter dans le Flatpak (et donc à maintenir), ou très peu. Cela dilue énormément la tâche tout en permettant de rester sécurisé.
Ainsi pour les distributions, ça ne change pas grand chose: elles peuvent continuer à proposer les logiciels les plus notables notamment, et avoir des mises-à-jour fonctionnelles pas forcément au taquet (mais une fois tous les 6 mois ou 1 an en fonction du cycle de sortie de la distrib). Ça sera suffisant pour la majorité des logiciels.
Les développeurs eux auront moins de travail puisqu'il n'y aura plus qu'un seul paquet à maintenir pour être dispo partout.
Enfin tout le monde aura accès à des mises-à-jour immédiates fonctionnelles ET de sécurité si on choisit d'installer le paquet Flatpak upstream.
En tous cas, le projet GIMP par exemple fournira désormais un paquet Flatpak upstream que je crée et maintiens. Je pense que c'est vraiment une avancée car jusqu'à ce jour, les gens sous Windows ont un installeur, ceux sous OSX un DMG, et sous Linux… on leur disait d'attendre le paquet de leur distrib ou de compiler. Ça fait limite "citoyens de seconde zone" (bon c'est pas vrai, hein. Quasi tous les dévs de GIMP sont sous Linux, et donc ça veut dire notamment que la version nux est bien plus stable que les autres! Mais bon on pourrait croire). Ben plus maintenant. Tant que je serai dév de GIMP, les linuxiens auront leur Flatpak (bon à part si une alternative encore mieux fait son apparition bien sûr, ou si je découvre un truc horrible qui me fait changer d'avis sur l'utilité… espérons que non, mais on sait jamais!) et seront toujours des citoyens de première zone! :-D
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En effet, je pense que leur suite creative cloud a encore une longue vie devant elle. D'ailleurs même le logiciel "Flash" a probablement un avenir sous son nouveau nom Animate. Simplement le "focus" a changé et le but n'est plus d'exporter en format Flash mais en HTML5 ou en d'autres formats vidéos.
Donc oui, Flash, le format, est sur la pente descendante, et Shockwave l'est encore plus (depuis bien plus longtemps puisque cette technologie fut justement totalement éclipsée par Flash quasi dès ses débuts! C'est dire à quel point c'est mort. J'explique cela dans les sections "Premier pas", puis "Age Sombre" de l'article sur Flash) et c'est donc normal que les logiciels dédiés à ces formats disparaissent (ou deviennent génériques comme fut le cas pour "Animate").
Mais effectivement je doute qu'Adobe en tant que société soit mourante. Pas du tout même. Une petite recherche sur le web indique un chiffre d'affaire en croissance. Apparemment ils ont eu une baisse du chiffre en 2013-14 (si je comprends bien comment on lit ces tableaux) mais ils sont repartis en force en 2015.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Microsoft Office est l'un des fleurons commerciaux de Microsoft. Il me semble — si je ne m'abuse — que cela compte pour une grande part dans les revenus de la compagnie (rapide recherche sur le net, si je comprends bien les graphiques, surtout le dernier, leur suite office fait environ 25% de leur revenu, au delà des produits serveur et des OSes).
Le fait est qu'aujourd'hui comme il y a 20 ans, une chose n'a pas changé: les gens ont besoin d'écrire des textes (courriers, contrats, histoires…) et pour cela les traitements de texte de ce type reste l'outil essentiel de la majeure partie des gens. Les tableurs sont aussi une ressource très commune et ne disparaîtront pas de sitôt, les gens en entreprise ont régulièrement besoin de faire des présentations…
Donc quelle est l'intérêt d'investir dans une suite office, vraiment? Quand tout dans l'utilisation informatique quotidienne des gens ainsi que dans les chiffres de l'entreprise informatique qui vend la suite office la plus utilisée au monde montre qu'il y a un potentiel financier énorme, cela me paraît une bien étrange question… :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
On a déjà beaucoup avec strictement des assos de logiciels libres, mais c'est pas exclu. Les contributeurs qui créeront l'album décideront de ce qui rentre dans le cadre du projet ou non.
Par contre, il faudrait que cette association, Kokopelli, nous contacte (un simple email) et nous envoie les autocollants d'abord.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ce sont juste des logos, ou aussi des autocollants? Il faut que les gens puissent pouvoir se les procurer (sans les imprimer eux même, mais plutôt à un stand TuxFamily par exemple…). Et si ce sont bien des autocollants, lesquels et quelles dimensions métriques?
Merci! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
La différence entre et tutu . Sémantiquement, c’est compliqué de savoir lequel est la « forme à utiliser ».
Ben quand tu as un truc unique qui peut être exprimé en valeur simple, tu fais un attribut. Ensuite dès que c'est une donnée compliquée (qui va être composée de plusieurs valeurs), ou que tu peux en avoir plusieurs, c'est forcément un nœud fils. Quand tu crées ton schéma, c'est à toi de connaître tes données.
Un protocole qui impose l’encodage va quelque part à l’encontre de la norme.
Pas du tout. On avait ce type de remarques régulièrement sur XMPP, du type "XMPP, c'est pas du vrai XML car vous n'utilisez qu'une partie des fonctionnalités" (voir les restrictions XML). Mais non, ce n'est pas vrai. Tout flux XMPP est un document XML absolument bien formé qui sera traité sans erreur dans n'importe quel parseur XML générique.
Encore une fois, XML n'a pas pour but d'être un format final en soi. Il n'y a aucune sémantique dans XML. D'ailleurs si tu fais une recherche sur la spec du terme "semantic", ça ne retourne qu'une seule occurrence qui dit exactement cela:
This specification does not constrain the application semantics, use, or (beyond syntax) names of the element types and attributes, except that names beginning with a match to (('X'|'x')('M'|'m')('L'|'l')) are reserved for standardization in this or future versions of this specification.
C'est à chacun de faire un format et d'y ajouter de la sémantique. La création du format final peut ainsi passer par se limiter à un sous-ensemble de XML. C'est comme l'utilisation d'un langage de programmation: cela n'oblige absolument pas les développeurs à utiliser toutes les fonctionnalités du dit-langage, voire même les autorise à en interdire certaines dans leur programme (exemple très courant: le C++ où beaucoup de développeurs vont interdire l'utilisation de certains fonctionnalités dans leur code, comme dans le Google C++ style guide; notamment les exceptions sont une fonctionnalité interdite dans beaucoup de gros projets C++). Est-ce à dire que le code C++ de Google ou d'ID Software (Doom 3) n'est pas du C++ parce qu'ils n'utilisent qu'un sous-ensemble (clairement interdisant pas mal de fonctionnalités)?
Enfin pour revenir plus précisément à cette fonctionnalité (codage de caractères dans XML), la spéc dit clairement:
(processors are, of course, not required to support all IANA-registered encodings)
Puis un peu plus bas:
Unless an encoding is determined by a higher-level protocol, it is also a fatal error if an XML entity contains no encoding declaration and its content is not legal UTF-8 or UTF-16.
Comme tu vois, la spéc XML est clairement préparée à ce que le codage puisse être déterminé non par la déclaration, mais par le protocole de plus haut niveau (par exemple XMPP). XML est vraiment fait dans l'optique qu'il va en général y avoir une spéc de plus haut niveau qui donnera une vraie sémantique aux éléments et attributs. Sans cela, XML n'est qu'une sorte de syntaxe ou grammaire générique.
Si tu veux un exemple simple, une contrainte comme « date < date_du_jour » (contrainte métier tout à fait raisonnable) n’est pas exprimable. Au final, la validation xsd ne te dispense pas de faire ton boulot correctement.
Bien sûr, tu ne peux pas tout valider dans un schéma XML (qui est aussi un format générique et n'a bien entendu aucune logique par rapport à ton besoin particulier, ou "logique métier" comme on dit), mais tu parlais pas de ça. Tu parlais des types de base et comme quoi XML n'en avait pas hormis string, contrairement à json. Je te réponds que si, avec les schémas. Et maintenant tu réponds que ça fait pas le café non plus! Faut pas changer non plus d'argument à chaque phrase! Non parce que json non plus ne fait le café! :P
Le fait est que XML a des types de base, et c'était donc ma réponse à ton assertion comme quoi il n'y en avait pas; et qu'en plus la validation de ces types peut être faite avant le code spécifique (pas en json, où ça doit être fait dans le code, à moins d'ajouter un mécanisme de schéma spécifique au json). Ça n'empêche en effet absolument pas une validation complémentaire dans le code si nécessaire (comme ton exemple de date). Mais au moins, on sait que les données arrivent directement dans le bon type si on valide avec un schéma.
Par curiosité, comment tu fais quand tu as des données arborescentes à représenter dans tes fichiers de conf (ou simplement des listes) à plat ?
Je l'explique plus haut, dans un autre commentaire. En gros, si tu as un besoin super complexe dans un fichier destiné à être édité par un humain de manière régulière, j'aurais tendance à dire qu'y a un problème plus profond de design logiciel. Si tu dois représenter des données très complexes, faut alors avoir une interface graphique adaptée et compréhensible (et en interne, un format adapté, pas du clé=valeur). Parce que je suis désolé, mais que ce soit du json ou du XML, si y a plusieurs niveaux et une arborescence avancée, c'est juste imbitable pour un non-programmeur. Je mets pas ça entre les mains des gens par design comme étant dans le fonctionnement normal de l'application.
Un truc que tu veux éditable par les gens dans le fonctionnement habituel du programme, c'est un fichier très simple. Sinon y a vraiment un problème de design.
Ensuite ces formats clé=valeur ont tout de même des types de base (chaînes de caractère, nombre et booléen), et des listes (ex: le format clé=valeur standardisé par Freedesktop, dont je donne déjà le lien plus haut a des listes avec séparation des éléments par des point-virgules). Et puis il y a des groupes (mais ca s'arrête là au niveau "arborescence", pas de niveau supplémentaire au delà).
Il y a un minimum de fonctionnalité tout de même! :-)
Cela devrait être bien suffisant pour un fichier destiné à édition manuelle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
si c'est pour une édition par des humains, je préfère YAML.
J'ai eu une fois à implémenter un parseur YAML. C'était vraiment l'horreur. Ils ont fait des choix vraiment bizarres et ont défini plein de façons de noter la même donnée. On ne s'en rend pas compte côté utilisateur car on va en général utiliser la même notation partout. Mais quand on fait un parseur, il faut être exhaustif (pour ce 1% de gens qui vont envoyer des fichiers avec cette syntaxe). Très mauvaise expérience.
Si pour une édition par des humains, je préfère quelque chose de bien plus simple encore, type fichiers clé-valeur simple. Il y a des formats de ce type standardisés, typiquement celui de FreeDesktop qui fut défini pour les fichiers .desktop (donc utilisés par la plupart des — sinon tous les — bureaux libres). Ce type de format reste simple à parser (et en général, y a même pas besoin de faire soi-même, si on utilise une bibliothèque de bureau, par exemple glib). Ce format peut contenir des chaînes de caractères, nombres, booleans et des listes, des sections (même la localisation est prise en charge si besoin est, et elle peut être automatisée avec extraction du texte original par gettext puis génération de fichiers qui contiennent toutes les localisations; c'est ce qui est fait en général pour localiser les fichiers desktop!) et il n'emploie pas 10 variantes par type ni de logique super-compliquées.
Sinon y a aussi des formats encore plus simples, plus proches du INI de Microsoft (le format standardisé par Freedesktop est d'ailleurs très proche, bien qu'avec quelques différences) qui est aussi beaucoup utilisé, même sur nos systèmes libres.
Ces formats sont souvent suffisants et je ne vois pas l'utilité d'apporter la complexité du YAML pour un fichier destiné à être édité par des humains. Ensuite je dis pas, YAML a des fonctionnalités plus avancées et peut-être dans des cas d'usage très particuliers, il convient de monter d'un cran et d'utiliser ce format. Mais je n'ai jamais eu le cas. En général, lorsque le besoin devient vraiment complexe, ce n'est plus un format que je destine à l'édition par des humains, mais par un programme (et à ce moment, ce n'est pas non plus le YAML que je vais choisir).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
meilleur rapport signal / bruit (moins d’octets perdus)
Le XML (comme tout format texte avec syntaxe répétitive) est très compressible, rendant l'argument obsolète. Tous les formats ou protocoles qui sont basés sur XML le compressent dans l'usage "normal" (hors débuggage où on désactivera la compression temporairement).
pas de différentiation entre attribut et valeur du nœud
Je ne comprends pas ce que tu veux dire.
encodage fixé par la norme
Si c'est pour de l'échange de fichier, le fichier XML définit simplement son codage dans sa déclaration. Ensuite le décodage est quand même un truc de base sur tous les systèmes. La seule problématique est lorsqu'un format de fichier ne déclare pas le codage donc il faut faire de la détection (ce qui n'est pas du 100% de réussite). Mais comme XML le fait, y a pas de problème ici.
En plus dans les faits, très souvent les sous-formats vont imposer un codage unique (souvent UTF-8). C'est le cas par exemple de XMPP.
types de base existants dans le langage (liste, flottants, chaînes), faisant partie de la norme, là où XML n’a que des chaînes
Si tu fais du XML bête et méchant, sans schéma, oui il n'y a pas vraiment de types. Mais un format XML est fait pour être défini (en fait XML en soi est un format générique pour faire des formats spécifiques!), par exemple dans un schéma XML et là tu as tous les types que tu veux.
En outre, là où XML va avoir une étape de validation générique au niveau de ton parseur (que tu n'as donc en général pas à implémenter dans le code; en utilisant une bibliothèque XML externe, on se contente de fournir le schéma et la validation est faite pour nous), tu dois en général implémenter de la validation spécifique pour un format json.
Sans compter la reprise sur erreur: comme XML a une étape de validation du schéma, il est capable d'ignorer tout erreur de contenu (mauvais type, attributs inconnus, etc.), mais en le prenant en compte, avec par exemple simplement un avertissement dans le programme qu'il y a une corruption possible du fichier. En très peu de ligne (encore une fois, en se reposant sur une bibliothèque générique), on va définir de la gestion d'erreur précise pour divers cas et on ne sortira en erreur complète que sur les problèmes majeurs. C'est même la base de certains sous-formats de XML, par exemple XMPP encore, qui est extensible par nature, a certaines caractéristiques obligatoires mais peut aussi accueillir des extensions (et un client/serveur peut les ignorer s'il ne les prend pas en charge mais sans jamais casser la connexion ou le transfert fiable et complet des données).
Json pourrait faire tout cela bien sûr, mais nécessite beaucoup de code spécifique et sera donc bien plus prompt aux erreurs de programmation. Surtout en gestion d'erreur, on sait tous que c'est exactement le genre de trucs chiants que beaucoup vont laisser "pour plus tard"; et le manque dans le code ne se voit pas pendant longtemps — puisque logiquement en général le contenu utilisé est valide — jusqu'au jour où on tombe sur un bout de données corrompu et là, le programme risque de vraiment mal le prendre!
Ensuite XML est clairement beaucoup plus lourd à mettre en place et ce n'est pas à utiliser selon moi pour des usages simples. Genre effectivement pour une API web, on va peut-être éviter de la compression (quoique ça dépend; même pour du json, si l'API est faite pour transporter pas mal de données, cela peut être rentable de compresser). De même pour plein de petits formats très courts (typiquement dans une API web, on peut considérer que chaque réponse à une fonction a potentiellement un format différent), on veut peut-être pas écrire plein de mini-schémas XML. Ce serait vite ennuyeux.
Dans plein de cas, json est bien plus léger, simple et flexible. Donc c'est plus agréable pour tous ces petits usages simples. Par contre dans le cas de la création d'un format long et complexe, beaucoup utilisé et structuré, je ne choisirai probablement jamais json. C'est juste le moyen idéal pour se retrouver avec des fichiers invalides sans même s'en rendre compte pendant des semaines (jusqu'au jour où notre programme a besoin de parser ce bout du fichier et saute à notre figure).
Quant à des fichiers de conf (si on prévoit édition par un humain), je n'utiliserais ni json ni XML, mais un format simple "attribut: valeur" ou "attribut = valeur", type fichiers INI. Parce que quand on parle d'édition et lisibilité possible par un humain, je suis désolé mais ni json ni XML ne sont de bons choix. Typiquement c'est très facile de casser un fichier de l'un ou l'autre format (classique: oublier le tag fermant en XML ou le crochet fermant en json).
Par contre lisibilité par un développeur (pour débugguer par exemple), je trouve les 2 aussi lisibles du moment qu'ils indentés pour faciliter le débuggage (et les 2 aussi illisibles s'ils sont pas indentés ou sans retour à la ligne).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Pour t'aider efficacement, il serait bon que tu expliques ce que tu reproches à Dash to Dock comme ça on saurait mieux quoi conseiller. :-)
Bon sinon, personnellement je n'ai jamais utilisé Dash to Dock, ni aucun autre dock depuis que je suis passé à GNOME 3 (je n'en vois personnellement plus l'utilité. C'est simplement 1000x plus rapide/pratique de taper la touche Super puis quelques lettres dans l'overview pour chercher n'importe quel programme).
Cependant il fut une époque où j'utilisais Cairo-Dock et j'appréciais cela beaucoup. Ce n'est pas un plugin GNOME 3, mais un dock générique qui marche avec n'importe quel WM ou bureau (j'utilisais cela avec OpenBox à l'époque).
Bon le développement m'a l'air très ralenti, à en juger par une absence de commits depuis plusieurs mois. Est-ce que le projet est tout simplement devenu très stable et a juste peu de nouveautés (note que Dash to Dock n'a pas non plus un développement intensif; ce type de logiciel n'en a pas forcément besoin)? Ou bien y a plus vraiment de maintenance? Je sais pas et ça fait maintenant quelques temps que je n'ai plus utilisé. Mais bon, c'est une piste pour toi. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Star Wars Rebels, qui semble t'avoir marqué (en mal)
Je ne suis pas un hater de Star Wars Rebel. Je l'utilisais juste en exemple car j'ai regardé plusieurs épisodes y a pas si longtemps et donc c'est un exemple frais. C'est tout. :-)
Je ne regarde pas énormément de séries animées 3D, mais ce n'est pas une question de qualité graphique. C'est juste que je trouve peu de séries 3D qui semblent avoir un script ou mise en scène qui me plaise. Souvent les séries 3D semblent faites pour les très jeunes seulement (avec ces grosses ficelles pas subtiles du tout) alors que les séries pour adultes/tout âge semblent plutôt se diriger vers la 2D (je ne prétends pas non plus connaître toutes les séries animées).
très très loin du fond du panier.
Je m'en rends bien compte.
Ensuite je n'ai pas trouvé SW Rebel extraordinaire, mais comme dit plus haut, c'est plutôt au niveau scénaristique/mise en scène. Je m'attache pas à la qualité visuelle seulement et suis tout à fait conscient que les séries ont rarement des moyens conséquents.
D'ailleurs dans les séries animées que j'adore, y a The Simpsons et on peut pas vraiment dire que ce soit du grand art graphique et animé. South Park est d'ailleurs une bonne série également (même si le côté pipi-caca, c'est moins mon kif) et eux vont carrêment à fond dans l'anti-qualité graphique et animée.
Tout ça pour dire que je ne limite pas mes sélections au critère "beau". Simplement, c'était le sujet du fil de discussion (-> qu'est-ce qui prend du temps dans l'animation?). Et je ne déteste pas Star Wars Rebel. C'est juste moyen en tant que série, mais c'est loin d'être le fond du panier, comme tu dis. :-)
D'où le fait que je soit impressionné. ;)
Et ça veut donc dire qu'ils ont réussi leur coup. Comme souvent ce qui importe, c'est de trouver un public à qui ça plaît. Il n'est pas nécessaire d'être un "prodige" technique. Je dirais même plus: ça sert à rien d'être un prodige si ça ne plaît pas. On voit ça des fois, une œuvre inutilement compliquée et extraordinaire techniquement; ou alors super intellectuelle (ou philosophique, ou au contraire totalement abstraite, ou sans aucun sens ou dans le but unique de choquer, etc.). Je ne suis pas fan non plus de cela (mais certains le sont, et donc y a un public, c'est ce qui compte).
Des fois, des trucs plus simples mais qui "marchent", c'est bien aussi. ;-)
En tout cas, merci beaucoup de l'analyse très poussée.
De rien. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ben pas vraiment. J'ai regardé tes exemples, au contraire, ça illustre parfaitement mon propos qu'on va tricher dès qu'on essaie de faire des trucs un peu 3D.
Dans le premier exemple (la danse), bon bah à part les persos, y a rien qui tourne. D'ailleurs comme tu le notes, y a même pas de décor, alors y a rien à faire tourner. Or bien sûr qu'on va faire tourner les persos dans de l'anim 2D! C'est un minimum et tout le monde le fait (à part quand tu veux aller dans les extrêmes, genre South Park). :-)
Quand je parle de rotation, c'est le reste dont je parle, et surtout le décor, qui lui est habituellement très peu (sinon du tout) changé dans un même plan, donc le faire changer d'angle, c'est vraiment se mettre des bâtons dans les roues en se donnant beaucoup de travail compliqué en plus qui n'est normalement pas à faire.
D'ailleurs en 2D vectorielle, c'est même l'inverse, ils vont avoir tendance à encore moins jouer avec les angles, même sur les personnages, et tes 2 exemples en sont le parfait exemple: les persos vont avoir tendance à toujours être dans des positions très figées (de face, de côté, de quart, trois-quart, etc. Très peu de nuance par rapport à la 2D dessinée et à la 3D) pour se donner moins de travail. C'est un peu le propre de ce style d'ailleurs.
Dans le second exemple, parles-tu de cette rotation vue de haut à 13:54-55? Si oui, alors c'est pas du tout ça dont je parle. Dans ce cas, ils ne font pas du tout tourner le décor, mais la caméra! Il n'y a pas de travail sur la perspective dans ce plan. Au contraire, même, c'est une ruse qui permet d'utiliser une seule image statique pendant plusieurs secondes tout en donnant une impression de mouvement! C'est donc une solution de facilité (ce qui ne la rend pas pour autant très bien, hein! Qu'on me fasse pas dire ce que j'ai pas dit: trouver et appliquer les solutions de facilité fait aussi partie du boulot et est aussi un critère de travail de qualité!).
Ou alors, tu parles de cette rotation autour du perso en 13:57 -> 14:01? Ben là aussi, c'est une grosse ruse! Ils sont dans une clairière comme par hasard quasi-parfaitement circulaire et quelque soit l'angle qu'on prenne, on voit à peu près la même chose: des arbres. Il a donc "suffi" de copier-coller ces arbres (peut-être avec de petites retouches, en particulier dans leur taille pour donner une impression de différence en passant vite) et de déplacer la caméra rapidement dans un plan parallèle. Cela combiné avec le plan immédiatement précédent (où on a bien montré au public le caractère très "circulaire" dans la situation des personnages avec cette vue de dessus et l'effet de rotation de caméra dont je parlais) et avec la rotation effective des personnages suffit pour tromper le cerveau.
D'ailleurs tu remarqueras l'énorme flou donné à cet arrière-plan (pour être bien sûr de ne rien remarquer de bizarre) ainsi que le fait que les ennemis — qui sont des dizaines tout autour des 2 héros sur le plan précédent — sont soudainement invisibles pendant cette rotation; à part à la toute fin du plan, t'en as 3 qui rentrent dans le champ caméra au moment où le héros saute dans un portail… tout est fait pour tromper le public tout en se simplifiant la tâche et sans faire le moindre travail sur la perspective.
Il n’empêche qu'à l'époque (il y a 8 ans, déjà), et même aujourd'hui, c'est assez bluffant.
Attention, il n'y a rien à reprocher aux animateurs de Wakfu qui m'ont l'air de faire du bon boulot (en me basant sur ces quelques extraits). Ce n'est pas une critique, juste une analyse de ces extraits. :-)
Mais il faut quand même le dire: ce sont des choses que tout le monde fait en 2D depuis des décennies. Ils bossent bien, pas de problème de ce côté là, mais je vois absolument rien d'extraordinaire (ou de "bluffant") dans ces scènes. Désolé.
Il arrive des fois de voir du travail vraiment bluffant dans du changement de perspective sur certains films en 2D pure (j'arrive plus à me rappeler quel film, mais je me souviens d'un cas y a pas longtemps: on regardait un film et on arrête sur un plan, on revient en arrière plusieurs fois, et on se demande s'ils se sont aidés de 3D justement ou s'ils ont vraiment fait ce plan entièrement à l'ancienne). Mais je suis désolé, ça ne m'a pas l'air d'être le cas du tout dans tes 2 exemples.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tiens, c’est curieux, j’étais persuadé que le passage à la 3D avait notamment été dicté par des contraintes de coût, parce que ça coûtait moins cher (càd, ça va plus vite) de faire de la 3D que de l’animation « traditionnelle ».
Moi aussi les chiffres plus faibles en 3D m'ont étonné. Ensuite le but de mon commentaire n'était pas de comparer 2D et 3D en temps d'animation, et cet article est bien trop imprécis pour être pris en référence ultime. C'est simple: ça dépend bien trop des choix d'animation. Tu vas pas mettre autant de temps pour animer disons une balle qui rebondit (exemple typique en animation) dans un monde Tex Avery et un personnage d'un film Pixar. Donc faut pas non plus trop s'accrocher à ces chiffres. Leur but premier est d'expliquer que l'animation en règle générale prend énormément de temps et plus tu montes en qualité, plus ce temps est important.
Aussi je me suis demandé si l'auteur de cet article ne comptait pas les parties modélisation + rigging dedans. Il est connu qu'en 3D, cela prenne énormément de temps. En gros, en 2D trad, le palier de préparation est relativement court et on peut rapidement commencer à animer. Alors qu'en 3D, y a un gros blocage au début avec la modélisation/rigging, mais une fois que les persos sont faits, il me semblait que tu pouvais animer plus vite; et donc sur de longs projets qui réutilisent les mêmes persos souvent, c'est plus rentable au final (alors que sur un projet très court au contraire, c'est peu rentable… sauf si justement tu fais de la tellement basse qualité que tu utilises des persos tout faits dans des banques de persos 3D par ex, et donc tu fais sauter modélisation et rigging; ou bien que tu fais du copier-coller de persos en changeant juste le visage, etc.). Mais ça, c'est ce que je pensais. Ce type d'article va à l'encontre de cette vision, donc je ne saurais dire. Peut-être que non en fait, peut-être que même l'animation est plus longue en 3D. Ou alors le rapport temps/qualité n'est pas linéaire: peut-être qu'en haute qualité 3D, tu passes plus de temps à animer qu'en haute qualité 2D, mais qu'à l'inverse en basse qualité 3D, tu passes moins de temps à animer qu'en basse qualité 2D (ça serait en fait assez logique, car en 2D, même en basse qualité, tu dois quand même redessiner des choses; c'est déjà plus qu'en basse qualité 3D où tu peux juste te contenter de placer ton perso approximativement).
Il faudrait croiser les infos. Ou mieux, avoir des stats basées sur des milliers d'animateurs et des définitions claires dans le contexte de ces stats. :-)
Mais cela n'a pas beaucoup d'importance. Ce qui est sûr, c'est que même si ça allait en fait plus vite en 3D, ça prend toujours du temps de bien animer. Le choix de la technique n'est jamais fait dans un but de gain temporel quand on veut faire de la qualité (ce qui est notre cas, et bien évidemment le cas de Disney pour ses films cinés), car par défaut on a choisi un chemin difficile et quoiqu'on fasse, ce sera long, coûteux et plein d'obstacles. Y a pas de miracle.
coûtait moins cher (càd, ça va plus vite)
Sur ce point en particulier, le rapport temps/coût n'est pas toujours vrai (bon il l'est souvent, il faut bien le dire, surtout dès que des humains sont en jeu car c'est le temps humain qui coûte le plus). Lors de notre visite de l'atelier Weta (un studio vraiment génial qui font des costumes, objets, maquettes… c'est simple, ils sont au générique de quasi tous les blockbusters Hollywood), on nous expliquait que les films faisaient de moins en moins d'animatronique (ex: si un gars a une main de robot, tu pourrais soit l'éditer ensuite en 3D, soit tu pourrais faire une vraie main robotisée que l'acteur pourrait mettre au dessus de sa vraie main pendant le tournage…) au profit de la 3D. Mais ce n'était pas une histoire de coût car la 3D revient en fait plus cher. Par contre, c'est plus rapide!
Ça se vérifie notamment bien dans les animes, où les décors sont beaucoup réalisés en 3D pour gagner du temps
Alors non, ce n'est pas la raison de l'utilisation de 3D dans un film 2D. Tu vas d'ailleurs prendre bien plus de temps pour modéliser ton décor 3D que le dessiner (je le disais, la partie modélisation prend beaucoup de temps; et pour comparer entièrement avec un dessin 2D final, faut rajouter aussi textures, etc.).
La raison d'utiliser de la 3D en 2D est simplement pour faire des choses quasi-impossible en 2D. Alors c'est pas vrai que ce soit impossible (c'est du dessin, tout est théoriquement possible), mais c'est très très dur. En particulier tout ce qui est mouvement de caméra non planaire. En 2D trad, tous tes mouvements de caméra suivront un plan: tu peux aller à gauche/droit (l'équivalent d'un travelling sur rails dans le cinéma), en haut/bas, tu peux zoomer… mais tu ne vas pas par exemple tourner autour du personnage. Pourquoi? Parce que la perspective est une technique très difficile (demande à n'importe quel peintre s'il a jamais eu de problème avec la perspective, et aussi s'il est aussi fort dans tous les angles; très souvent les peintres ont des préférences de perspective), alors si en plus tu dois faire de la perspective changeante dans un même plan, c'est la mort cérébrale du pauvre artiste!
Et puis en plus, ça veut dire qu'il faut redessiner le même décor à chaque frame, alors que dans les scènes habituelles 2D, tu te contentes de redessiner les personnages et tu gardes le même décor (sur lequel la caméra peut zoomer ou se déplacer parallèlement). Sur ce point, tu pourrais dire: donc finalement, c'est bien une question de temps puisqu'il faut en fait comparer une seule modélisation de décor à X décors dessinés! Et même si tu peux avoir raison sur un plan assez long, une telle demande est surtout un coup à rendre tes dessinateurs fous: "redessine moi ce décor 20 fois en imaginant que la caméra tourne autour de ce point (le perso probablement), avec des angles de 1° entre chaque dessin". Ça s'est fait un peu (ou plus souvent, y a des moyens de tricher un peu, notamment en jouant avec les objets en premier plan, on peut faire illusion), mais y a des limites.
C'est ça la vraie raison de l'utilisation de 3D dans un film 2D.
Du coup, tu sais ce qui a motivé le choix de l’abandon du dessin traditionnel chez Disney ?
Ben je pense que c'est la cool-attitude. La 3D, c'était le truc hype à faire pour être dans le coup. Et de nos jours, c'est l'attente usuelle. Même si la 2D au ciné existe encore et a son petit public, il faut dire ce qui est: ce n'est plus le cinéma à grand succès. Donc de nos jours, ils continuent pour suivre la demande. Y a plus de retours en arrière (du moins pas sans risque financier majeur pour une boîte dont le but est de faire beaucoup d'entrées cinéma).
En tous cas, on peut pas dire que ce soit une question de diminuer les coûts, quand on voit les budgets de production de plus en plus énormes à chaque film.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Comme disait quelqu'un dans un autre journal, va par exemple essayer de te plaindre à la poste que le livreur laisse toujours un papier alors que tu es chez toi.
Mouais… je peux pas dire que je sois très content non plus des services de livraison privées. Je me souviens de pas mal de mauvaises expériences similaires (le gars qui sonne même pas et laisse un papier). Une de mes anecdotes les plus symptomatiques: je travaillais dans des bureaux en région parisienne et comme ces sociétés livrent dans les heures de bureau, ben j'avais donné l'adresse de mon boulot plutôt que chez moi, en notant bien mon numéro de téléphone portable ainsi qu'un commentaire pour dire au livreur de me demander à l'accueil (c'était une PME, l'accueil nous connaissait tous), voire simplement le laisser à l'accueil. Franchement ça pouvait pas être plus simple.
Personne n'est passé de la journée, alors le soir, je regarde le site et le livreur a laissé en commentaire disant qu'il a sonné et qu'il n'y avait personne! C'était des bureaux, il suffisait juste de montrer au premier étage de l'immeuble et la porte était ouverte. Y avait aucune porte fermée (ni en bas, ni à l'étage) ni sonnerie! En gros le livreur ne s'était pas donné la peine de rentrer dans l'immeuble (sinon il aurait su qu'y avait pas de sonnerie comme dans un immeuble d'habitation) et il n'avait pas essayé d'appeler sur mon portable non plus. Je me suis plains. Ils m'ont fait le coup une seconde fois et au final le colis est reparti à l'envoyeur (c'était un support-client qui m'envoyait une pièce; ça m'a fait perdre des semaines)! Et ce n'était pas la poste mais une des grosses boîtes privées de transport de paquet (je ne saurais plus dire laquelle pour sûr pour cette anecdote précise par contre, mais à peu près toutes m'ont fait un coup similaire une fois dans ma vie).
Alors la poste, ils sont loin d'être parfait. Ceci dit, je serais loin d'être aussi catégorique que toi sur la binarisation privé versus public que tu fais sur le sujet.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bourrage d'urne.
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Votez pour « GIMP Motion », extension de GIMP pour l’animation (projet ZeMarmot). Évalué à 2.
Ah. Je n'ai pas testé. On avait vu qu'on ne pouvait pas voter avec un second ordinateur dans le même appart (donc même IP) donc j'ai supposé que ça se base vraiment sur l'IP. Mais si tu dis que juste vider ses cookies suffit, alors c'est vraiment programmé n'importe comment.
Déjà que même de base la logique d'un vote par IP n'est pas très bonne, déjà parce que ça interdit à plusieurs personnes de voter si derrière la même IP (typiquement la famille derrière une même box, ou ses collègues au boulot), mais surtout car — comme tu l'indiques — ça rend le bourrage facile. Beaucoup de fournisseurs d'accès ne garantissent pas d'IP stable, en particulier avec des connexions 3G.
Le second, c'est nous. Et si on est second (et on a même été premier pendant un moment), c'est grâce à linuxfr! Merci Linuxfr. :-)
On était genre 5ème, puis j'ai publié ce journal, et en une demi journée, on a passé tout le monde (c'est simple, j'ai publié en début de soirée, le lendemain au réveil, on était premier). Ça a continué sur la lancée pendant une bonne journée ou plus, et à un moment on a même eu plus de 200 votes d'écart avec le second! Mais là ça s'est calmé; les votes pour GIMP Motion augmentent encore régulièrement, mais plus très vite. :-/
Donc notre remontée fulgurante, c'est pas du bourrage, c'est du linuxfrage (le site avec un lectorat de libriste si grand qu'il est connu pour faire des DDOS involontaires de petits serveurs lorsque certains liens sont si intéressants que tout le monde clique!). ;-)
Le premier, on s'est posé la question, en effet. Surtout que hier soir, quand ils nous ont dépassé, on a lancé des messages sur les réseaux sociaux pour activer nos soutiens; lorsqu'on a difficilement grimpé à leur niveau et dépassé de quelques votes, ils ont soudainement fait un bon de plus de 100 votes en genre 30 minutes. Ça m'a paru suspect.
Ensuite je veux pas médire sans savoir. Ils ont peut-être une communauté très vaste aussi et savent bien faire jouer leur communication. Apparemment ils ont une "app" de téléphone et poussent les utilisateurs à voter en promettant de débloquer des fonctionnalités lorsqu'ils atteignent des paliers de vote.
Au final, même s'ils utilisent vraiment des techniques de changement d'IP (mais j'en sais rien), ce n'est certes pas fair-play, mais peut-être pas contre les règles. Le règlement n'indique pas que les votes doivent être limités à un par personne physique. Il dit juste:
Nous on va continuer à la jouer cool, ne serait-ce que parce que j'ai pas que ça à faire que de piper les dés. On va se contenter de lancer quelques appels comme on l'a fait sur linuxfr et espérer que la communauté du libre saura être plus importante en nombre. Pour moi, LinuxFR a encore fait (il y a 2 jours, avec le nombre de vote impressionnant qu'on a eu) une démonstration épatante du pouvoir de la communauté du logiciel libre… et en plus seulement à l'échelle francophone!
Oui. Par contre, le gagnant du prix du public est "disqualifié" automatiquement des prix du jury (ce que je trouvais totalement idiot au début, soit dit en passant car le grand prix est de 5000 €! Mais maintenant que je me rends compte que c'est si simple de "bourrer les urnes", c'est peut-être la raison).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Il y a beaucoup de "manipulation de fenêtres".
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Votez pour « GIMP Motion », extension de GIMP pour l’animation (projet ZeMarmot). Évalué à 5.
Oui y a encore plein de trucs avec lesquels je suis pas tout à fait heureux. En plus le fait d'être bloqué sur GTK+2 n'aide pas. J'ai hâte qu'on passe à GIMP 3 pour profiter de certaines nouvelles widgets.
Ceci dit, quand tu parles de "manipulation de fenêtres", j'imagine que tu parles des divisions en panneaux que l'on peut redimensionner en cliquant-déplaçant la bordure. Peut-être que ça se voit pas bien en vidéo, mais c'est en fait assez simple et intuitif car ce type de GUI est très classique. En plus j'ai fait ce screencast juste avant d'uploader, sur mon ordi portable qui a un écran assez restreint. Avec un grand écran, voire plusieurs écrans (configuration classique chez les graphistes et animateurs), ce type de problème se poserait beaucoup moins.
Mais ça n'empêche pas que plein de choses doivent être améliorés quand même. :-)
Pour le moment, j'essaie de me concentrer surtout sur le cœur de certaines fonctionnalités, et accélérer les chargements, etc. (ça se voit pas dans la vidéo, car c'est pas le but; le traitement d'image pour la vidéo, c'est pas facile pour obtenir un bon compromis entre une prévisualisation fluide, ce qui veut en général dire qu'il y a eu du préchargement, et une GUI qui soit réactive malgré le dit-préchargement).
Donc bon, oui y a du boulot! Par conséquent merci pour avoir cliqué! Si on gagne, ça me donnera du temps pour pouvoir travailler dessus. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Sauvegarde
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Installer DeepIn en Triple boot avec Windows et ElementaryOS Loki déjà installés. Évalué à 4.
Je ne peux pas te donner de réponse avisée sur ton problème exact. Par contre, dans tous les cas : sauvegarde tes données. Quand tu fais ce genre de manips, il ne faut jamais supposer qu'il n'y aura aucun problème. voilà pour mon conseil du jour. ;)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mon commentaire sur le blog…
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 10.
Dont c'est le métier? Pas forcément. On ne regarde que la qualité du code, pas le CV. La personne pourrait être éboueur de profession ou pilote de course qu'on ne le saurait même pas. Si le code est bon, on l'intègre, sinon on propose des améliorations possibles pour intégration ultérieure potentielle (on appelle cela de la "revue de code" et on en reçoit tous, même les mainteneurs des plus gros projets demandent aux autres qu'ils revoient leur code).
Donc un projet qui n'a aucun designer ne pourra alors jamais en avoir puisque les designers ne pourront jamais être jugé par un designer déjà présent? Là y a comme un problème de poule et d'œuf, non?
C'est déjà mieux. Pourtant tu continues à faire bien trop de distinction, à classer les gens et les mettre dans une case ('dév', 'designer'…), à confondre qualité et profession/métier (comme je l'ai dit et je le répète ça joue, bien entendu, mais c'est loin d'être du 100%)… Et surtout tu dis ça, mais clairement en vrai tu juges sans savoir si ce sont des gens qui "savent". As-tu fait un background check sur l'ensemble des gens que tu as cité et moqué (pour ne pas dire craché dessus, disons le clairement) dans ton post de blog? J'ai quand même l'impression que tu me classeras direct dans la catégorie "sale développeur qui y comprend rien" si on a affaire sur un projet. Or j'ai fait de l'ergonomie à l'université, avec des projets où j'ai fait des tests utilisateurs, etc. Ensuite je n'ai pas poursuivi du tout dans ce domaine et suis le premier à dire que je suis loin d'un expert design ou ergonome. Mais ça n'en reste pas moins un sujet qui m'intéresse, je lis sur le sujet, je veux en savoir plus, etc. Alors dans quelle catégorie je rentre? Suis-je quand même un "dév qui sait"?
C'est une question bien rhétorique car je ne m'attends pas à ce que tu me répondes direct. Enfin… j'espère que tu n'allais pas le faire. Ce serait bien présomptueux. Et c'est là mon point d'argument: tu ne peux pas avoir d'avis sur chaque contributeur à un projet avec juste quelques messages en arrivant sur un nouveau projet. Et ce que ce soit pour la programmation ou le design.
L'indentation dans le code est importante et on intègre les problèmes d'indentation dans la revue de code. On appelle cela le "style" du code, il doit rester cohérent dans l'ensemble du code pour que celui-ci reste lisible et compréhensible. Ce n'est absolument pas une sorte de réaction de kikoolol comme tu sembles le penser, est même potentiellement insultant (comme beaucoup de choses que tu sembles penser des développeurs) et montre une incompréhension du travail de développeur.
Bien sûr si c'est l'unique problème, on pourrait simplement intégrer le patch et corriger l'indentation ensuite nous-même, ce qu'on fait parfois. Mais c'est important de le dire et de demander au contributeur de corriger lui-même son indentation. Si on veut garder les contributeurs et les pousser à continuer, ils doivent savoir quelles sont nos règles pour améliorer leurs patchs au fur et à mesure. En plus ce genre de choses sont très bien prises par les contributeurs justement. Tout revue de code est en générale bien reçue (en tous cas par les développeurs qui n'ont pas un égo surdimensionné, qui veulent vraiment aider, qui veulent aussi apprendre parfois, etc.) et montre bien qu'on s'intéresse au patch et qu'on veut l'intégrer.
Donc très mauvais exemple. Et ça montre que tu ne comprends pas du tout ce que font les développeurs encore une fois.
Pour te donner un exemple plus artistique (car il se trouve que j'ai un certain bagage dans le milieu artistique, moi-même déjà, mais aussi en collaboration technique avec des artistes). C'est un peu comme si un dessinateur utilisait son propre style dans un film d'animation au lieu d'utiliser le style du film (donc y aurait un perso différent stylistiquement des autres dans la scène). Tu peux transposer ça avec des arts plastiques où plusieurs artistes travaillent sur une même œuvre, sur la musique aussi avec des musiciens qui jouent ensemble, etc. Bien sûr, je parle pas d'œuvres où mélanger des styles très différent est justement le but (type cadavre exquis!), mais de trucs plus classiques. Il y a un moment où l'harmonisation du style des intervenants est tout aussi important que la compétence intrinsèque de chacun si on veut que l'œuvre finale soit belle. [*] On appelle cela du travail d'équipe!
Sur ces belles paroles, je pense que ce sera mon dernier message. J'ai pas l'impression que la discussion va vraiment évoluer et surtout j'ai le sentiment que tu as juste une dent contre les développeurs de logiciel libre, voire contre le logiciel libre dans son ensemble (à la façon dont tu as l'air d'attaquer quasi chaque projet).
C'est vraiment dommage car on a en effet vraiment besoin de designers. Ce pourquoi j'essayais de donner mon avis sur la question pour voir si on pouvait amender les choses. J'ai pas l'impression. :-/
[*] P.S.: après réflexion, mon parallèle n'est pas idéal car l'indentation n'influe pas directement sur le logiciel final (contrairement au style d'un dessin pour une œuvre dessinée). L'indentation en programmation est plus une histoire d'organisation. Un meilleur parallèle serait alors simplement des gens qui travaillent ensemble mais quelqu'un qui refuserait de suivre l'organisation du groupe. Genre il range des dossiers par date alors que tout le monde a décidé de ranger par ordre alphabétique (car c'est son style d'organisation, il veut pas qu'on lui impose un autre, vous comprenez!). Bien sûr, on peut quand même arriver à un travail acceptable, mais cela met clairement des bâtons dans les roues de la dynamique globale.
Je garde quand même l'autre exemple car plus artistique et te parlera peut-être plus, et je pense que c'est pas si différent au final, car la conclusion est la même: il s'agit au final de travail d'équipe et il faut savoir parfois faire des concessions sur son style le temps d'un projet.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Mon commentaire sur le blog…
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 10.
Hmm… J'ai répondu sur le blog par correction, mais je me rends compte que la vraie discussion se passe apparemment ici. Même l'auteur d'origine ne semble plus répondre qu'ici. Allez hop! Je recopie ma réponse (rédigée en s'adressant à ce designer).
Bonjour,
Ce billet dit des choses justes, mais aussi d'autres qui me font peur, notamment après avoir vécu une mauvaise expérience avec un designer dans le libre justement.
Globalement je suis totalement d'accord avec le fait que l'on doit laisser le designer bosser et qu'il est le boss dans son domaine. Il est celui qui doit avoir le dernier mot dans ce qu'il fait.
Par contre, il est normal qu'il y ait une étape intermédiaire entre "inconnu au bataillon" et "mainteneur de tout l'aspect design du logiciel". C'est la même chose pour les développeurs. Dans beaucoup de logiciels libres, si un contributeur fait un très bon code dans une zone que personne n'a touché depuis des lustres, non seulement ce code sera accepté et intégré au logiciel, mais en plus si ce contributeur reste dans le coin et continue à contribuer, il sera considéré comme le "mainteneur" de ce bout de code et celui qui décide. Mais la condition, c'est bien: "si un contributeur fait un très bon code".
Parce que du mauvais code, y en a aussi plein (développeur pro ou pas), et si un développeur se ramène dans un projet avec comme intro "J’ai 11 ans d’expérience dans le développement, j’ai réglé des problématiques conceptuelles sur des sites et des projets stratégiques gargantuesques impliquant des dizaines de personnes juste pour la partie logicielle, donc chill, je peux gérer ton projet", ben ça me fera ni chaud ni froid. Et la réponse sera la même que pour un autre: ok on accepte les patchs, on attend le tien.
Note que j'ai croisé des professionnels qui ont des années d'expérience et dont les compétences m'impressionnent absolument pas, tout comme j'ai croisé des étudiants ou très jeunes développeurs qui trouvaient vraiment des solutions extrêmement pertinentes et qualitatives sur des problèmes très complexes. L'expérience, c'est important, mais ce n'est pas tout. Et ceci s'applique quel que soit le métier.
Donc oui, je suis totalement d'accord sur le fait qu'il faut laisser travailler et avoir le dernier mot au designer, mais il faut d'abord que ce dernier passe l'étape où on l'accepte comme un designer du projet. Tu ne peux absolument pas critiquer la décision de l'équipe SPIP comme tu le fais, par exemple. Note que je l'aime bien cette proposition de design, mais bon voilà, je contribue/décide pas chez SPIP. J'ai aussi eu des patchs refusés dans ma vie dans divers projets. Souvent j'y ai passé des heures et des heures. Mais voilà, c'est la vie. Je vais pas en faire une sorte de conclusion générale (et négative) sur le processus de développement dans le logiciel libre, ni me faire une opinion générale (et très négative aussi) sur une équipe de gens que je ne connais simplement pas, encore moins aller la diffuser dans un post.
Il y a aussi cette dualité stricte entre designer et développeur, que je n'aime pas. Comme je disais, je suis tout à fait d'accord que le designer doit décider des choses du design. Mais cela ne doit pas l'empêcher de pouvoir écouter les développeurs. Un développeur, c'est pas non plus un abruti qui a du caca dans les yeux, comme tu le dis si poétiquement. Ce n'est pas parce qu'on est développeur qu'on est forcément un débile du design ou qu'on ne peut pas avoir de bonne idées. De même qu'un designer peut aussi avoir de très bonnes idées pour les développeurs (il n'est pas toujours nécessaire de savoir programmer pour comprendre le boulot du développeur, ce n'est qu'une — parfois minime même — partie du boulot de développeur, ce que certains designers ne semblent pas voir).
Je parlais de mauvaise expérience, c'était justement avec un designer qui marquait une triple et très stricte catégorisation des gens: designer, développeur et utilisateur. Je me rappelle même qu'en réunion, une fois, il commence en notant un triangle sur tableau blanc pour noter les 3 catégories clairement séparées (la base de sa philosophie de contribution quoi). Il nous disait alors très clairement que les développeurs étaient des abrutis qui ne devaient absolument pas toucher ou parler du design. Un peu comme toi. Super expérience [ironique], je le dis tout de suite. Comme quoi, y a pas que les designers qui se font mal traiter par les dévs et peuvent mal vivre la collaboration (franchement j'ai très mal vécu cette collaboration et je suis très heureux qu'il soit parti, ça a débloqué beaucoup de choses car justement on le considérait comme le boss du design et on avait accepté son leadership dans ce domaine! Selon moi une erreur puisque c'était ce genre de personne, mais ça montre bien que c'est tout à fait possible). L'inverse existe donc aussi.
Le fait est que le designer est en effet celui avec l'expérience, la connaissance théorique, etc. sur le design. Il est celui qui aura le dernier mot. Ça ne l'empêche pas de pouvoir parfois avoir tort (voire d'être mauvais, comme un développeur peut être mauvais, etc. Le fait d'être un professionnel n'empêche pas cela) ou de pouvoir revoir ses idées en prenant en compte des contre-propositions. Le dév, c'est un techos; mais ça l'empêche pas d'avoir des idées dans le champs du design, et parfois bonnes, qui sait! Quant à l'utilisateur (non parce que ce designer considérait aussi que les gens ne savaient pas ce qui était bon pour eux et qu'il ne fallait donc pas les écouter, ce avec quoi je ne suis absolument pas d'accord non plus; je ne sais pas quelle est ta position sur le sujet, mais puisque tu considères qu'il ne faut écouter que le designer dont c'est le métier, j'imagine que tu te positionnes donc aussi pareil?)… les designers et développeurs sont pas aussi des utilisateurs potentiels? Pourquoi faire une sorte de limite stricte? Au final, les "utilisateurs", ben c'est des gens. Et ils ont aussi le droit à une opinion (même si — encore une fois — oui ils sont pas des designers pros et le(s) designer(s) du projet sera celui avec le dernier mot).
Ensuite dans ma vie, j'ai aussi eu de très bonnes interactions avec des designers (dans le logiciel propriétaire, c'est triste à dire!). Je me souviens de jobs où je lisais une spéc, puis j'allais m'asseoir à côté du designer et faisais quelques commentaires. Parfois il m'expliquait pourquoi mes idées n'allaient pas, puis après une discussion, je comprenais et remballais l'idée. D'autres fois, il comprenait mes idées, était d'accord, et faisait évoluer sa spéc. Franchement, ça se passait super bien, extrêmement bonne collaboration et très bon souvenir. Et c'était aussi un designer avec des années d'expériences, etc. etc. Mais la question n'est pas là!
Au final, je conclurai généralement: le logiciel libre, c'est comme partout, c'est fait d'humains avant tout. Et comme tout entre humains, la collaboration, ça veut aussi dire discuter et savoir prendre un peu sur soi de temps de temps. Aussi savoir accepter les critiques d'ailleurs (du moment qu'elles sont constructives et pas agressives, bien sûr!).
Je trouve que le libre est un très bon environnement pour se former à la fois une estime de soi, mais aussi une forme d'humilité.
Je travaille sur des logiciels libres, dont un très gros, et je suis constamment à la recherche de designers qui accepteraient de prendre la charge du design (ou d'une partie de celui-ci) parce que c'est un très vieux logiciel qui a vraiment une vieille GUI basée sur des paradigmes d'il y a plus de 20 ans (22 ans cette année). Une fois qu'on se sera mis d'accord, on considérera leurs choix comme des décisions. Mais ça ne doit pas empêcher les discussions et clairement je suis à la recherche de quelqu'un qui ne considérera pas les développeurs comme des sous-hommes. Je ne dis pas que c'est nécessairement ton cas. Je n'ai aucune idée de comment se passerait la collaboration avec toi et ne connais pas ton travail, ni n'ai aucun moyen de juger vraiment juste par cet article de blog. Peut-être que ça se passerait super bien, qui sait! Mais j'avoue que ça fait un peu peur de lire ton avis sur la collaboration avec les développeurs, ou du moins ce que je crois en comprendre. :-/
Ensuite je lis peut-être mal entre les lignes et me plante peut-être sur tes dires et intentions. Donc bah j'espère que tu trouveras ton bonheur dans le design de logiciel libre! Car oui, beaucoup de logiciels en ont vraiment besoin (ceux auxquels je contribue aussi sont clairement du lot!). Je suis d'accord sur ce point.
Donc bonne continuation!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Flatpak pour les paquets de logiciels de bureau
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 10.
Non. :-)
Ça se répond en petits morceaux.
1/ Déjà en vrai y a un runtime et un SDK faits en même temps. Le runtime ne contient que ce qui est nécessaire pour exécuter les logiciels (librairies partagées, etc.) alors que le SDK contient aussi les trucs de développement (headers de lib, mais aussi des outil divers comme les autotools, etc.). Les dévs doivent bien sûr installer tout, mais les autres n'installent que le runtime. Ça fait déjà beaucoup moins de dépendances que la liste "naïve" que j'ai faite précédemment avec un
grepet unwcpour compter les lignes.2/ Un runtime comme celui de freedesktop va contenir énormément de libs que beaucoup de logiciels utilisent sans même forcément s'en rendre compte (car pas en dépendance directe). Que ce soit libpng, ou les libs X11 ou Wayland, si votre appli a une GUI, vous en aurez vraisemblablement besoin. Beaucoup de cas d'usage "bureau" feront aussi des appels DBus, même si vous n'en avez aucune connaissance dans votre code. Vous voudrez forcément les libs alsa et pulseaudio pour le son, les diverses libs de Desktop ou d'affichage de texte, etc.
Au final ce sont des libs de base qui sont nécessaires pour quasi toute appli graphique (même si la dépendance n'est pas directe). Il faut bien voir que le "bureau linux" est lui-même vraiment stratifié sur de nombreux niveaux sur lesquels la plupart des logiciels graphiques s'appuient. Dire un chiffre genre "200" bibliothèques peut paraître énorme, mais je vous assure, pour faire tourner votre ordi super-moderne, ça ne l'est pas du tout! Même en espace disque, ce ne sera pas énorme. Beaucoup de libs de base sont très simples et ne tiendront que sur quelques Ko une fois compilés. Le fameux "faire une seule chose et le faire bien".
3/ Si vraiment vous êtes dans un cas exceptionnel où vous pouvez faire tourner l'application sur quasi aucune dépendance, vous êtes libre de faire votre propre runtime super-minimal.
Si vous voulez dépendre du runtime Freedesktop, mais pas de celui de GNOME: supposons qu'il y a une seule lib que vous voulez qui est dans le runtime GNOME, vous pouvez aussi bien l'ajouter dans votre Flatpak et vous baser sur le runtime Freedesktop. Il n'est pas nécessaire de tirer le runtime GNOME.
4/ Aussi il faut bien se rendre compte que si les gens se mettent à installer Flatpak, ils auront probablement déjà les principaux runtimes, dont celui de GNOME (et celui de KDE). Celui-ci est partagé entre les applications et téléchargé une seule fois, donc pas téléchargé pour une application unique. C'est plutôt efficace et permet des Flatpaks de taille réduite.
En outre, côté sécurité, ça signifie que vous bénéficierez de la réactivité de l'équipe de Flatpak (contenu du runtime Freedestop) ainsi que de l'équipe GNOME (runtime GNOME) donc des mises-à-jour de sécurité de ces 2 runtimes. En tant que développeur d'application, c'est autant de dépendances dont on n'aura pas à s'inquiéter.
Au final, je trouve ce système de niveaux de runtime les uns au dessus des autres assez bien et cela permet de bien diluer le travail entre les packageurs de divers projets, de garantir une sécurité plutôt bonne tout en ayant des mises-à-jour fonctionnelles régulières.
Pour le moment, mon expérience est assez positive. Je n'ai que des problèmes d'accès de fonctionnalités du bureau qui ne sont pas encore possible parfois à cause de la problématique "sandbox". Mais ce sont des problèmes connus et sur lesquels l'équipe de Flatpak travaille. Mon interaction avec eux est plutôt constructive jusqu'à présent (GIMP étant un logiciel avec pas mal de dépendances, et qualifiable de relativement complexe, j'ai forcément rencontré plusieurs petits embêtements ici et là).
P.S.: je conclurai avec un truc auquel je viens juste de penser; le fait d'installer des apps KDE est toujours très ennuyeux dans les distribs classiques, car cela va souvent tirer des dizaines d'autres applications graphiques (souvent pas parce que ce sont de vrais dépendances, mais parce que les packageurs de distribs veulent se simplifier la vie et "supposent" que si vous voulez une application KDE, ça veut dire que vous les voulez toutes) qui vont notamment polluer mon overview lors d'une recherche d'application (ou les menus d'application pour ceux qui en ont encore). Cela ne sera — je pense bien — pas possible avec Flatpak et si j'installe une application KDE qui aura été packagé en Flatpak, je pense que je n'aurai que cette app dans mon overview/menu ce qui améliorera le confort d'utilisation. Et au besoin, désinstaller le runtime Flatpak KDE sera 1000 fois plus simple, minimal en taille et propre que me débarrasser des dépendances multiples dans mon système principal. C'est aussi un gros avantage!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: tendance
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 4. Dernière modification le 31 janvier 2017 à 00:34.
Si ça y répond même plutôt pas mal. :-)
Cf. mon message plus bas.
P.S.: en tous cas pour Flatpak. Pour Docker, je sais pas, mais comme c'est orienté plutôt services et système de prob, j'en doute. Et pour d'autres alternatives de bureau, type Snap, aucune idée non plus du modèle adopté.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Flatpak pour les paquets de logiciels de bureau
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 10.
Tu cites déjà la réponse dans ton journal. Je pense que Flatpak, si le projet continue dans la bonne direction (ça a l'air d'être le cas pour l'instant), peut être la solution au problème cité.
Note que je ne considère absolument pas que le système de paquet par distribution est cassé pour autant, ni qu'il disparaîtra. C'est simplement complémentaire. L'écosystème logiciel GNU est simplement devenu trop important pour que tous les logiciels intéressants soient inclus dans les paquets gérés par la distrib (on peut voir cela comme un succès du "bureau Linux" si on veut alimenter le troll! :P). Donc il faut trouver des solutions pour répartir mieux le travail, et ça veut en général dire que les développeurs doivent s'y mettre. Par contre — on le sait bien depuis le temps — faire un paquet par distribution n'est pas gérable, surtout si ce sont des logiciels faits sur le temps libre (cas non rare dans le logiciel libre!). Un format standard comme flatpak, utilisable sur toute distribution GNU/Linux, est donc une très bonne alternative.
Alors je sais pas comment ça marche pour Docker que tu cites aussi, mais j'imagine bien qu'y a pas de mise-à-jour automatique (surtout parce que c'est fait pour les serveurs et on veut pas voir des trucs genre maj auto en prod!). Par contre Flatpak a un système de dépôt. En gros, chaque projet aura désormais un mini-dépôt de paquets pour ses logiciels et mettra à jour ses dépendances (note: il est aussi possible de faire des Flatpak standalone, sans dépôt, mais ce n'est pas la procédure conseillée).
Ainsi quand le projet mettra à jour son paquet, l'ensemble des gens qui auront installé ce paquet recevront des notifications qu'une mise-à-jour est dispo. Personne ne se baladera avec des applis et dépendances trouées (tant que le projet upstream est maintenu). Note que le projet n'a même pas à maintenir l'ensemble des dépendances possibles d'un logiciel puisque Flatpak fonctionne par "niveaux" de runtime. Ainsi le projet Flatpak lui-même maintient un runtime "Freedesktop" qui à lui seul contient déjà environ 200 dépendances de base qui vont suffire pour énormément de projets. Le projet GNOME aussi maintient un runtime, basé sur celui Freedesktop et qui ajoute environ 50 dépendances. Le projet KDE aussi maintient un runtime. Un logiciel doit simplement choisir un runtime sur lequel se baser.
Pour énormément de projet, celui signifie qu'il n'y aura peut-être aucune dépendance supplémentaire à ajouter dans le Flatpak (et donc à maintenir), ou très peu. Cela dilue énormément la tâche tout en permettant de rester sécurisé.
En tous cas, le projet GIMP par exemple fournira désormais un paquet Flatpak upstream que je crée et maintiens. Je pense que c'est vraiment une avancée car jusqu'à ce jour, les gens sous Windows ont un installeur, ceux sous OSX un DMG, et sous Linux… on leur disait d'attendre le paquet de leur distrib ou de compiler. Ça fait limite "citoyens de seconde zone" (bon c'est pas vrai, hein. Quasi tous les dévs de GIMP sont sous Linux, et donc ça veut dire notamment que la version nux est bien plus stable que les autres! Mais bon on pourrait croire). Ben plus maintenant. Tant que je serai dév de GIMP, les linuxiens auront leur Flatpak (bon à part si une alternative encore mieux fait son apparition bien sûr, ou si je découvre un truc horrible qui me fait changer d'avis sur l'utilité… espérons que non, mais on sait jamais!) et seront toujours des citoyens de première zone! :-D
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: En dehors de Flash
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal adobe c'est bientôt mort ?. Évalué à 10.
En effet, je pense que leur suite creative cloud a encore une longue vie devant elle. D'ailleurs même le logiciel "Flash" a probablement un avenir sous son nouveau nom Animate. Simplement le "focus" a changé et le but n'est plus d'exporter en format Flash mais en HTML5 ou en d'autres formats vidéos.
Donc oui, Flash, le format, est sur la pente descendante, et Shockwave l'est encore plus (depuis bien plus longtemps puisque cette technologie fut justement totalement éclipsée par Flash quasi dès ses débuts! C'est dire à quel point c'est mort. J'explique cela dans les sections "Premier pas", puis "Age Sombre" de l'article sur Flash) et c'est donc normal que les logiciels dédiés à ces formats disparaissent (ou deviennent génériques comme fut le cas pour "Animate").
Mais effectivement je doute qu'Adobe en tant que société soit mourante. Pas du tout même. Une petite recherche sur le web indique un chiffre d'affaire en croissance. Apparemment ils ont eu une baisse du chiffre en 2013-14 (si je comprends bien comment on lit ces tableaux) mais ils sont repartis en force en 2015.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: La FSF et le logiciel libre en phase terminale ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Flash est en phase terminale!. Évalué à 9.
Microsoft Office est l'un des fleurons commerciaux de Microsoft. Il me semble — si je ne m'abuse — que cela compte pour une grande part dans les revenus de la compagnie (rapide recherche sur le net, si je comprends bien les graphiques, surtout le dernier, leur suite office fait environ 25% de leur revenu, au delà des produits serveur et des OSes).
Le fait est qu'aujourd'hui comme il y a 20 ans, une chose n'a pas changé: les gens ont besoin d'écrire des textes (courriers, contrats, histoires…) et pour cela les traitements de texte de ce type reste l'outil essentiel de la majeure partie des gens. Les tableurs sont aussi une ressource très commune et ne disparaîtront pas de sitôt, les gens en entreprise ont régulièrement besoin de faire des présentations…
Donc quelle est l'intérêt d'investir dans une suite office, vraiment? Quand tout dans l'utilisation informatique quotidienne des gens ainsi que dans les chiffres de l'entreprise informatique qui vend la suite office la plus utilisée au monde montre qu'il y a un potentiel financier énorme, cela me paraît une bien étrange question… :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Changement de logo chez Mozilla (donc changement d'autocollants)
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Album Autocollants du Libre : appel aux associations. Évalué à 2.
Wow. Ça change vraiment!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: KOKOPELLI
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Album Autocollants du Libre : appel aux associations. Évalué à 2.
On a déjà beaucoup avec strictement des assos de logiciels libres, mais c'est pas exclu. Les contributeurs qui créeront l'album décideront de ce qui rentre dans le cadre du projet ou non.
Par contre, il faudrait que cette association, Kokopelli, nous contacte (un simple email) et nous envoie les autocollants d'abord.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mageia.org
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Album Autocollants du Libre : appel aux associations. Évalué à 2.
Même questions que pour TuxFamily, plus haut! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: TuxFamily.org
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Album Autocollants du Libre : appel aux associations. Évalué à 2.
Salut,
Ce sont juste des logos, ou aussi des autocollants? Il faut que les gens puissent pouvoir se les procurer (sans les imprimer eux même, mais plutôt à un stand TuxFamily par exemple…). Et si ce sont bien des autocollants, lesquels et quelles dimensions métriques?
Merci! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Incoming PauLLA Stickers ! :D
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Album Autocollants du Libre : appel aux associations. Évalué à 2.
Super! Merci. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: XML sapu et autres billevesées
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 4. Dernière modification le 13 janvier 2017 à 17:42.
Ben quand tu as un truc unique qui peut être exprimé en valeur simple, tu fais un attribut. Ensuite dès que c'est une donnée compliquée (qui va être composée de plusieurs valeurs), ou que tu peux en avoir plusieurs, c'est forcément un nœud fils. Quand tu crées ton schéma, c'est à toi de connaître tes données.
Pas du tout. On avait ce type de remarques régulièrement sur XMPP, du type "XMPP, c'est pas du vrai XML car vous n'utilisez qu'une partie des fonctionnalités" (voir les restrictions XML). Mais non, ce n'est pas vrai. Tout flux XMPP est un document XML absolument bien formé qui sera traité sans erreur dans n'importe quel parseur XML générique.
Encore une fois, XML n'a pas pour but d'être un format final en soi. Il n'y a aucune sémantique dans XML. D'ailleurs si tu fais une recherche sur la spec du terme "semantic", ça ne retourne qu'une seule occurrence qui dit exactement cela:
C'est à chacun de faire un format et d'y ajouter de la sémantique. La création du format final peut ainsi passer par se limiter à un sous-ensemble de XML. C'est comme l'utilisation d'un langage de programmation: cela n'oblige absolument pas les développeurs à utiliser toutes les fonctionnalités du dit-langage, voire même les autorise à en interdire certaines dans leur programme (exemple très courant: le C++ où beaucoup de développeurs vont interdire l'utilisation de certains fonctionnalités dans leur code, comme dans le Google C++ style guide; notamment les exceptions sont une fonctionnalité interdite dans beaucoup de gros projets C++). Est-ce à dire que le code C++ de Google ou d'ID Software (Doom 3) n'est pas du C++ parce qu'ils n'utilisent qu'un sous-ensemble (clairement interdisant pas mal de fonctionnalités)?
Enfin pour revenir plus précisément à cette fonctionnalité (codage de caractères dans XML), la spéc dit clairement:
Puis un peu plus bas:
Comme tu vois, la spéc XML est clairement préparée à ce que le codage puisse être déterminé non par la déclaration, mais par le protocole de plus haut niveau (par exemple XMPP). XML est vraiment fait dans l'optique qu'il va en général y avoir une spéc de plus haut niveau qui donnera une vraie sémantique aux éléments et attributs. Sans cela, XML n'est qu'une sorte de syntaxe ou grammaire générique.
Bien sûr, tu ne peux pas tout valider dans un schéma XML (qui est aussi un format générique et n'a bien entendu aucune logique par rapport à ton besoin particulier, ou "logique métier" comme on dit), mais tu parlais pas de ça. Tu parlais des types de base et comme quoi XML n'en avait pas hormis string, contrairement à json. Je te réponds que si, avec les schémas. Et maintenant tu réponds que ça fait pas le café non plus! Faut pas changer non plus d'argument à chaque phrase! Non parce que json non plus ne fait le café! :P
Le fait est que XML a des types de base, et c'était donc ma réponse à ton assertion comme quoi il n'y en avait pas; et qu'en plus la validation de ces types peut être faite avant le code spécifique (pas en json, où ça doit être fait dans le code, à moins d'ajouter un mécanisme de schéma spécifique au json). Ça n'empêche en effet absolument pas une validation complémentaire dans le code si nécessaire (comme ton exemple de date). Mais au moins, on sait que les données arrivent directement dans le bon type si on valide avec un schéma.
Je l'explique plus haut, dans un autre commentaire. En gros, si tu as un besoin super complexe dans un fichier destiné à être édité par un humain de manière régulière, j'aurais tendance à dire qu'y a un problème plus profond de design logiciel. Si tu dois représenter des données très complexes, faut alors avoir une interface graphique adaptée et compréhensible (et en interne, un format adapté, pas du clé=valeur). Parce que je suis désolé, mais que ce soit du json ou du XML, si y a plusieurs niveaux et une arborescence avancée, c'est juste imbitable pour un non-programmeur. Je mets pas ça entre les mains des gens par design comme étant dans le fonctionnement normal de l'application.
Un truc que tu veux éditable par les gens dans le fonctionnement habituel du programme, c'est un fichier très simple. Sinon y a vraiment un problème de design.
Ensuite ces formats clé=valeur ont tout de même des types de base (chaînes de caractère, nombre et booléen), et des listes (ex: le format clé=valeur standardisé par Freedesktop, dont je donne déjà le lien plus haut a des listes avec séparation des éléments par des point-virgules). Et puis il y a des groupes (mais ca s'arrête là au niveau "arborescence", pas de niveau supplémentaire au delà).
Il y a un minimum de fonctionnalité tout de même! :-)
Cela devrait être bien suffisant pour un fichier destiné à édition manuelle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci LinuxFR!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Meilleures contributions LinuxFr.org : les primés de novembre 2016. Évalué à 5. Dernière modification le 13 janvier 2017 à 16:25.
Aujourd'hui je reçois un paquet énorme, je me dis "mais qu'est-ce que c'est? J'ai rien commandé!".
J'ouvre et c'est en fait le livre qui a été mis dans un paquet qui fait peut-être 15 fois sa taille!
Enfin voilà, ça m'a fait marrer alors je voulais partager car envoyer un livre dans un si énorme paquet, c'est pas commun quand même. :P
Merci encore!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: XML sapu et autres billevesées
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 2.
J'ai eu une fois à implémenter un parseur YAML. C'était vraiment l'horreur. Ils ont fait des choix vraiment bizarres et ont défini plein de façons de noter la même donnée. On ne s'en rend pas compte côté utilisateur car on va en général utiliser la même notation partout. Mais quand on fait un parseur, il faut être exhaustif (pour ce 1% de gens qui vont envoyer des fichiers avec cette syntaxe). Très mauvaise expérience.
Si pour une édition par des humains, je préfère quelque chose de bien plus simple encore, type fichiers clé-valeur simple. Il y a des formats de ce type standardisés, typiquement celui de FreeDesktop qui fut défini pour les fichiers
.desktop(donc utilisés par la plupart des — sinon tous les — bureaux libres). Ce type de format reste simple à parser (et en général, y a même pas besoin de faire soi-même, si on utilise une bibliothèque de bureau, par exemple glib). Ce format peut contenir des chaînes de caractères, nombres, booleans et des listes, des sections (même la localisation est prise en charge si besoin est, et elle peut être automatisée avec extraction du texte original par gettext puis génération de fichiers qui contiennent toutes les localisations; c'est ce qui est fait en général pour localiser les fichiers desktop!) et il n'emploie pas 10 variantes par type ni de logique super-compliquées.Sinon y a aussi des formats encore plus simples, plus proches du INI de Microsoft (le format standardisé par Freedesktop est d'ailleurs très proche, bien qu'avec quelques différences) qui est aussi beaucoup utilisé, même sur nos systèmes libres.
Ces formats sont souvent suffisants et je ne vois pas l'utilité d'apporter la complexité du YAML pour un fichier destiné à être édité par des humains. Ensuite je dis pas, YAML a des fonctionnalités plus avancées et peut-être dans des cas d'usage très particuliers, il convient de monter d'un cran et d'utiliser ce format. Mais je n'ai jamais eu le cas. En général, lorsque le besoin devient vraiment complexe, ce n'est plus un format que je destine à l'édition par des humains, mais par un programme (et à ce moment, ce n'est pas non plus le YAML que je vais choisir).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: XML sapu et autres billevesées
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 2.
Le XML (comme tout format texte avec syntaxe répétitive) est très compressible, rendant l'argument obsolète. Tous les formats ou protocoles qui sont basés sur XML le compressent dans l'usage "normal" (hors débuggage où on désactivera la compression temporairement).
Je ne comprends pas ce que tu veux dire.
Si c'est pour de l'échange de fichier, le fichier XML définit simplement son codage dans sa déclaration. Ensuite le décodage est quand même un truc de base sur tous les systèmes. La seule problématique est lorsqu'un format de fichier ne déclare pas le codage donc il faut faire de la détection (ce qui n'est pas du 100% de réussite). Mais comme XML le fait, y a pas de problème ici.
En plus dans les faits, très souvent les sous-formats vont imposer un codage unique (souvent UTF-8). C'est le cas par exemple de XMPP.
Si tu fais du XML bête et méchant, sans schéma, oui il n'y a pas vraiment de types. Mais un format XML est fait pour être défini (en fait XML en soi est un format générique pour faire des formats spécifiques!), par exemple dans un schéma XML et là tu as tous les types que tu veux.
En outre, là où XML va avoir une étape de validation générique au niveau de ton parseur (que tu n'as donc en général pas à implémenter dans le code; en utilisant une bibliothèque XML externe, on se contente de fournir le schéma et la validation est faite pour nous), tu dois en général implémenter de la validation spécifique pour un format json.
Sans compter la reprise sur erreur: comme XML a une étape de validation du schéma, il est capable d'ignorer tout erreur de contenu (mauvais type, attributs inconnus, etc.), mais en le prenant en compte, avec par exemple simplement un avertissement dans le programme qu'il y a une corruption possible du fichier. En très peu de ligne (encore une fois, en se reposant sur une bibliothèque générique), on va définir de la gestion d'erreur précise pour divers cas et on ne sortira en erreur complète que sur les problèmes majeurs. C'est même la base de certains sous-formats de XML, par exemple XMPP encore, qui est extensible par nature, a certaines caractéristiques obligatoires mais peut aussi accueillir des extensions (et un client/serveur peut les ignorer s'il ne les prend pas en charge mais sans jamais casser la connexion ou le transfert fiable et complet des données).
Json pourrait faire tout cela bien sûr, mais nécessite beaucoup de code spécifique et sera donc bien plus prompt aux erreurs de programmation. Surtout en gestion d'erreur, on sait tous que c'est exactement le genre de trucs chiants que beaucoup vont laisser "pour plus tard"; et le manque dans le code ne se voit pas pendant longtemps — puisque logiquement en général le contenu utilisé est valide — jusqu'au jour où on tombe sur un bout de données corrompu et là, le programme risque de vraiment mal le prendre!
Ensuite XML est clairement beaucoup plus lourd à mettre en place et ce n'est pas à utiliser selon moi pour des usages simples. Genre effectivement pour une API web, on va peut-être éviter de la compression (quoique ça dépend; même pour du json, si l'API est faite pour transporter pas mal de données, cela peut être rentable de compresser). De même pour plein de petits formats très courts (typiquement dans une API web, on peut considérer que chaque réponse à une fonction a potentiellement un format différent), on veut peut-être pas écrire plein de mini-schémas XML. Ce serait vite ennuyeux.
Dans plein de cas, json est bien plus léger, simple et flexible. Donc c'est plus agréable pour tous ces petits usages simples. Par contre dans le cas de la création d'un format long et complexe, beaucoup utilisé et structuré, je ne choisirai probablement jamais json. C'est juste le moyen idéal pour se retrouver avec des fichiers invalides sans même s'en rendre compte pendant des semaines (jusqu'au jour où notre programme a besoin de parser ce bout du fichier et saute à notre figure).
Quant à des fichiers de conf (si on prévoit édition par un humain), je n'utiliserais ni json ni XML, mais un format simple "attribut: valeur" ou "attribut = valeur", type fichiers INI. Parce que quand on parle d'édition et lisibilité possible par un humain, je suis désolé mais ni json ni XML ne sont de bons choix. Typiquement c'est très facile de casser un fichier de l'un ou l'autre format (classique: oublier le tag fermant en XML ou le crochet fermant en json).
Par contre lisibilité par un développeur (pour débugguer par exemple), je trouve les 2 aussi lisibles du moment qu'ils indentés pour faciliter le débuggage (et les 2 aussi illisibles s'ils sont pas indentés ou sans retour à la ligne).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Que cherches-tu exactement?
Posté par Jehan (site web personnel, Mastodon) . En réponse au message [GNOME 3] Extension : Ajouter une barre de lancement rapide. Évalué à 3.
Salut!
Pour t'aider efficacement, il serait bon que tu expliques ce que tu reproches à Dash to Dock comme ça on saurait mieux quoi conseiller. :-)
Bon sinon, personnellement je n'ai jamais utilisé Dash to Dock, ni aucun autre dock depuis que je suis passé à GNOME 3 (je n'en vois personnellement plus l'utilité. C'est simplement 1000x plus rapide/pratique de taper la touche Super puis quelques lettres dans l'overview pour chercher n'importe quel programme).
Cependant il fut une époque où j'utilisais Cairo-Dock et j'appréciais cela beaucoup. Ce n'est pas un plugin GNOME 3, mais un dock générique qui marche avec n'importe quel WM ou bureau (j'utilisais cela avec OpenBox à l'époque).
Bon le développement m'a l'air très ralenti, à en juger par une absence de commits depuis plusieurs mois. Est-ce que le projet est tout simplement devenu très stable et a juste peu de nouveautés (note que Dash to Dock n'a pas non plus un développement intensif; ce type de logiciel n'en a pas forcément besoin)? Ou bien y a plus vraiment de maintenance? Je sais pas et ça fait maintenant quelques temps que je n'ai plus utilisé. Mais bon, c'est une piste pour toi. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Avancement ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche ZeMarmot : compte‐rendu de fin 2016 et appels aux dons. Évalué à 4. Dernière modification le 09 janvier 2017 à 00:34.
Je ne suis pas un hater de Star Wars Rebel. Je l'utilisais juste en exemple car j'ai regardé plusieurs épisodes y a pas si longtemps et donc c'est un exemple frais. C'est tout. :-)
Je ne regarde pas énormément de séries animées 3D, mais ce n'est pas une question de qualité graphique. C'est juste que je trouve peu de séries 3D qui semblent avoir un script ou mise en scène qui me plaise. Souvent les séries 3D semblent faites pour les très jeunes seulement (avec ces grosses ficelles pas subtiles du tout) alors que les séries pour adultes/tout âge semblent plutôt se diriger vers la 2D (je ne prétends pas non plus connaître toutes les séries animées).
Je m'en rends bien compte.
Ensuite je n'ai pas trouvé SW Rebel extraordinaire, mais comme dit plus haut, c'est plutôt au niveau scénaristique/mise en scène. Je m'attache pas à la qualité visuelle seulement et suis tout à fait conscient que les séries ont rarement des moyens conséquents.
D'ailleurs dans les séries animées que j'adore, y a The Simpsons et on peut pas vraiment dire que ce soit du grand art graphique et animé. South Park est d'ailleurs une bonne série également (même si le côté pipi-caca, c'est moins mon kif) et eux vont carrêment à fond dans l'anti-qualité graphique et animée.
Tout ça pour dire que je ne limite pas mes sélections au critère "beau". Simplement, c'était le sujet du fil de discussion (-> qu'est-ce qui prend du temps dans l'animation?). Et je ne déteste pas Star Wars Rebel. C'est juste moyen en tant que série, mais c'est loin d'être le fond du panier, comme tu dis. :-)
Et ça veut donc dire qu'ils ont réussi leur coup. Comme souvent ce qui importe, c'est de trouver un public à qui ça plaît. Il n'est pas nécessaire d'être un "prodige" technique. Je dirais même plus: ça sert à rien d'être un prodige si ça ne plaît pas. On voit ça des fois, une œuvre inutilement compliquée et extraordinaire techniquement; ou alors super intellectuelle (ou philosophique, ou au contraire totalement abstraite, ou sans aucun sens ou dans le but unique de choquer, etc.). Je ne suis pas fan non plus de cela (mais certains le sont, et donc y a un public, c'est ce qui compte).
Des fois, des trucs plus simples mais qui "marchent", c'est bien aussi. ;-)
De rien. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Avancement ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche ZeMarmot : compte‐rendu de fin 2016 et appels aux dons. Évalué à 2. Dernière modification le 08 janvier 2017 à 19:09.
Ben pas vraiment. J'ai regardé tes exemples, au contraire, ça illustre parfaitement mon propos qu'on va tricher dès qu'on essaie de faire des trucs un peu 3D.
Dans le premier exemple (la danse), bon bah à part les persos, y a rien qui tourne. D'ailleurs comme tu le notes, y a même pas de décor, alors y a rien à faire tourner. Or bien sûr qu'on va faire tourner les persos dans de l'anim 2D! C'est un minimum et tout le monde le fait (à part quand tu veux aller dans les extrêmes, genre South Park). :-)
Quand je parle de rotation, c'est le reste dont je parle, et surtout le décor, qui lui est habituellement très peu (sinon du tout) changé dans un même plan, donc le faire changer d'angle, c'est vraiment se mettre des bâtons dans les roues en se donnant beaucoup de travail compliqué en plus qui n'est normalement pas à faire.
D'ailleurs en 2D vectorielle, c'est même l'inverse, ils vont avoir tendance à encore moins jouer avec les angles, même sur les personnages, et tes 2 exemples en sont le parfait exemple: les persos vont avoir tendance à toujours être dans des positions très figées (de face, de côté, de quart, trois-quart, etc. Très peu de nuance par rapport à la 2D dessinée et à la 3D) pour se donner moins de travail. C'est un peu le propre de ce style d'ailleurs.
Dans le second exemple, parles-tu de cette rotation vue de haut à 13:54-55? Si oui, alors c'est pas du tout ça dont je parle. Dans ce cas, ils ne font pas du tout tourner le décor, mais la caméra! Il n'y a pas de travail sur la perspective dans ce plan. Au contraire, même, c'est une ruse qui permet d'utiliser une seule image statique pendant plusieurs secondes tout en donnant une impression de mouvement! C'est donc une solution de facilité (ce qui ne la rend pas pour autant très bien, hein! Qu'on me fasse pas dire ce que j'ai pas dit: trouver et appliquer les solutions de facilité fait aussi partie du boulot et est aussi un critère de travail de qualité!).
Ou alors, tu parles de cette rotation autour du perso en 13:57 -> 14:01? Ben là aussi, c'est une grosse ruse! Ils sont dans une clairière comme par hasard quasi-parfaitement circulaire et quelque soit l'angle qu'on prenne, on voit à peu près la même chose: des arbres. Il a donc "suffi" de copier-coller ces arbres (peut-être avec de petites retouches, en particulier dans leur taille pour donner une impression de différence en passant vite) et de déplacer la caméra rapidement dans un plan parallèle. Cela combiné avec le plan immédiatement précédent (où on a bien montré au public le caractère très "circulaire" dans la situation des personnages avec cette vue de dessus et l'effet de rotation de caméra dont je parlais) et avec la rotation effective des personnages suffit pour tromper le cerveau.
D'ailleurs tu remarqueras l'énorme flou donné à cet arrière-plan (pour être bien sûr de ne rien remarquer de bizarre) ainsi que le fait que les ennemis — qui sont des dizaines tout autour des 2 héros sur le plan précédent — sont soudainement invisibles pendant cette rotation; à part à la toute fin du plan, t'en as 3 qui rentrent dans le champ caméra au moment où le héros saute dans un portail… tout est fait pour tromper le public tout en se simplifiant la tâche et sans faire le moindre travail sur la perspective.
Attention, il n'y a rien à reprocher aux animateurs de Wakfu qui m'ont l'air de faire du bon boulot (en me basant sur ces quelques extraits). Ce n'est pas une critique, juste une analyse de ces extraits. :-)
Mais il faut quand même le dire: ce sont des choses que tout le monde fait en 2D depuis des décennies. Ils bossent bien, pas de problème de ce côté là, mais je vois absolument rien d'extraordinaire (ou de "bluffant") dans ces scènes. Désolé.
Il arrive des fois de voir du travail vraiment bluffant dans du changement de perspective sur certains films en 2D pure (j'arrive plus à me rappeler quel film, mais je me souviens d'un cas y a pas longtemps: on regardait un film et on arrête sur un plan, on revient en arrière plusieurs fois, et on se demande s'ils se sont aidés de 3D justement ou s'ils ont vraiment fait ce plan entièrement à l'ancienne). Mais je suis désolé, ça ne m'a pas l'air d'être le cas du tout dans tes 2 exemples.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Avancement ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche ZeMarmot : compte‐rendu de fin 2016 et appels aux dons. Évalué à 2. Dernière modification le 08 janvier 2017 à 15:49.
Moi aussi les chiffres plus faibles en 3D m'ont étonné. Ensuite le but de mon commentaire n'était pas de comparer 2D et 3D en temps d'animation, et cet article est bien trop imprécis pour être pris en référence ultime. C'est simple: ça dépend bien trop des choix d'animation. Tu vas pas mettre autant de temps pour animer disons une balle qui rebondit (exemple typique en animation) dans un monde Tex Avery et un personnage d'un film Pixar. Donc faut pas non plus trop s'accrocher à ces chiffres. Leur but premier est d'expliquer que l'animation en règle générale prend énormément de temps et plus tu montes en qualité, plus ce temps est important.
Aussi je me suis demandé si l'auteur de cet article ne comptait pas les parties modélisation + rigging dedans. Il est connu qu'en 3D, cela prenne énormément de temps. En gros, en 2D trad, le palier de préparation est relativement court et on peut rapidement commencer à animer. Alors qu'en 3D, y a un gros blocage au début avec la modélisation/rigging, mais une fois que les persos sont faits, il me semblait que tu pouvais animer plus vite; et donc sur de longs projets qui réutilisent les mêmes persos souvent, c'est plus rentable au final (alors que sur un projet très court au contraire, c'est peu rentable… sauf si justement tu fais de la tellement basse qualité que tu utilises des persos tout faits dans des banques de persos 3D par ex, et donc tu fais sauter modélisation et rigging; ou bien que tu fais du copier-coller de persos en changeant juste le visage, etc.). Mais ça, c'est ce que je pensais. Ce type d'article va à l'encontre de cette vision, donc je ne saurais dire. Peut-être que non en fait, peut-être que même l'animation est plus longue en 3D. Ou alors le rapport temps/qualité n'est pas linéaire: peut-être qu'en haute qualité 3D, tu passes plus de temps à animer qu'en haute qualité 2D, mais qu'à l'inverse en basse qualité 3D, tu passes moins de temps à animer qu'en basse qualité 2D (ça serait en fait assez logique, car en 2D, même en basse qualité, tu dois quand même redessiner des choses; c'est déjà plus qu'en basse qualité 3D où tu peux juste te contenter de placer ton perso approximativement).
Il faudrait croiser les infos. Ou mieux, avoir des stats basées sur des milliers d'animateurs et des définitions claires dans le contexte de ces stats. :-)
Mais cela n'a pas beaucoup d'importance. Ce qui est sûr, c'est que même si ça allait en fait plus vite en 3D, ça prend toujours du temps de bien animer. Le choix de la technique n'est jamais fait dans un but de gain temporel quand on veut faire de la qualité (ce qui est notre cas, et bien évidemment le cas de Disney pour ses films cinés), car par défaut on a choisi un chemin difficile et quoiqu'on fasse, ce sera long, coûteux et plein d'obstacles. Y a pas de miracle.
Sur ce point en particulier, le rapport temps/coût n'est pas toujours vrai (bon il l'est souvent, il faut bien le dire, surtout dès que des humains sont en jeu car c'est le temps humain qui coûte le plus). Lors de notre visite de l'atelier Weta (un studio vraiment génial qui font des costumes, objets, maquettes… c'est simple, ils sont au générique de quasi tous les blockbusters Hollywood), on nous expliquait que les films faisaient de moins en moins d'animatronique (ex: si un gars a une main de robot, tu pourrais soit l'éditer ensuite en 3D, soit tu pourrais faire une vraie main robotisée que l'acteur pourrait mettre au dessus de sa vraie main pendant le tournage…) au profit de la 3D. Mais ce n'était pas une histoire de coût car la 3D revient en fait plus cher. Par contre, c'est plus rapide!
Alors non, ce n'est pas la raison de l'utilisation de 3D dans un film 2D. Tu vas d'ailleurs prendre bien plus de temps pour modéliser ton décor 3D que le dessiner (je le disais, la partie modélisation prend beaucoup de temps; et pour comparer entièrement avec un dessin 2D final, faut rajouter aussi textures, etc.).
La raison d'utiliser de la 3D en 2D est simplement pour faire des choses quasi-impossible en 2D. Alors c'est pas vrai que ce soit impossible (c'est du dessin, tout est théoriquement possible), mais c'est très très dur. En particulier tout ce qui est mouvement de caméra non planaire. En 2D trad, tous tes mouvements de caméra suivront un plan: tu peux aller à gauche/droit (l'équivalent d'un travelling sur rails dans le cinéma), en haut/bas, tu peux zoomer… mais tu ne vas pas par exemple tourner autour du personnage. Pourquoi? Parce que la perspective est une technique très difficile (demande à n'importe quel peintre s'il a jamais eu de problème avec la perspective, et aussi s'il est aussi fort dans tous les angles; très souvent les peintres ont des préférences de perspective), alors si en plus tu dois faire de la perspective changeante dans un même plan, c'est la mort cérébrale du pauvre artiste!
Et puis en plus, ça veut dire qu'il faut redessiner le même décor à chaque frame, alors que dans les scènes habituelles 2D, tu te contentes de redessiner les personnages et tu gardes le même décor (sur lequel la caméra peut zoomer ou se déplacer parallèlement). Sur ce point, tu pourrais dire: donc finalement, c'est bien une question de temps puisqu'il faut en fait comparer une seule modélisation de décor à X décors dessinés! Et même si tu peux avoir raison sur un plan assez long, une telle demande est surtout un coup à rendre tes dessinateurs fous: "redessine moi ce décor 20 fois en imaginant que la caméra tourne autour de ce point (le perso probablement), avec des angles de 1° entre chaque dessin". Ça s'est fait un peu (ou plus souvent, y a des moyens de tricher un peu, notamment en jouant avec les objets en premier plan, on peut faire illusion), mais y a des limites.
C'est ça la vraie raison de l'utilisation de 3D dans un film 2D.
Ben je pense que c'est la cool-attitude. La 3D, c'était le truc hype à faire pour être dans le coup. Et de nos jours, c'est l'attente usuelle. Même si la 2D au ciné existe encore et a son petit public, il faut dire ce qui est: ce n'est plus le cinéma à grand succès. Donc de nos jours, ils continuent pour suivre la demande. Y a plus de retours en arrière (du moins pas sans risque financier majeur pour une boîte dont le but est de faire beaucoup d'entrées cinéma).
En tous cas, on peut pas dire que ce soit une question de diminuer les coûts, quand on voit les budgets de production de plus en plus énormes à chaque film.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Ne plus avoir de voiture
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 10.
Mouais… je peux pas dire que je sois très content non plus des services de livraison privées. Je me souviens de pas mal de mauvaises expériences similaires (le gars qui sonne même pas et laisse un papier). Une de mes anecdotes les plus symptomatiques: je travaillais dans des bureaux en région parisienne et comme ces sociétés livrent dans les heures de bureau, ben j'avais donné l'adresse de mon boulot plutôt que chez moi, en notant bien mon numéro de téléphone portable ainsi qu'un commentaire pour dire au livreur de me demander à l'accueil (c'était une PME, l'accueil nous connaissait tous), voire simplement le laisser à l'accueil. Franchement ça pouvait pas être plus simple.
Personne n'est passé de la journée, alors le soir, je regarde le site et le livreur a laissé en commentaire disant qu'il a sonné et qu'il n'y avait personne! C'était des bureaux, il suffisait juste de montrer au premier étage de l'immeuble et la porte était ouverte. Y avait aucune porte fermée (ni en bas, ni à l'étage) ni sonnerie! En gros le livreur ne s'était pas donné la peine de rentrer dans l'immeuble (sinon il aurait su qu'y avait pas de sonnerie comme dans un immeuble d'habitation) et il n'avait pas essayé d'appeler sur mon portable non plus. Je me suis plains. Ils m'ont fait le coup une seconde fois et au final le colis est reparti à l'envoyeur (c'était un support-client qui m'envoyait une pièce; ça m'a fait perdre des semaines)! Et ce n'était pas la poste mais une des grosses boîtes privées de transport de paquet (je ne saurais plus dire laquelle pour sûr pour cette anecdote précise par contre, mais à peu près toutes m'ont fait un coup similaire une fois dans ma vie).
Alors la poste, ils sont loin d'être parfait. Ceci dit, je serais loin d'être aussi catégorique que toi sur la binarisation privé versus public que tu fais sur le sujet.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Merci LinuxFR!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Meilleures contributions LinuxFr.org : les primés de novembre 2016. Évalué à 9.
Comme d'hab, merci. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]