Jehan a écrit 294 commentaires

• [^] # Re: A l'inverse ?

  Posté par Jehan (page perso) le 09/06/13 à 14:11. En réponse à la dépêche Open Funding cherche des testeurs beta. Évalué à 5.

  

  Bonjour Sylvain,

  je ne suis pas tout à fait d'accord.
  Je fais ça sans arrêt des patchs uniques pour des projets dont j'avais jamais vu le code avant, et dont je verrai peut-être jamais plus le code si je n'ai pas besoin de corriger un autre truc.

  J'ai fait ça pour des corrections de bug — quand je rencontre un bug que les développeurs principaux n'estiment pas aussi prioritaires que moi par exemple; mais même pour des fonctionnalités, et parfois sur des vraiment gros logiciels.
  À vrai dire, c'est comme ça même pour les projets pour lesquels j'ai maintenant droit d'écriture, etc. Parce qu'il faut bien commencer quelque part et qu'on n'est jamais aussi bien servi que par soi-même! :-)

  Bien sûr, ça demande plus de travail que pour un développeur qui connaît bien le code source du projet, mais y a aucune raison que ça soit bloquant (c'est comme de l'auto-formation: une fois que le dév a fait une première fonctionnalité, il a un peu d'expérience, sera plus rapide pour une seconde sur le même logiciel, et ainsi de suite).

  Enfin bon tout ça pour dire qu'y a aucune raison que le système de prime ne fonctionne pas. Bien sûr je comprends tes dires, la peur d'avoir trop de projets sans dév qui noient les projets plus actifs dans une masse d'info, mais ce n'est qu'une question d'UI du site: s'il est bien fait, on peut mettre bien en avant les projets qui ont un dév prêt à bosser et n'attends que les fonts par rapport aux projets sans dév actif.
  :-)

• [^] # Re: Juste une petite question

  Posté par Jehan (page perso) le 09/06/13 à 00:45. En réponse au message Cherche photospectromètre à emprunter autour d'un café sur Paris ou Auckland?. Évalué à 1. Dernière modification : le 09/06/13 à 00:45

  

  Salut,

  ben écoute chez moi colormgr get-devices, ça marche, et ça me retourne mon écran, ainsi que la liste de toutes les imprimantes que j'ai configurées sur ma machine, ainsi que leur profile, leur colorspace, etc.

  Mais en dehors de cela, je ne suis pas la meilleure personne pour t'aider et te dire quel est ton problème. Je suis aussi nouveau dans ce monde du calibrage d'outil graphique. Par contre, pour autant que je comprenne, non y a pas de raison que cela ne marche pas. Il ne devrait pas y avoir besoin de cablage ou de matériel particulier pour calibrer. Tout périphérique qui a un contact visuel avec l'être humain devrait pouvoir être configurable, que ce soit un écran — quelque soit sa technologie —, une imprimante, un scanner, etc. Parce que s'il existait un périphérique ultime qui n'avait pas besoin de calibrage et qu'on considérait avoir toujours les bonnes couleurs (d'ailleurs qu'est-ce que ça voudrait bien dire?!), ben pourquoi donc utiliserait-on autre chose?! ;-)

  Donc je pense que ton problème est logiciel et je te conseille de contacter les personnes adaptées (les packagers de ta distro, ou upstream le mainteneur du logiciel).

  Et non je n'ai pas essayé de forum de photographie. Seulement la mailing liste upstream du colorhug et ici. Tu connais des forums en particulier à conseiller?

• [^] # Re: Usb Sagem Fast 800

  Posté par Jehan (page perso) le 05/05/13 à 13:44. En réponse au message Quoi installer pour vieux modem ADSL free avec connexion USB?. Évalué à 1.

  

  Salut,

  merci. Y a en effet un driver qui semble correspondre avec mon kernel de base:
  /lib/modules/3.4.34-desktop-1.mga2/kernel/drivers/usb/atm/ueagle-atm.ko.xz

  Avec tout ça, j'espère que tout ira bien alors. :-)
  Merci encore.

• [^] # Re: PC de la famille ?

  Posté par Jehan (page perso) le 05/05/13 à 13:24. En réponse au message Quoi installer pour vieux modem ADSL free avec connexion USB?. Évalué à 1.

  

  Salut,

  si bien sûr ils ont un PC. Et je prévoyais aussi de l'utiliser pour télécharger les paquets une fois sur place si j'ai pas pu le faire avant. :-)
  Simplement:

  • j'essaie d'éviter d'utiliser des PCs Windows quand je peux;
  • c'est quand même plus simple/sympa de faire ça avant et — oh! — magique ça marche direct;
  • même une fois sur place, il me faudra connaître les paquetages, donc je prends les devants en demandant un chouille en avance.

  :-)

• [^] # Re: Installation hors deb?

  Posté par Jehan (page perso) le 02/05/13 à 01:52. En réponse au journal Essai de Lightworks Beta 11.1.h sous GNU/Linux. Évalué à 3.

  

  C'est ce que j'avais fait en premier. J'avais bêtement décompressé le .deb. Malheureusement le prefix du logiciel est évidement dans le binaire, ce qui fait que je ne peux pas juste décompresser et tenter de lancer le logiciel de n'importe où.

  $ ./lightworks
  ./lightworks: ligne20: /usr/lib/lightworks/spawn: Aucun fichier ou dossier de ce type

  Je suis donc obligé d'aller copier les fichiers de l'arborescence lightworks dans /usr, et là ça me plaît pas de le faire à la main, ce pourquoi j'avais tenté de l'installer comme un rpm pour que mon système de paquetage soit capable de désinstaller tout ça proprement plus tard.
  Là aller tout copier à la main, ça implique que je dois garder une liste de tous les fichiers quelque part pour aller les virer plus tard (je peux faire ça par un script, c'est pas difficile. Mais ça implique surtout que je dois me souvenir de ça même des mois après si je désinstalle pas ce logiciel dans les jours à venir).
  Enfin voilà, c'est ennuyeux. :-/

  Sinon c'est bizarre que ce soit une lib interne car justement j'avais cherché avec find cette lib dans l'archive décompressée et y avait pas (même si y a plein d'autres avec un nom similaire, en effet, j'avais pas regardé). Donc je me demande où c'est. Peut-être que c'est une dépendance inutile? J'essaierai la proposition de Thomas Debesse ci-dessous.

  En tous cas, si le logiciel est réellement si bien (pas encore pu testé donc!), j'espère bien que la sortie promise en Libre n'est pas bidon et qu'elle arrivera vraiment. Bon j'arrête pas de respirer dans l'attente, mais ce serait cool. Pour l'instant on se contente de Blender VSE, qui est en effet loin de parfait, mais pourtant le mieux de ce que j'ai vu dans le Libre pour le montage. :-/

• # Installation hors deb?

  Posté par Jehan (page perso) le 01/05/13 à 23:36. En réponse au journal Essai de Lightworks Beta 11.1.h sous GNU/Linux. Évalué à 3.

  

  Salut,

  je sais qu'officiellement ils ne distribuent que pour ubuntu ou autres distribs utilisant des package .deb (Mint, etc.), mais j'ai quand même voulu tester sur ma Mageia. Donc j'ai téléchargé, j'ai converti le .deb en .rpm avec alien, puis j'ai essayé d'installer.

  $ urpmi ./lightworks-11.1.H-2.x86_64.rpm
  Le paquetage demandé ne peut pas être installé :
  lightworks-11.1.H-2.x86_64 (car libmc_enc_ddpp.so.7()(64bit) est non satisfait)

  Cette lib n'existe dans aucun des paquets officiels de Mageia. Le web ne semble pas non plus connaître ce fichier (0 réponse dans Google par exemple, avec la recherche "libmc_enc_ddpp.so.7"). Quelqu'un sait à quoi ce fichier correspond? Quelqu'un a réussi à installer ce logiciel sur autre chose que les plateformes officiellement supportées?
  Merci!

• [^] # Re: GEGL

  Posté par Jehan (page perso) le 02/04/13 à 16:27. En réponse à la dépêche Traitement d'image : Sortie de G'MIC 1.5.5.1. Évalué à 2.

  

  Salut,

  je vois. Si tu veux vraiment avoir tout en un comme maintenant, ne pourrais-tu faire un unique filtre GEGL dont le nom du filtre vraiment utilisé est un des paramètres du filtre unique GEGL?

  Ceci dit, même si je comprends ton idée, du point de vue utilisateur, n'est-ce pas mieux que tous les filtres soient bien intégrés dans l'interface de GIMP, plutôt qu'imposer une UI intermédiaire pour choisir un filtre de la collection? Il y en a beaucoup — et c'est bien! — donc il faut simplement les organiser par genre (menu, sous-menu, etc.) ou autre.

  En tous les cas, pour la problématique humaine, les relations ne sont pas toujours parfaites, que ce soit en proprio ou en Libre. Mais c'est pour cela que je parlais de politesse. Selon moi la meilleure façon de contribuer est de toujours rester poli et agréable toi-même, même si tu as l'impression de rencontrer des murs, des résistances, et même des paroles dures voire stupides, et simplement de persister. De temps en temps, tu reviens à la charge, toujours aimable.
  Ton software a l'air plutôt bon, et ils ne peuvent que voir cela et ce que des centaines de filtres supplémentaires de qualité peuvent apporter à GIMP. Je suis sûr qu'il y a moyen de l'intégrer sainement à GIMP comme filtre GEGL, ou bien qu'on en trouvera un.

• [^] # Re: GEGL

  Posté par Jehan (page perso) le 02/04/13 à 14:52. En réponse à la dépêche Traitement d'image : Sortie de G'MIC 1.5.5.1. Évalué à 4.

  

  Salut,

  en même temps, le but ne sera pas d'avoir deux systèmes en parallèle, mais bien d'avoir un système qui remplacera l'autre. Pour toi, à l'heure actuelle puisque tu développes activement tes filtres, cela fait du travail en double. Mais une fois que la 2.10 sera sortie, tu n'auras plus que du GEGL à développer (à moins que tu ne prévois de continuer à supporter les vieilles versions de GIMP, même pour les nouveaux développements?).

  Enfin es-tu sûr que les anciens plug-ins de filtres ne pourront plus tourner? Tu as demandé à l'équipe? Parce qu'à l'heure actuelle par exemple, dans l'arbre de développement, on a un mix de plugin vieux style et de filtres GEGL par exemple. Et je vois pas trop de raison pour qu'on casse la compatibilité avec un plug-in tiers qui cherchera à modifier directement une image, même si bien entendu on déconseillera de tels plug-ins. On porte tous les plug-ins "officiels" (ceux fournis dans le dépôt avec GIMP lui-même), mais je suis pas sûr qu'on va chercher explicitement à casser un plug-in tier non à jour. Ensuite je peux me tromper.
  Mais dans tous les cas, je vois pas pourquoi il serait intéressant de s'attacher à l'ancien système. GEGL est gagnant-gagnant pour tout le monde: les développeurs de plug-in, les développeurs GIMP, et surtout les utilisateurs!

  En tous cas, je vois que tu seras au Libre Graphics Meeting. J'assisterai à ta conf. :-)
  Et tu auras l'occasion de discuter de vive voix avec le reste de l'équipe GIMP là-bas pour mettre un peu plus au clair. Mais encore une fois, tu peux déjà demander. On traîne sur IRC (enfin moi pas trop, mais les plus gros contributeurs y passent leur journée) et ça répond plutôt aimablement aux gens polis.

• # GEGL

  Posté par Jehan (page perso) le 02/04/13 à 14:18. En réponse à la dépêche Traitement d'image : Sortie de G'MIC 1.5.5.1. Évalué à 4.

  

  Bonjour,

  les filtres GMIC sont-ils aussi développés en parallèle avec une implémentation GEGL pour être prêt quand GIMP 2.10 sortira?

  GEGL est pour moi une avancée majeure dans GIMP, en particulier car cette librairie permettra dans un second temps de travailler totalement sans perte à partir d'images sources (même si je pense que la 2.10 ne permettra pas cela immédiatement car cela demande une interface adaptée). Et pour moi, c'est une fonctionnalité énorme.
  Sinon ça a vraiment l'air cool. J'essaierai. :-)

• [^] # Re: enregistrement

  Posté par Jehan (page perso) le 07/03/13 à 22:37. En réponse au journal Une pratique acousmatique sous logiciels libres. Évalué à 2.

  

  Salut,

  la question m'intéresse aussi. Je viens de regarder les spécs de cet enregistreur, c'est sûr que ça a l'air sympa, vu de loin: enregistrement en wav, sur une carte 32GB, deux modes de charge, dont piles AA classiques (ce qui permet de pouvoir toujours charger, même en zone sans courant facile d'accès). Pour quelqu'un qui voyage, c'est plutôt sympa (même si je trouve que 4/5 h d'usage, c'est pas idéal, et que 290g aussi, j'aurais aimé moins).

  Maintenant j'y connais rien. Comment est-ce dans la concurrence? Quelle est la qualité d'enregistrement? Y a-t-il beaucoup de souffle/bruit?
  J'imagine que ce type de produit est surtout fait pour enregistrer des sons "sur le terrain", cela peut-il aussi servir pour enregistrer des sons ou voix dans un environnement intérieur insonorisés? Je pensais peut-être acheter genre une carte son externe (modèle? Je sais pas), avec un bon micro (?), etc. Une sorte de mini-studio portable. Mais comme je bouge beaucoup, c'est pas idéal. Ce genre de produit peut-il faire double emploi? Terrain et utilisation plus "studio"?

  Notez bien que je suis conscient que l'idéal est d'avoir du matos adapté différent à chaque utilisation. J'imagine bien qu'on ne peut pas comparer une petite machine de 300g avec une carte son semi-pro et un super micro, et encore moins avec un gros studio de 40m2 et une console de mixage de 100 kg. Je parle de compromis. Quand on vagabonde d'un endroit à l'autre, chaque gramme et cm3 compte. Si je peux avoir une petite machine qui a une qualité raisonnable dans diverses situations, suffisamment pour avoir un son de qualité (pas parfait, mais bon, voire très bon tout de même), sans souffle quand on enregistre du silence ou des sons faibles, etc. ben ça m'irait.

  Ce genre de machine répond-il au besoin?

• [^] # Re: Questions sur la fonctionnalité de point d'accès

  Posté par Jehan (page perso) le 22/02/13 à 20:37. En réponse à la dépêche NetworkManager 0.9.8 propose la création de points d'accès. Évalué à 1.

  

  Salut,

  Je dirais plutôt que quelqu'un s'est emmêle les pinceaux quelque part entre l'explication d'un développeur et la news.

  Bon bah j'ai regardé plus en détail. Apparemment cette technologie s'appelle 'wifi-direct', cela permet apparemment de faire facilement du p2p entre deux machines, mais a d'autres usages, comme celui de partager une connexion donc. La pub intel semble vraiment dire qu'on peut recevoir une connexion wifi puis la re-partager en hotspot, bien que les termes utilisés soient vraiment imprécis/mauvais, et en effet probablement écrit par des gens du marketing ("Connect your PC to the WLAN or the Internet, then securely share the access" -> c'est assez marrant comment ils mettent le WLAN et l'internet en parallèle, plutôt que Wifi et Ethernet, ce que "je pense" était le but).

  Donc j'ai cherché si des gens avaient effectivement réussi à faire une telle chose, puisque je ne peux pas tester moi-même sans Windows. J'ai finalement trouvé cet article en anglais où l'auteur dit qu'il a partagé sa connexion wifi comme un hotspot wifi avec succès grâce à cette technologie.

  I tested sharing of both a LAN and WiFi internet connection successfully but the My WiFi application could not share a Bluetooth DUN connection that I set up.

  => en français, il dit qu'il a testé et partagé avec succès une connexion wifi et une connexion ethernet (par contre pas une connexion bluetooth).

  Donc apparemment si c'est possible, ça existe, c'est en vente, ça marche sur des plateformes Windows, y a des logiciels avec GUI qui permettent de gérer cela sans se poser trop de question sur cet OS, et y a des gens qui ont pu testé et le disent sur des sites génériques. Ça n'a vraiment pas l'air d'un gars du marketing Intel qui s'est "emmêlé les pinceaux" avec l'explication du développeur.

  Donc moi j'ai ce genre de matériel, et ma question est vraiment de savoir si la partie logicielle existe sous Linux aussi (même un peu plus austère s'il le faut, des lignes de commande me vont aussi; du moins c'est mieux que rien).

• [^] # Re: Questions sur la fonctionnalité de point d'accès

  Posté par Jehan (page perso) le 22/02/13 à 14:56. En réponse à la dépêche NetworkManager 0.9.8 propose la création de points d'accès. Évalué à 1.

  

  Salut,

  1) Savoir si tu peux le faire dépend de la carte wifi (et de la version de ton noyau). Si tu veux quand même savoir si ta carte peut le faire, regarde la sortie de iw phy | grep -A 5 "interface combination".

  Damn, il semble que non!

  # iw phy | grep -A 5 "interface combination"
          interface combinations are not supported
          Supported commands:
                   * new_interface
                   * set_interface
                   * new_key
                   * new_beacon
  
  

  J'utilise un kernel 3.4.32 (packagé par Mageia 2) avec un driver iwlwifi.
  Mais alors maintenant je me demande vraiment ce qu'Intel promeut à ce point avec cette fonctionnalité "hotspot" (qui est la même chose qu'access point, non?) si on peut même pas à la fois recevoir et émettre en wifi!

  Merci pour la réponse en tous cas. Un jour, j'essaierai peut-être de fouiller un peu plus le sujet pour voir exactement ce qu'il est possible de faire avec ma carte et l'état du dév des drivers pour cela.

• # Questions sur la fonctionnalité de point d'accès

  Posté par Jehan (page perso) le 22/02/13 à 11:05. En réponse à la dépêche NetworkManager 0.9.8 propose la création de points d'accès. Évalué à 4. Dernière modification : le 22/02/13 à 11:06

  

  Bonjour!

  Je possède un portable avec dedans un Intel Centrino Ultimate N6300 ce qui a l'air d'être du lourd, et donc ça me rend triste de pas utiliser sous certaines fonctionnalités publicisées. Notamment j'ai toujours été intéressé par cette fonctionnalité de pouvoir créer un "point d'accès" d'après la spéc, mais j'ai jamais pu l'essayer puisque j'utilise pas Windows.
  A priori il semble que certains drivers Linux le permettent, et ce logiciel permettrait donc de gérer cela.
  Mais je me pose des questions:

  1/ est-ce que cette fonctionnalité signifie bien que je peux en même temps recevoir une connexion en wifi, et la partager comme point d'accès moi-même? Ou bien la carte wifi ne peut faire qu'une chose à la fois, donc je dois récup ma connexion ailleurs (autre carte wifi, éthernet…) et cette carte ne gère que le point d'accès?

  2/ Est-ce logiciel (pilote, etc.) uniquement ou bien aussi matériel? Genre n'importe quel puce wifi pourrait théoriquement avoir la fonctionnalité de point d'accès, ce n'est qu'une question de si quelqu'un a développé de pilotes pour cela ou non?

  Merci.

• [^] # Re: xcf-utils

  Posté par Jehan (page perso) le 18/02/13 à 14:54. En réponse au journal Outils autour de Gimp : Pack My Sprites et Xcftools. Évalué à 2.

  

  Salut,

  ça je comprends bien. Il s'agit du format d'échange, non du format de travail. De même de des développeurs ne donnent pas seulement un code source aux utilisateurs, mais ils leur donnent une version binaire prête à l'emploi d'un double clic.

  Maintenant laisse moi te donner un exemple:

  Tu fais ton sprite. C'est un bonhomme tout petit, et il bouge pas beaucoup. Mais il bouge quand même les pieds au moins quand il marche, probablement les mains aussi, peut-être même qu'il tourne la tête.
  Qu'est-ce que tu fais quand tu veux faire les diverses versions de sa démarche? Bien sûr, tu peux faire le petit bonhomme complet, puis tu dupliques le calque (ou tu fais une autre image, ou que sais-je), et tu changes juste un peu les pieds, puis les mains, puis tu re-dupliques le calque, etc. Tu fais autant de calques/images que de frames.
  Mais voilà, un jour, tu veux changer son corps. Un truc tout con: tu trouves que la veste rouge lui va pas. Tu veux la faire bleue. Bah! Facile. Tu dois changer la couleur de la veste sur chaque frame finie de l'animation! Donc tu recharges chaque png un à un, et tu modifies la veste.
  Pourtant le corps est exactement le même sur chaque! Mais tu multiplies ton travail par le nombre de frame/png.

  Maintenant plutôt que faire cela, voilà ce que tu pourrais faire: tu fais le corps qui bouge jamais sur un calque, deux versions de la tête (une à gauche, une à droite, ou que sais-je), trois versions des bras (balancés d'un côté ou de l'autre, ou au "repos"), pareil pour les jambes. Et tu as maintenant 1 * 2 * 3 * 3 = 18 frames différentes en seulement 1 + 2 + 3 + 3 = 9 calques (avec juste quelques pixels par calque. Dans ton cas, un calque, c'est juste les bras par exemple). Et le jour où tu veux changer la couleur du corps, tu changes seulement deux calques, puis tu lances un script (que tu as écrit à côté) qui regénère tes 18 frames de png en 1 centième de secondes.
  Puis le jour où tu veux changer plus, facile aussi, et fait en quelques secondes.
  En travaillant que sur des png par contre, ce jour là où tu veux faire un gros changement sur ton bonhomme, t'es vraiment dans la merde, et tu peux tout aussi bien tout reprendre du début.

  Julien Jorge dans ce journal a montré un très bon exemple de ce workflow dont je parle, et que tu as tout intérêt à prendre dans ton cas aussi. Regarde bien sa copie d'écran. Il a un layer pour le corps, des layers pour diverses positions pour chaque aile, etc.
  Moi c'est encore pire. On fait des dessins animés. Genre 10, 24 ou plus images par seconde, taille HD. Tu te rends bien compte que si je recopiais des éléments fixes à chaque frame, le jour où je veux changer cet élément (qui bougeait pas pendant genre 10 secondes par exemple, donc quelques centaines de frames!), c'est mort, on se tire une balle.

  C'est pour cela que tu devrais vraiment travailler avec des XCF, sauver tes XCF et même les versionner (les png par contre, sauf cas particulier, ne les versionne pas si tu peux éviter. C'est du généré! Pas du source). Ton application finale, elle utilisera toujours des png, qui seront générés automatiquement à partir des tes XCF par une commande dans le Makefile (ou autre système de compilation), ce qui fait que tu as jamais à t'en préoccuper, mais tu bosses uniquement sur les XCF. Tu ne devrais même pas à avoir à exporter à la main dans GIMP en png en fait. Tu te rends compte si tout le monde faisait cela? On n'utiliserait jamais GIMP! Ou alors tu veux te limiter à une dizaine de persos dans ton jeu, ou alors tu aimes le boulot chiant de fourmi (afficher le layer, masquer avant, exporter, afficher, masquer, exporter, etc. 1 fois par frame), ou alors tu prévois de sous-traiter en Inde. :-D
  Non on ouvre GIMP, on fait la partie "intéressante" (on dessine), on sauve, on ferme GIMP, et on veut taper Make, et basta. C'est fini. On a un jeu (dans ton cas) compilé avec de nouvelles images juste finie. :-)

  Ce que tu es en train de faire là, c'est l'équivalent pour un programmeur de bosser directement sur la source compilée, ou plutôt sur du code généré: tu as un code, tu le compiles, puis tu jettes ton code original. Et lorsque tu veux modifier ton code, tu bosses à partir de la version générée que tu recompiles, puis tu rejettes, etc. Bien sûr c'est encore faisable car dans ton cas ton code "compilé" (png) est moins barbare qu'un binaire, mais ça reste de la donnée générée, avec tout ce que cela implique (perte de donnée, complexification, etc.).

  D'ailleurs je viens de revoir à nouveau ton post sur nanim, tu écris

  Enfin, il faut recommencer pour toutes les positions clefs de l'animation, n'ayant pas la possibilité d'engager une armée d'intervallistes, je me suis contenté de 5 frames

  Forcément, tu redessines tout à chaque fois! Alors que si tu avais séparé avec des calques, et généré avec un script tes pngs, t'as juste à dessiner une nouvelle position des bras, et paf t'as une nouvelle frame.

• [^] # Re: xcf-utils

  Posté par Jehan (page perso) le 18/02/13 à 13:11. En réponse au journal Outils autour de Gimp : Pack My Sprites et Xcftools. Évalué à 2.

  

  Salut,

  As tu des détails sur ce qui empêche la libgimp d'être utilisé hors de Gimp ? Qu'attend-elle de l'application qui la charge ?

  Techniquement aucune idée. J'imagine qu'à l'origine pas grand chose, mais à l'heure actuelle, changer cela doit être vraiment compliqué.
  Théoriquement, je vois personnellement aucune raison. Je vois pas pourquoi on pourrait pas avoir une libgimp totalement indépendante, et GIMP utiliserait cette libgimp (et d'autres applications pourraient aussi). C'est à vrai dire ce que je ferais si je développais GIMP de zéro aujourd'hui (à vrai dire, pour tout "gros" projet que je fais, c'est le type de design que je fais: baser le programme sur une librarie indépendante qui implémente le cœur des fonctionnalités).
  Historiquement j'imagine qu'à l'origine les développeurs n'ont fait la libgimp que dans l'idée d'avoir des plugins. Ils n'ont pas dû s'imaginer à l'époque que des gens pourraient vouloir ouvrir des fichiers XCF hors de GIMP.
  Factuellement une application indépendante ne peut faire un include de la libgimp. Tu peux essayer, tu peux compiler, et au moment de lancer, ça dit ça:
  bash
./test is a GIMP plug-in and must be run by GIMP to be used

  Même erreur si ton plugin est python, C, script-fu, etc. Tu dois donc lancer d'abord la console gimp et de là lancer ton script.

  Au sujet des fonctionnalités, le seul outil qui m'intéresse dans Xcftools est xcfinfo. Pour tout ce qui concerne les opérations sur l'image j'utilise des scripts Scheme que je passe à gimp-console. Du coup ton outil me conviendrait bien à ceci près que j'aimerais que cela fonctionne sous Windows. J'ai commencé à migrer Xcftools pour pouvoir livrer une version Windows mais ça me semble plus difficile avec ton outil qui utilise des scripts shell.

  Ok donc tu pourrais utiliser mon outil en effet (xcf-info, note le tiret, pour pas empêcher les gens qui veulent tester les deux).
  En plus je me suis réveillé ce matin en me disant "pourquoi je l'ai pas écrit en C?". En effet le plus problématique de mon script est sa lenteur. Or la lenteur est dûe à 3 facteurs:
  - on charge GIMP (sans UI, mais quand même): ça, je peux rien y faire;
  - je fais un hash de chaque image de layer: ça c'est pour moi une fonctionnalité indispensable pour rendre xcf-info utile lors d'un git diff;
  - c'est du python.
  Sur des petits XCF, c'est raisonnable, mais je travaille avec des XCF en HD (1920x1080) avec des dizaines de calques, si ce n'est une centaine, de calques.
  Donc comme je disais, ce matin, je me suis dit que le fait que ce soit en python est le seul truc que je peux changer. J'ai donc passé plusieurs heures à réimplémenter mon xcf-info en C (j'ai au passage découvert et corrigé un bug dans gimptool, c'est une bonne journée). Il est maintenant 2 à 3 fois plus rapide que la version en Python. J'ai quasi fini. Je pense que je pousserai ça sur le dépôt un peu plus tard aujourd'hui.

  Pour le petit script shell, il fait genre une dizaine de lignes, tu l'as regardé? En gros il se contente d'encapsuler l'appel à gimp-console (parce que c'est une ligne de commande à se taper la tête au mur si on voulait retenir cela), rien d'autre (j'ai quelques lignes pour simuler un --help, mais c'est pour faire joli, y a en gros qu'une seule ligne qui sert à quelque chose en fait). Je sais bien que le shell Windows est nul comparé même aux shell Unix les plus basiques, mais ça je pense que ça peut forcément le faire quand même.
  Si tu fais ce petit script Windows, n'hésite pas à m'envoyer le patch, je l'intégrerai pour les plateformes Windows. :-)

  Je migre le journal dans l'espace de rédaction. Es-tu intéressé pour y présenter xcf-utils ?

  Bien sûr.

• [^] # Re: xcf-utils

  Posté par Jehan (page perso) le 18/02/13 à 12:34. En réponse au journal Outils autour de Gimp : Pack My Sprites et Xcftools. Évalué à 3.

  

  Salut,

  je pense qu'il y a incompréhension. Le but n'est nullement de "forcer" l'utilisation de XCF. C'est simplement que XCF est le format de GIMP. De même que si tu sauves dans Blender, ça sauve un .blend (tu peux pas sauver autre chose), qui est le format de Blender et pas plus fait à servir de format d'échange avec un autre programme non plus. Si tu veux un autre format qui n'est pas le format natif du logiciel, eh bien tu "exportes". Par exemple tu peux essayer d'exporter ton XCF en png, ou en PSD, etc. Et tu peux exporter ton blend en 3ds, etc. Pareil pour Audacity ou Ardour. Tu ne "sauves" que dans leur format respectif, mais si tu veux un fichier son (vorbis, flac, etc.), tu "exportes".
  Ce sont des logiciels qui ont fait le choix de faire une différenciation entre une sauvegarde et un export. Plein de logiciels font ce choix, alors que d'autres ont un design où ils mélangent les deux fonctionnalités (par exemple LibreOffice permet de "sauver" dans son format OpenDocument natif, et d'exporter en .doc avec la même fonction).

  Alors pourquoi différencier? Parce que le format natif est adapté au logiciel, toutes les fonctionnalités y sont, donc il n'y a pas de perte de données. Quand tu sauvegardes ton travail en XCF dans GIMP, tu ne perds aucune donnée (c'est un peu faux, il y a un type de données qu'aucun format de dessin ne sauve: l'historique. Donc à l'heure actuelle, aucun format graphique n'est parfaitement sans perte). Si tu "exportes" en png, tu obtiens un image plate, tu perds tes calques, tes masques, tes chemins, ta sélection. Pire si tu exportes en jpg, tu perds même en image (puisqu'il y a perte de qualité). Donc l'idée est que tu travailles toujours en XCF, qui est le format qui a tout ce que fait GIMP. Puis au dernier moment, quand tu es content de ton travail, tu "exportes" dans un format fait pour être visionné, ou échangé, etc.
  Il est bien moins grave que quelqu'un ait à exporter (ce qui ne prend pas plus de temps, juste un raccourci différent) plutôt que le risque que quelqu'un qui aille un peu vite perde des données (perde ses calques, etc.).

  Hormis cela, GIMP n'a absolument aucune intention de "pousser" le format pour une utilisation générique, bien au contraire. Il a toujours été clair que XCF, c'était pour GIMP, pas plus. Y a d'ailleurs d'autres logiciels qui ont apparemment forké le format XCF, mais ça a divergé depuis et ce sont donc maintenant des formats différents.

  Pour servir de format d'échange qui conserve certaines fonctionnalités, il y a OpenRaster qui est développé en collaboration par les équipes de divers logiciels Libres, et dit s'inspirer d'OpenDocument, pour les images raster (= bitmap, ce n'est donc pas un format vectoriel). Mais ça reste encore super basique. J'ai lu la spec (qui ressemble plus à un brouillon sur un bout de table d'ailleurs pour l'instant) en 5 minute top-chrono, elle est extrêmement incomplète, imprécise et a peut-être un vingtième des fonctionnalités de XCF (en gros, ça supporte les calques et groupe de calque, et basta! C'est tout).
  La mailing list, sur laquelle je suis inscrit depuis des mois, est aussi quasiment silencieuse.
  Alors attention ce n'est pas une critique. Comme tout projet Libre/Standardisation, c'est animé par ceux qui sont intéressé. Les coupables, c'est nous, donc moi aussi. Pour ma part, j'ai juste fait 2/3 messages sur la liste, et un patch sur la librairie libora, c'est tout. J'ai justement pas mal de propositions, mais faut que je me fasse le temps.
  Le jour où OpenRaster a l'ensemble des fonctionnalités de GIMP, alors peut-être qu'on réfléchira à en faire notre format natif, tout comme LibreOffice utilise maintenant le standard OpenDocument. Si un logiciel comme MyPaint a pu déjà en faire son propre format natif, c'est seulement parce que le logiciel n'a aucune fonctionnalité avancée (pour le dessin même, il paraîtrait qu'il est mieux que GIMP, mais hors cela, il est très basique). En attendant ce n'est pas une solution viable.

  Notez que pour la 3D, ils ont le format d'échange COLLADA qui ressemble bien plus à quelque chose. Bon j'ai jamais lu, et je n'ai aucune idée de la qualité. Mais y a un vrai organisme de standardisation, des sociétés qui soutiennent, c'est vraiment beaucoup utilisé, et la spéc fait des centaines de pages. Ensuite aucune idée si un jour Blender va échanger son format blend avec Collada. Blend fait beaucoup de choses aussi, dont certaines sont peut-être unique. Le format COLLADA contient-il tout blend? Aucune idée.

• # xcf-utils

  Posté par Jehan (page perso) le 17/02/13 à 11:34. En réponse au journal Outils autour de Gimp : Pack My Sprites et Xcftools. Évalué à 8.

  

  Salut,

  au sujet de xcftools, j'avais également envoyé un patch pour un problème de compilation, il y a quelques mois (novembre). Je vois que t'en as corrigé d'autres mais pas celui que j'ai eu d'ailleurs, donc je viens de t'envoyer mon patch par email, pendant qu'on y est. Et tout comme toi, je n'avais aucune réponse de l'auteur originel. Enfin pareil, la reprise de ce code ne me motive pas. Non pas qu'il est mauvais ou quoi (je m'en souviens même plus depuis le temps), mais que d'après moi ces outils ont un problème de base: ils réimplémentent le format XCF séparément de la libgimp. Ce serait OK si XCF était un format standard (comme OpenRaster dont parle quelqu'un plus haut) avec une spéc donnée. Mais voilà, XCF est considéré par l'équipe de GIMP comme un "dump" de l'organisation interne d'une image GIMP. Bien sūr, l'équipe fait en sorte qu'on puisse toujours lire des vieux fichiers XCF dans GIMP même, mais ça ne va pas plus loin (pas de volonté de format stable en dehors de l'utilisation dans GIMP même). D'ailleurs la seule doc qui existe du format XCF est justement celle qui fut écrite par Henning Makholm, celui à l'origine des xcftools (et cette doc est intouchée depuis 2009, il manque donc plein de trucs dedans). En d'autre termes je trouvais que réimplémenter un outil qui faisait pareil que la libgimp, c'était un mauvais plan de base (aussi bien cela soit-il techniquement, juste difficilement maintenable).

  Alors la libgimp a un problème tout de même: elle nécessite GIMP. Ce n'est pas une librairie indépendante et tout outil qui charge la libgimp doit nécessairement être lancé par GIMP même.
  J'ai essayé d'en discuter un peu avec l'équipe GIMP, mais même si je pense que personne ne serait contre si quelqu'un se chargeait de patcher GIMP dans ce sens, si personne ne le fait, les dévs actuels n'en ont pas l'utilité, donc c'est loin d'être une priorité (ce que je comprends). Et bien que je sois un dév GIMP moi-même depuis quelques mois, ce n'est pas non plus ma priorité comparée à d'autres corrections et fonctionnalités que je veux intégrer (surtout qu'une libgimp indépendante serait un énorme boulot, c'est loin d'être anodin).
  La proposition d'un autre dév était qu'il était probablement plus simple de pousser le support de XCF vers GEGL, ce qui est intéressant mais pas la solution selon moi. Car ce qui est intéressant dans la libgimp, c'est pas uniquement charger, convertir ou faire des opérations sur le format, c'est aussi toutes les autres fonctions pour travailler sur un fichier XCF et qui ne se retrouveraient pas dans GEGL (des opérations sur les calques, les masques, les chemins, parasites, etc.).

  Ma solution a donc été de réimplémenter ce que je souhaitais des xcftools dans un script shell qui encapsule l'appel à GIMP, lancé sans UI. On ne voit donc absolument pas que ça lance GIMP console, bien que ce soit tout de même une dépendance du script. Cependant je me suis dit que la dépendance GIMP ne devait pas être un problème pour quiconque veut travailler sur des XCF a priori.
  En outre, cela n'empêche nullement de l'utiliser sur un serveur sans serveur graphique non plus, par exemple pour des crons, des hooks, ou autre script automatique, puisqu'il est possible de compiler GIMP sans UI avec l'option --enable-gimp-console (note que je n'ai pas personnellement testé).
  Au final cela fait donc un script python de quelques lignes qui peut faire tout ce que fait xcftools, mais en mieux, et de manière certifiée conforme, puisque ça utilise la libgimp. Aussi y a le support des groupes (qui était effectivement un point manquant pour moi), mais aussi je fais un hash du bitmap dans chaque calque.
  Mon but d'utilisation des xcftools était en effet principalement pour faire un diff entre deux images afin de l'intégrer à mon flot de travail git.
  Cela fait qu'en cas de conflit, ou simplement pour voir un historique, je sais si entre deux commits, il y a simplement eu un changement du nom du layer, ou de son contenu, si un layer a été juste déplacé. Je peux même repérer un layer dont le contenu a été changé, le nom aussi, puis déplacé! Ou bien si c'est juste l'offset qui change, etc.
  En gros en cas de conflit, on fait comme avec du code, on voit ce qui a changé, et si ce sont des layers différents, ou juste des renommages de calque, pof! On peut merger (à la main) sans risque!
  Bon note que ce hash et le fait que ça charge GIMP rend mon xcf-info vachement plus lent que le xcfinfo des xcftools. Mais je trouve personnellement xcfinfo quasi inutile pour un diff (aucun moyen de savoir si un dessin a changé, juste les noms/dimensions/alpha!). Donc ça reste une meilleure option pour mes besoins.

  Enfin bon, je viens de créer un projet xcf-utils sur mon compte TuxFamily pour y déposer mon code. Comme ça quiconque souhaite peut y jeter un coup d'œil et/ou l'utiliser. Je pense que c'est un code bien plus pérenne, et en mēme temps 100 fois plus simple. Tu peux faire un checkout du code là:
  git clone git://git.tuxfamily.org/gitroot/xcfutils/xcfutils.git
  (ou web: http://git.tuxfamily.org/xcfutils/xcfutils?p=xcfutils/xcfutils.git;a=tree)

  Par contre, je pense que toi, tu es surtout intéressé par xcf2png/pnm. Je n'ai pas réimplémenté cela pour le moment, bien que je compte faire quelque chose dans le genre, et pour quelque chose d'assez similaire à toi, puisque c'est pour faire des animations. En fait je travaille sur tout un workflow d'animation qui utilise GIMP pour le dessin. Mais ce code sera pour une prochaine release quand tout sera bien en place. :-)
  C'est en gros basé sur le code du plugin animation-playback, mais en bien meilleur (pas juste 1 calque = 1 frame) et avec plein de features plus avancées, mais en restant simple (GAP par exemple est une usine à gaz qui essaye presque d'implémenter un NLE dans GIMP, selon moi!).
  Mais tu peux toujours t'inspirer de mon code, et surtout de comment j'utilise un bête script shell pour en gros lancer un plugin GIMP indépendant. Ça veut dire que si tu peux faire un plugin GIMP (et comme on peut presque tout faire en plugin…), alors tu peux aussi le lancer comme un simple script shell! C'est toute l'idée.
  En tous cas, perso je veux pas m'embêter avec ce code C qui duplique toute une logique de libgimp, mais avec qques années de retard. Fais ça en quelques lignes de code (soit script-foo, soit python) en quelques minutes. :-)

  Bon ensuite on peut considérer que c'est un gros hack. Mais il sert à remplacer xcftools qui est — selon moi — un hack encore plus gros.
  L'idéal serait définitivement d'avoir une libgimp indépendante, mais cet idéal n'existe pas encore. :-)

• [^] # Re: Lapin compris

  Posté par Jehan (page perso) le 13/02/13 à 04:47. En réponse au journal Mise à disposition progressive du contenu: bonne idée.. Évalué à 1.

  

  Merci pour le commentaire, c'est super intéressant et avec des chiffres! Probablement une mine d'or pour d'autres dessinateurs qui n'ont jamais eu ce genre de cours et se demandent combien ils pourraient toucher avec la BD.

  On commence toujours avec une avance sur les droits : l'éditeur prend un risque et nourrit un auteur. Il achète des pages, puis les revend.

  C'est vrai que je savais qu'il y avait un fixe aussi. J'y pensais pas parce que le journal et ce blog post que j'avais trouvé n'en parlait pas. Mais bon ça change pas tant que ça ce qui est dit au sujet du pourcentage. :-)

  • L'éditeur achète les pages, puis l'auteur touche un pourcentage sur chaque vente. En gros, l'avance+le droit d'auteur. C'est le Nirvana.
  • L'éditeur achète les pages. L'auteur ne touche rien immédiatement, mais à partir d'un certain volume de vente, l'avance de l'éditeur a été remboursée, et l'auteur commence enfin à toucher ses droits d'auteur. C'est un modèle plus répandu que le précédent, mais comme il y a beaucoup d'auteurs, beaucoup de BDs, bref, beaucoup de concurrence, les cas où l'avance est remboursée et où l'auteur peut toucher ses droits ne sont pas si courants.

  Ça correspond donc au cas où on a la proportionnelle (droits d'auteur) uniquement, mais avec un minimum.

  • L'éditeur achète les pages. Puis il vend, et une fois l'avance remboursée, il garde le surplus. Ça a été le contrat le plus merdique pendant longtemps.
  • L'éditeur achète les pages. Puis il vend. Si il vend pas assez, l'éditeur demande remboursement à l'auteur. Le cas a été évoqué, mais sans source. Je n'affirmerais donc pas que ça se fait, mais je le précise quand même, parce que notre prof nous avais dit que ça se faisait (surtout chez les éditeurs récents). (si cette dernière phrase vous donne l'impression que je suis un benêt, c'est que j'en suis un ;-))

  Oui ça c'est vraiment salaud. Comme je dis dans un autre commentaire, l'auteur aussi a pris un risque. La BD est peut-être pas terrible, mais en plus de presque rien toucher, on nous demande de rembourser, après avoir bossé un an complet et avoir fini le projet?! En plus, c'est pas forcément un problème de qualité de la BD; même si la qualité est bien évidemment une composante du succès, on sait tous que parfois des trucs qu'on va trouver nul ont pourtant un succès fou, et vis-versa. D'ailleurs on pourrait renverser la situation: l'auteur pourrait penser que la BD fait un flop non pour sa qualité, mais parce que l'éditeur n'a pas correctement fait le marketing et publicisé la BD comme il l'aurait dû. En un sens l'auteur donc pourrait accuser l'éditeur d'incompétence et lui demander de lui verser des dommages et intérêts. Ce serait la même chose selon moi, juste dans l'autre sens. Je trouve donc cela profondément malsain. J'espère que ce cas est plus théorique qu'autre chose.

  Je parle bien sûr ici du modèle de rémunération traditionnel. C'est vrai que dans le schéma de distribution classique, l'éditeur ne touche pas tant que ça, et l'auteur encore moins. En économisant les coûts de production et de distribution, il doit être plus rapide de rembourser la bande dessinée.

  Voici les rémunérations « traditionnelles » qu'on nous avait appris (moins cher, on commence à se faire entuber) : Pour une planche, 80€ le scénario, 160€ le dessin (couleur comprise). Une bande dessinée de 45 planches rapporte donc à l'auteur 10800€ s'il fait le scénario et le dessin. La dite bande dessinée met souvent un an ou plus à sortir (il y a des auteurs plus prolifiques, mais on veut de la qualité ;-)).

  Tout comme l'auteur se fait payer au fur et à mesure qu'il livre les planches à l'éditeur, on peut supposer qu'il trouvera un moyen de se rémunérer en sortant ses planches une par une (ou deux par deux, qu'est ce que j'en sais ⸮). La condition pour survivre est donc de gagner 240€ par planche mise en ligne. Ou moins si on est assez productif. Comme ce montant est celui que l'auteur touche pour une planche dans le schéma traditionnel, il n'y a plus à supprimer le coût d'impression, de distribution, etc. (c'est déjà fait). Par contre, ça ne prend pas en compte les charges sociales et tout ce bazar que je ne maîtrise pas (comme si je « maîtrisais » ce qu'on a juste vu deux-trois fois en cours… :-°).

  Ok, tous ces 3 paragraphes là, tu parles d'un schéma avec diffusion internet uniquement, et sans distribution papier? (puisque tu parles de planches mises en ligne)
  En tous cas, 10800 euros par an, surtout si c'est brut, c'est vraiment pas énorme. J'espère que si un auteur fait ce genre de choses, il fait plus d'un projet à la fois. Sinon il mangera pas beaucoup. uhuh
  D'ailleurs oui tiens, les chiffres que tu donnes dans ton commentaire sont bruts (bon ça a l'air brut, puisque tu parles de charges sociales après coup, mais je demande juste pour être sûr) ou nets? Ça change beaucoup de choses.

  Je n'ai pas fait d'étude de marché ou quoi que ce soit d'approchant. Donc, je ne dirais pas « c'est facile » ou « c'est trop dur, n'importe quoi ». Mais quand je lis « l'auteur se fait 0.1€ par BD vendue » ou « il se rémunérera comme avant », ça ne me parle pas. Déjà, parce qu'avec l'avance de l'éditeur, un auteur peu se faire bien plus (cas de la BD qui est tellement nulle qu'elle ne se vend qu'une fois, l'auteur se fait 10000€ sur la BD (par contre il a plus de contrat…)). Et que s'il se coupe de l'éditeur, il va peut être gagner 0.1€ par BD, mais il sera rémunéré au nombre de BD réellement vendues, pas à une estimation ou un espoir de l'éditeur.

  Tiens oui, t'as jamais donné d'idée de prix pour le fixe avant. Quand tu dis 10000€ ici, c'est le genre de somme habituelle? Ou bien c'est juste un chiffre sorti du chapeau pour l'exemple? C'est quoi les tarifs les plus courants pour les fixes dans les 4 cas que tu donnes (j'imagine que selon le cas, ça diffère. Si y a pas ou moins de pourcentage en particulier, j'espèrerai au moins un meilleur fixe)?

  Sinon avant-dernière question: que se passe-t-il quand l'auteur ne finit pas le projet? Rupture de contrat et il rembourse le fixe entier?

  Et dernière: que se passe-t-il si l'auteur est en retard sur le projet (il finit, mais ça prend plus d'un an)? Y a-t-il en général des deadlines à respecter? L'auteur a-t-il dans ce cas un malus sur ce qu'il va toucher? Et s'il est possible d'avoir un malus, peut-il avoir un bonus s'il finit en avance?

  Bon voilà, c'est tout pour aujourd'hui. Désolé pour toutes ces questions, c'est cool d'avoir quelqu'un qui a des chiffres. :-D
  Aussi t'as un site web avec certains de tes dessins?

• [^] # Re: Lapin compris

  Posté par Jehan (page perso) le 13/02/13 à 04:18. En réponse au journal Mise à disposition progressive du contenu: bonne idée.. Évalué à 2.

  

  Il y a tout de même un gros risque pour l'auteur aussi.
  Un auteur met souvent un an pour faire une BD, c'est pas rien. Et c'est un temps qu'il a passé avec un revenu faible (juste cette avance). C'est pas juste un gars qui a une "idée", un jour où il discute au bistrot du coin avec un pote, et qui est jaloux parce qu'il l'a pas mise en pratique (parce qu'il a pas cru en sa propre idée jusqu'à ce qu'il voit qu'elle aurait en fait marché?) mais qu'un autre le fait et se fait des couilles en or. Non, là le mec il a passé un an de sa vie sur son projet et si ce projet (BD) est génial et devient un énorme succès ou fait un flop, ça change rien pour lui. J'aimerais pas ça. Et je trouverais ça merdique, perso.
  Et tout cela est indépendant de la qualité de ton travail. Même si ta BD est nulle, t'as quand même pris ce risque d'y passer un an entier (parce que toi, apparemment, t'y croyais quand même).

  Alors certes l'éditeur prend un risque en mettant de l'argent sur la table de suite, mais l'auteur prend aussi un risque en passant un an de sa vie à dessiner/scénariser/autre. C'est en gros la différence entre être employé et être indépendant. Dans un cas, on bosse pour un fixe, et on s'en fout de faire du bon boulot (on est payé pareil quoi qu'il arrive), dans l'autre on est son propre patron et on veut vraiment réussir (l'éditeur là n'est plus notre patron, mais serait plutôt considéré comme notre client à qui on a sous-traité production/distribution/marketing).
  Bien sûr le fixe peut être bon ou non. Tout comme ton salaire en tant qu'employé peut être bon ou non. C'est une autre histoire. T'as beau avoir un beau fixe/salaire, tu n'as pas moins pris ton année pour réaliser ton projet sans savoir s'il aurait du succès (temps que tu aurais pu passer autrement).

  En plus (mais ça c'est personnel), mais pour moi le risque temps est plus contraignant que le risque argent. Bon l'argent voilà, ça se gagne, ça se perd. Surtout si on en a déjà un montant raisonnable (ce qui est en général le cas en tant qu'éditeur), et tant qu'un autre auteur nous en fait gagner, c'est le jeu d'en perdre un peu par ailleurs. Par contre ton temps, tu le re-gagnes jamais. Si t'as "dépensé" un an de ta vie à peaufiner une BD, tu re-gagnes jamais ton année. C'est fini. C'est à réfléchir bien plus, quand il y a un risque de flop (et il y a presque toujours pour une BD, sauf si t'es déjà célèbre). Donc on devrait pas se lancer ds un projet de BD sur un coup de tête probablement, réfléchir sur le meilleur, choisir, et décider.
  En d'autres termes, il y a bien un risque selon moi.

• [^] # Re: Lapin compris

  Posté par Jehan (page perso) le 11/02/13 à 18:44. En réponse au journal Mise à disposition progressive du contenu: bonne idée.. Évalué à 10.

  

  Comment il va se rémunérer? Ben comme avant…
  Tu crois que sur les 9 euros de BD papier dont parle cet auteur, il touche plus que les 1 euros? Alors qu'on arrête pas de parler constamment du fait que les intermédiaires (éditeurs, distributeurs…) touchent bien plus que les auteurs dans beaucoup métiers artistiques?
  Tiens le premier résultat sur une recherche web "pourcentage que touche un auteur sur une bd": http://blog.marcpautrel.com/post/2008/03/08/Le-pourcentage-de-droits-dauteur-en-2008

  En gros, l'auteur sur ce blog dit qu'il accepte de toucher minimum 10% sur le prix du livre, mais on comprend par son coup de gueule blogué que ces 10% sont loin d'être acquis et que beaucoup d'éditeurs essaient de proposer moins (genre 8% apparemment). Et apparemment en lisant les commentaires, on lit que les auteurs jeunesse peuvent même toucher beaucoup moins (genre 3 ou 6%).
  Sans compter que si tu es auteur littéraire, tu touches seul tes 10%, mais en BD, ils sont souvent deux (scénariste, dessinateur; dans des cas plus rares, j'ai même vu 3, quand on rajoute un coloriste), donc ils se partagent ça.

  Donc maintenant avec l'exemple de ce tweet qui parle d'une BD papier à 9 euros. Supposons que cet auteur bosse seul (il dessine et écrit le scénar), et qu'il sait bien négocier (parce qu'il a déjà un peu de notoriété, d'expérience notamment, et peut-être une plus grande gueule que son timide collègue, c'est pas forcément donné à tous). Il touche donc dans un tel cas idéal… 0,9 euros par bd papier vendu!
  Là avec ses 1 euro en auto-édition, il gagne donc plus. Alors bien sûr, il faut voir qu'il a plus de boulot (se faire sa promotion seul, publier, faire un site web, etc.). Les 0,1 euros de différence sont pas forcément si avantageux sur le coup (je pense que c'est équivalent dans ce cas). Mais je pense que s'il monte dans ce cas à 2 euros (plus du double de ce qu'il toucherait dans un schéma classique!), il peut tout à fait se permettre le surplus de boulot, ou bien utiliser sa rémunération soudainement doublée en payant une plateforme de distribution web, ou bien un développeur pour faire un site web et/ou des "apps" pour appareils mobiles, etc.

• [^] # Re: Vitrines à pubs

  Posté par Jehan (page perso) le 19/01/13 à 12:35. En réponse à la dépêche Wikivoyage lancé officiellement. Évalué à 6.

  

  Salut,

  bon c'est mon dernier message sur ce sujet, parce que je me fais un peu prendre pour un idiot et je veux pas faire de, ni participer à, un troll. Mon premier message était une erreur déjà où j'ai un peu réagi à chaud; j'aurais jamais dû lancer la discussion. Donc je vais répondre cette fois, puis j'arrête. Aussi comme je l'ai dit dans une autre réponse, chacun fait comme il veut. Désolé d'avoir laissé entendre le contraire.

  Juste pour ce dernier message, cependant, je rappelle que j'ai dit que j'étais vagabond. Donc je ne suis pas allé en Ouzbékistan, mais je suis passé un petit mois au Kazakhstan voisin, de même qu'en Russie, Turquie, j'ai traversé la Mongolie, et plusieurs dizaines d'autres pays. Et je t'assure que je ne parle pas les langages de la plupart des ces pays, ou à peine (c'est à dire ce que j'apprends sur place, certainement pas assez pour philosopher), mais ça ne m'a pas empêché de communiquer, même sans langage commun. Et je n'ai jamais vexé personne à ma connaissance pour mon manque de manière.

  Aussi je n'ai aucun problème pour aller dans des endroits dits dangereux. Et je n'ai pas peur non plus de boire de l'eau partout dans le monde (je ne bois pas d'eau en bouteille en général). La notion de "potable" est très relative, et ce que beaucoup de pays occidentaux va considérer "non potable" est en fait tout à fait buvable. Alors ensuite y a des fois de l'eau "réellement" non potable, c'est à dire qu'elle est empoisonnée en gros. Quand ça arrive, on trouve d'autres solutions. Par exemple j'ai en général sur moi des pilules pour assainir l'eau (ce qui permet même de boire de l'eau boueuse, de l'eau de marais, etc.); mais même ce sont des cas extrêmes, et honnêtement c'est rare. Encore une fois, la plupart des gens s'imaginent le monde non occidental pour bien pire qu'il n'est. Attention je ne dis pas qu'il n'y a pas des endroits dangereux. J'ai déjà été attaqué, j'ai été confronté à des armes (Albanie, Russie, etc.) et des représentants de l'ordre véreux (Azerbaïdjan ou Mongolie par exemple. Notez que je n'ai jamais donné le moindre de pote de vin dans ce cas; la plupart des "recommandations" justement vous diront l'inverse pour éviter les "risques"), des problèmes techniques, etc. Mais tout ce que j'ai vécu, ce n'est pas ce que l'on lit dans les guides ou voit dans les films. Je n'ai nullement besoin de recommandation sur comment faire le bon touriste occidental ou comment être 100% prudent et n'aller voir que des attractions touristiques dont je n'ai pas grand chose à faire.

  Encore une fois, c'est juste moi. Si d'autres ont compris que je dis que le voyage organisé est mal, je suis désolé (à nouveau) pour le malentendu ou mon manque de tact (comme quoi, c'est pas pour les autres pays que je devrais prendre des cours de politesse :p).
  Sur ce, je ne répondrai plus sur ce fil de discussion.

• [^] # Re: Vitrines à pubs

  Posté par Jehan (page perso) le 18/01/13 à 18:20. En réponse à la dépêche Wikivoyage lancé officiellement. Évalué à 5.

  

  Salut,

  Marrant, sûrement, mais tu peux quand même louper de sacré trucs. Ca peut être bien de se renseigner un minimum sur les traditions, les pratiques, les usages pour communiquer avec les gens. Ca évite de faire des trucs qui vont choquer les autochtones (du genre, manger avec sa main gauche en Inde)

  Vagabond, c'est un peu ma vie. Et je n'ai jamais eu le genre de problèmes dont tu parles.
  T'es humain, les gens que tu croises sont humains, tu t'arranges pour pas être un gros con avec ces autres humains, et ça va tout seul. Le reste, ben justement c'est un truc de guide touristique pour moi. Attention, je ne veux pas dire que c'est faux ou quoi. Je connais aussi beaucoup de ces coutumes et trucs culturels qui sont censés choquer dans beaucoup de pays, parce que je suis pas totalement autiste et que je discute avec les gens justement. Ce que je dis, c'est que les relations humaines, en vrai, ça ne se passe pas comme ce genre de livre aimerait faire croire. Tout dans de jolies petites cases bien binaires ("tel pays, c'est comme ça que ça se passe"). Et c'est ainsi qu'après tu rencontres des voyageurs qui te sortent de grandes vérités générales sur un pays, ce qui pour moi est exaspérant.

• [^] # Re: Vitrines à pubs

  Posté par Jehan (page perso) le 18/01/13 à 18:01. En réponse à la dépêche Wikivoyage lancé officiellement. Évalué à 2.

  

  Salut,

  en effet, je n'ai pas été très diplomatique. Désolé. C'est parce que j'ai jamais aimé les guides, alors j'ai un peu réagi sur un coup de sang. J'aurai dû faire comme d'habitude, tourner sept fois mes doigts dans mes mains (ou un truc comme ça) et ne pas faire de message, comme je fais d'habitude. :-)

  Mais je n'ai en fait rien contre les gens qui utilisent les guides. Chacun fait comme il veut.

• [^] # Re: Vitrines à pubs

  Posté par Jehan (page perso) le 18/01/13 à 14:00. En réponse à la dépêche Wikivoyage lancé officiellement. Évalué à 7.

  

  Avec la Wikimedia qui est derrière, cela sera sans doute mieux. Mais je doute que cela éliminera totalement ce problème car c'est l'un des problèmes propres au concept de guide touristique selon moi. Et cela parce que je pense que c'est aussi ce que cherchent beaucoup de "touristes" justement.

  Je n'ai jamais acheté de guide touristique de ma vie, mais j'en ai feuilleté plusieurs et j'y ai toujours vu ce genre de contenu inintéressant ou pub cachée. Quand je vagabonde dans les pays, en fait, j'y vais toujours sans me renseigner, sans jamais rien chercher avant à son sujet. En plus comme je suis un gros ignare en géographie, en sciences politique, en histoire, etc., il m'est même arrivé d'arriver à une frontière de pays sans vraiment savoir le nom du pays ou sa capitale. Je trouve cela bien plus marrant comme ça. Quant aux restaus, ou autre, je suis toujours bien plus attiré par le petit bouiboui qui a l'air de rien et qui ne finira jamais dans un guide que par le restau à l'occidental sans intérêt que les gens recherchent (j'ai ce souvenir particulier d'avoir suivi un voyageur au Kazakhstan qui nous a mené dans un restau qui vendait des pizzas américaines chères et pas bonne! Et ce, juste parce que son guide le conseillait). Et de manière générale, j'aime que mes choix soient dictés par le hasard.

  Mais la plupart des voyageurs veulent au contraire tout prévoir, savoir déjà leur planning, ce qu'ils vont visiter, là où ils mangeront et dormiront. Donc c'est ce que fournissent les guides touristiques (offre et demande).
  Et cela amène soit les commerces à se faire leur pub cachée, soit à des contributeurs qui font une pub totalement ridicule sans s'en rendre compte.
  En effet j'ai souvent vu des boutiques, restaurants ou hôtels qui sont dans tel ou tel guide connu (Michelin, Routard, Lonely Planet, etc.) alors que franchement j'y ai rien vu de spécial. Mais souvent c'est un touriste quelconque qui est allé sur la place, a trouvé le repas bon ou le lit confortable (alors même que le restau ou hôtel voisin est tout aussi bon pour le même prix, sans pour autant que ni l'un ni l'autre ne mérite plus de louange que cela) et a fait une contribution au guide. Au final cela n'est qu'une démonstration de plus du fait que les hommes ont une vue restreinte du monde et un guide touristique n'est rien d'autre qu'une des nombreuses œillères que les hommes s'auto-imposent. Ils vont là où les autres vont plutôt que risquer de se planter.

  Donc bon wikivoyage est probablement une initiative sympa, mais je doute que cela apportera grand chose de toutes façons et que ça rendra le contenu intéressant, parce que selon moi le concept même de guide touristique est "défectueux" de base.

• [^] # Re: Utiliser Ibus pour switcher temporairement à bépo?

  Posté par Jehan (page perso) le 25/12/12 à 17:22. En réponse au journal Chinoiseries dactylographiques. Évalué à 1.

  

  Salut,

  merci pour la réponse. Donc c'était bien de cela qu'il s'agissait. Comme le ticket semble mélanger les 2 problèmes, je ne savais plus quand ça parlait de quoi.
  Quoiqu'il en soit, je n'ai pas un tel fichier simple.xml dans ma version d'ibus packagée par ma distrib. Je vois que c'est présent dans la dernière version cependant. Je vais voir si ça vaut le coup d'installer cette version alors (surtout que le blem que tu cites a l'air plutõt chiant aussi).

  Peut-être que je vais essayer fcitx aussi (apparemment ils ont aussi un gros panel de langages).

  Merci.