Journal Write once, run anywhere qu'il disait

35
3
déc.
2012

Sommaire

Bonjour Nal,

Ces derniers jours, j'ai travaillé sur le packaging de Newton Adventure et ce n'est pas de tout repos !

Voici un résumé de mes recherches sur le sujet.

Du simple zip…

Jusqu'ici je distribuais une simple archive au format zip contenant l'exécutable java du projet, càd un fichier jar, ainsi que les bibliothèques dont il dépend : certaines sont aussi écrites en java, ce sont donc aussi des jars, d'autres sont des bibliothèques natives destinées à accéder au matériel graphique via OpenGL ou sonore via OpenAL.

La production d'un jar exécutable est difficile, mais pas insurmontable :
il faut indiquer à Java où sont les bibliothèques. Pour les jars, il faut jouer avec maven, le programme utilisé pour compiler le projet, tandis que du code spécifique doit être écrit pour trouver les bibliothèques natives.

Toutefois ce mode de distribution pose plusieurs problèmes :

  • beaucoup d'utilisateurs ne savent pas décompresser une archive.
  • aucun raccourci dans le menu de l'environnement de bureau n'est créé automatiquement et avec certain (Unity par exemple), c'est très difficile de le faire à la main.
  • sur la plupart des PC, lorsque l'utilisateur double clique sur un jar, cela ouvre un gestionnaire d'archive au lieu d'exécuter le programme.

Sur ce dernier point, les environnements de bureau sont les grands coupables de ce comportement simple, mais stupide : combien d'utilisateurs veulent par défaut voir les entrailles d'un programme java plutôt que de l'exécuter ? C'est aussi idiot que d'ouvrir par défaut les exécutables avec un éditeur hexadécimal.

Changer les associations de fichier étant souvent très compliqué, je distribue des batchs pour aider l'utilisateur à lancer le programme, mais là aussi les fichiers batchs s'ouvrent souvent avec un éditeur de texte sur la plupart des machines. Avec Windows, c'est le top : la commande java est souvent inaccessible, l'exécution d'un batch provoque parfois des popups d'alertes…

… au paquet d'installation

Pour simplifier la vie des utilisateurs, j'ai décidé de créer des paquets pour les différents OS.

Debian

J'ai commencé par debian, puisque l'OS que j'utilise est basé dessus.
Les dépendances que j'utilise (lwjgl, phys2d, twl…) n'étant pas dans les paquets de cette distribution, j'ai fait un "gros deb", càd en embarquant toutes mes dépendances. Généré via maven par l'excellent plugin jdeb, ce paquet pourra servir de base de travail à de vrais empaqueteurs debian. J'ai découvert à cette occasion que la création de deb est un art difficile et je comprends mieux le manque de paquets à jour le travail titanesque que font les contributeurs debian.

Les autres

Pour les autres OS, j'ai fait appel à izpack, un logiciel qui crée des installeurs clickodromes multiplateformes. Un peu difficile d'accès, mais disposant d'un plugin maven, il me permet de créer facilement des installations de qualité (sauf pour Macosx, où ce n'est pas aussi bien qu'un .app).

Écrit en java, izpack génère un jar exécutable, il y a donc toujours le défaut des environnements de bureau décrit au début. Pour Windows, j'ai pu venir à bout de ce problème à l'aide d'un autre logiciel / plugin maven, launch4j qui transforme un jar en exe.

Et Java Web Start ?

Java Web Start est une technologie qui permet en cliquant sur un lien d'installer ou mettre à jour automatiquement une application Java et de créer un raccourci sur toutes les plateformes où tourne Java. Génial en apparence, elle a de gros défauts : une fois encore, l'association entre l'extension (jnlp) et le programme javaws n'est pas effective sur beaucoup de PC et l'utilisation de bibliothèques natives provoque l'affichage de popups d'alerte à faire fuir le plus intrépide des utilisateurs.

Conclusion

Le packaging d'applications multiplateformes, est une tâche complexe, mais indispensable pour toucher un large public. La charge est importante pour les développeurs de logiciel et c'est autant de temps perdu pour la correction de bug ou l'ajout de fonctionnalités.

J'espère qu'à l'avenir les environnements de bureau travailleront le support des programmes créés avec des outils de développement portables, car Java n'est pas le seul touché, afin de faciliter la vie des utilisateurs et des développeurs.

Mais… et Newton Adventure ?

Je donnerai bientôt des nouvelles de ce petit projet qui a bien grandi et qui, dans l'esprit des indies bundles sera peut être bientôt disponible sur des markets proprios, sous une licence privatrice
avec de bons gros morceaux de DRM dedans afin de plaire à un maximum de joueurs passionnés.

  • # Les retours de chariot à la main c'est mal

    Posté par  . Évalué à 7.

    Pense à configurer correctement ton éditeur pour qu'il ne fasse pas de retour de chariot tous les X caractères pour que la mise en page soit laissée à la feuille de style.
    Les gens avec des petits écrans auront un truc du genre :

    Jusqu'ici je distribuais une simple archive
    au format zip contenant
    l'exécutable java du projet, cad un fichier jar,
    ainsi que les
    bibliothèques dont il dépend: certaines sont
    aussi écrites en java, ce
    sont donc aussi des jars, d'autres sont des
    bibliothèques natives
    destinées à accéder au matériel graphique via
    OpenGL ou sonore via

    • [^] # Re: Les retours de chariot à la main c'est mal

      Posté par  (site web personnel) . Évalué à 2.

      Je suis allé un peu vite avec pandoc que j'utilise pour convertir entre les 50 syntaxes wikis que propose les sites. Ce serait plus simple si on avait droit au html…

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Les retours de chariot à la main c'est mal

      Posté par  . Évalué à 10.

      Le problème c'est surtout que LinuxFR ne respecte pas la spécification du format Markdown, qui précise bien qu'on peut mettre des retours à la ligne où on veut sans que ça ne change rien (comme en LaTeX par exemple), et que seul le double saut à la ligne crée un nouveau paragraphe (et il y a une syntaxe pour revenir à la ligne : mettre deux espaces avant le saut).

      Pour faire plus WYSIWYG, LinuxFR transforme tous les sauts à la ligne textuels en <br/>, et les outils qui pondent du Markdown—ou les utilisateurs qui écrivent du markdown—sont dans les choux.

      • [^] # Re: Les retours de chariot à la main c'est mal

        Posté par  . Évalué à 5.

        Moi je suis particulièrement ennuyé par le gras en milieu de m**o**t qui ne passe pas (ça marchait avant), je ne trouve pas l'entrée de suivi correspondante, ça m'étonne depuis le temps.

      • [^] # Re: Les retours de chariot à la main c'est mal

        Posté par  (site web personnel) . Évalué à -2. Dernière modification le 04 décembre 2012 à 15:37.

        LinuxFR transforme tous les sauts à la ligne textuels en

        Et je l'en remercie.

        et les outils qui pondent du Markdown—ou les utilisateurs qui écrivent du markdown—sont dans les choux.

        Ne devraient-ils pas couvrir d'insultes l'auteur de Markdown? Parce que bon, faut le faire, si c'est pour souffrir comme en HTML, autant faire de l'HTML non? L’intérêt d'un "langage" non HTML est justement d'est plus proche de l'écriture "naturelle", et ne pas respecter les sauts à la ligne est fort, très fort…

        Et sinon, c'est quoi l’intérêt des "outils qui pondent du Markdown" de balancer des retours chariots comme ça pour le plaisir? Ils ne sont pas obligés non plus! Bref, de mon point de vue c'est surtout les outils (et le "langage") qui foutent surtout le bordel.

        PS : j'en profite pour m'excuser auprès de l'auteur du journal, j'étais persuadé qu'il l'avait fait exprès n'imaginant pas un seul instant qu'un logiciel puisse formater de cette façon, et j'en croise qui militent pour cette limite à 80 caractère pour "raisons historiques" et que'il parait que c'est plus mieux bien pour la lecture (ce que je n'arrive pas à comprendre, est-ce que les gens écrive sur un quart d'une page pour dire de? le HTML c'est bien il permet de s'adapter à la largeur choisie par l'utilisateur!).

        • [^] # Re: Les retours de chariot à la main c'est mal

          Posté par  . Évalué à 6.

          il parait que c'est plus mieux bien pour la lecture

          C'est en tout cas le consensus dans l'édition de journaux, c'est rare de voir des magazines où le texte prend toute la largeur de la page, au profit de colonnes qui permettent d'être lues en déplaçant un minimum le regard. C'est peut-être pas une solution qui convient à tout le monde mais peut-être que les typographes ont réfléchi avant de faire ce choix et estiment que ça conviendra à une bonne partie de la population.

          • [^] # Re: Les retours de chariot à la main c'est mal

            Posté par  (site web personnel) . Évalué à 1. Dernière modification le 04 décembre 2012 à 15:52.

            Comme je disais juste avant, l'avantage de nos jours est qu'on s'occupe du contenu, le terminal peut s'occuper de la mise en page… C'est beau le HTML (et ePub maintenant, pour remplacer le PDF qui force la largeur aussi et est du coup une horreur sur liseuse)! ;-)
            La technologie change, on peut aussi re-réfléchir pour savoir si c'est toujours utile alors que la décision avait été faite avec d'autres critères (limitations technologiques) plutôt que d'appliquer bêtement les mêmes limites quand on change de support.

            • [^] # Re: Les retours de chariot à la main c'est mal

              Posté par  . Évalué à 7.

              Justement le fait de ne pas donner de sens au retour à la ligne seul (en ne faisant pas forcément un saut à la ligne dans le rendu) permet de laisser l'auteur choisir la façon dont il formate son texte (éventuellement avec une configuration que tu trouves rétrograde de limiter les lignes à 80 colonnes—si ça lui fait plaisir) indépendamment de la façon dont c'est rendu à l'utilisateur (en HTML configurable comme tu dis).

              C'est assez utile, par exemple je connais des gens qui écrivent du LaTeX en mettant un retour à la ligne à la fin de chaque phrase. Ça permet de mieux découper le propos dans une démonstration de maths, tout en étant un no-op du point de vue du rendu final.

              L'utilité pour les commentaires se discute (même si personnellement j'aime les commentaires construits et je trouve qu'on devrait les traiter avec la même syntaxe que tout le reste), mais le comportement non-standard de LinuxFR est surtout chiant pour les dépêches et les journaux, je trouve.

          • [^] # Re: Les retours de chariot à la main c'est mal

            Posté par  (site web personnel) . Évalué à 2.

            Oui, c'est mieux de limiter la largeur et c'est tout l'intérêt des colonnes d'un journal.
            Mais comme le dit Zenitram il appartient au logiciel / à la css de gérer cette affaire et non au texte initial (c'est ce qui est fait avec ma css linuxfr-solarized par exemple)

            Je crois que la largeur classique communément admise est en gros autour de 60-70 signes par ligne.

        • [^] # Re: Les retours de chariot à la main c'est mal

          Posté par  . Évalué à 2.

          Ne devraient-ils pas couvrir d'insultes l'auteur de Markdown?

          Si. En plus, c'est un Apple Fanboy.

        • [^] # Re: Les retours de chariot à la main c'est mal

          Posté par  (site web personnel) . Évalué à 5.

          j'en croise qui militent pour cette limite à 80 caractère pour "raisons historiques" et que'il parait que c'est plus mieux bien pour la lecture (ce que je n'arrive pas à comprendre, est-ce que les gens écrive sur un quart d'une page pour dire de? le HTML c'est bien il permet de s'adapter à la largeur choisie par l'utilisateur!).

          Il est admis que le champ visuel du lecteur couvre entre 60 et 70 caractères pour les tailles courantes de police. Cela permet au lecteur de prédire la suite de la ligne avant de la lire effectivement, ce qui allège la lecture attentive, et permet le survol lorsque le lecteur le désire.

          En outre, cela permet au lecteur de ne pas perdre le début de la ligne lorsqu'il arrive à sa fin, de sorte que le passage à la ligne suivante est plus fluide. Les typographes corrigent le problème causé par les longues lignes en augmentant l'espace interligne.

        • [^] # Re: Les retours de chariot à la main c'est mal

          Posté par  . Évalué à 2.

          Ne devraient-ils pas couvrir d'insultes l'auteur de Markdown? Parce que bon, faut le faire, si c'est pour souffrir comme en HTML, autant faire de l'HTML non? L’intérêt d'un "langage" non HTML est justement d'est plus proche de l'écriture "naturelle", et ne pas respecter les sauts à la ligne est fort, très fort…

          Si tu t'exprimes ainsi, c'est que tu n'as pas compris l'intérêt de Pandoc: il permet précisément de s'affranchir des sauts à la ligne.

          Si tu aimes travailler avec un éditeur doté d'une grande police d'affichage (bon, d'accord, tu n'as peut-être pas encore 50 ans…), tes lignes feront sans doute 80 caractères ou à peu près, alors que ton format d'export - disons un PDF via latex - en comprendra beaucoup plus en 11pt.

          Tu ne dois pas t'en préoccuper, puisque Pandoc éliminera les sauts à la ligne, sauf si, volontairement tu laisses deux espaces en fin de ligne, ou si tu insère une ligne vide.

      • [^] # Re: Les retours de chariot à la main c'est mal

        Posté par  (site web personnel) . Évalué à 4.

        Initialement (entendre lors du passage à Rails) ce n'était pas le cas.
        Le problème est que tout le monde n'est pas, loin de là, habitué au markdown et beaucoup se sont fait avoir par cette façon d'écrire.

        En ce sens la modification apportée permet d'écrire du texte sans se soucier de markdown, en sautant une ligne lorsqu'on veut changer de paragraphe. Et pour linuxfr je trouve ça plus pratique, on est plus sur du commentaire et donc du texte pu que sur du markdown comme on peut l'utiliser pour rédiger des contenus plus importants/imposants, des documentations, etc.

        http://linuxfr.org/news/architecture-logicielle-de-la-nouvelle-version-de-linuxfrorg
        http://linuxfr.org/suivi/retour-%C3%A0-la-ligne-ne-fonctionne-plus

  • # Bienvenue et évolution technologique

    Posté par  (site web personnel) . Évalué à -10. Dernière modification le 03 décembre 2012 à 17:03.

    La charge est importante pour les développeurs de logiciel et c'est autant de temps perdu pour la correction de bug ou l'ajout de fonctionnalités.

    Bienvenue sous Linux ;-).

    J'espère qu'à l'avenir les environnements de bureau travailleront le support des programmes créés avec des outils de développement portables, car Java n'est pas le seul touché, afin de faciliter la vie des utilisateurs et des développeurs.

    Dans tes rêves, la seule réponse que tu peux avoir c'est que leur façon de faire est parfaite et qu'il n'est pas question de discuter de se mettre autour d'une table pour faire quelque chose de commun. Ils aiment emmerder les développeurs et en son fiers!


    bon, c'était pas juste pour un unique troll, mais pour une difficulté de lecture : la technologie a aussi évolué depuis 1990, et de nos jours les écrans ne font plus du tout 80 colonnes de large :

    Ces derniers jours, j'ai travaillé sur le packaging de Newton
    Adventure et ce n'est pas de tout repos!

    Peu se mettre en :

    Ces derniers jours, j'ai travaillé sur le packaging de Newton Adventure et ce n'est pas de tout repos!

    le HTML est la pour s'adapter à l'écran, pourquoi donc imposer une largeur d'écran (20% de la largeur de mon écran, c'est pas beaucoup)?

    • [^] # Re: Bienvenue et évolution technologique

      Posté par  (site web personnel) . Évalué à 3.

      Malheureusement, il n'est pas possible d'éditer un journal…

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Bienvenue et évolution technologique

      Posté par  . Évalué à 4.

      La charge est importante pour les développeurs de logiciel et c'est autant de temps >>perdu pour la correction de bug ou l'ajout de fonctionnalités.

      Bienvenue sous Linux ;-).

      Le même package fonctionne sur mac et windows ?

      • [^] # Re: Bienvenue et évolution technologique

        Posté par  (site web personnel) . Évalué à 8.

        Windows et Macosx sont les OS qui me donnent le plus de mal.

        D'après les premiers retours, l'installeur izpack en jar exécutable fonctionne bien sur plusieurs variantes de debian et fedora.

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Bienvenue et évolution technologique

      Posté par  . Évalué à 1.

      Quel logiciel utilises-tu pour développer le jeu ? Game Develop ? Unity ?…

    • [^] # Re: Bienvenue et évolution technologique

      Posté par  . Évalué à -2.

      A part le fait qu'il radote, y a une raison … objective de le sabrer comme ca?

      il a quand même pas tort n'en déplaise à certains.

      Entre ceusse qui considerent qu'un exe qui ramène ses dépendances c'est la porte ouverte aux virus mais qui pleurent quand ff met 3 ans a sortir dans leur distrib,
      ceusse qui se plaignent que tous les langages qui ont leur propre système de dépendances au lieu d'utiliser celui de leur distrib mais ne sont pas choqués que chacune d'elle ait le sien incompatible avec les autres,
      ceusse qui pleurent parce que y a jamais de choix sur leur distrib utilisée par 3 pequins
      et qui bavent sur les exe linkés en statique
      ceussent qui voudraient pouvoir recompiler fesse de bouc a chaque changement de skin

      ….. Meeeerde, vla que je dois plusser Zenitram.
      Faites cric là.

      • [^] # Re: Bienvenue et évolution technologique

        Posté par  . Évalué à 6.

        A part le fait qu'il radote, y a une raison … objective de le sabrer comme ca?

        Euh…

        Dans tes rêves, la seule réponse que tu peux avoir c'est que leur façon de faire est parfaite et qu'il n'est pas question de discuter de se mettre autour d'une table pour faire quelque chose de commun. Ils aiment emmerder les développeurs et en son fiers!

        Tu vois pas de problème dans cette phrase ? Genre, un ton qu'il adopte trop souvent et qu'on lui reproche depuis longtemps, ce mélange de mépris, d'insulte mal déguisée, de je-fais-dire-aux-gens-ce-qu-ils-n-ont-jamais-dit-mais-c-est-pas-grave-parce-que-ca-me-sert, bref en un mot : de la zenitramerie ?

        • [^] # Re: Bienvenue et évolution technologique

          Posté par  . Évalué à 1.

          Si et je ne suis pas le dernier à lui rappeler.
          Mais ça n'empêche pas de répondre sur le fond.

          A moins , à moins … qu'il n'ait raison sur le fond

      • [^] # Re: Bienvenue et évolution technologique

        Posté par  (site web personnel) . Évalué à 10.

        Bah s'il avait lu le journal, il aurait vu que ce n'est pas Linux le problème, puisque l'auteur galère aussi sous Windows.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 1.

          Ce commentaire a été supprimé par l’équipe de modération.

  • # Pour le lancement du jar

    Posté par  (site web personnel) . Évalué à 2.

    Je vais sûrement écrire une bêtise, mais pour le lancement du jar : mettre un script dans le path utilisateur qui lancerait le jeu avec :

    java -jar le_binaire.jar

    ça le ferait pas?

    • [^] # Re: Pour le lancement du jar

      Posté par  (site web personnel) . Évalué à 7.

      C'est effectivement ce qui est fait pour beaucoup de logiciels en Java il me semblent. En revanche, question d'efficacité en mémoire :

      exec java -jar le_binaire.jar
      
      
      • [^] # Re: Pour le lancement du jar

        Posté par  (site web personnel) . Évalué à 9.

        Quelqu'un pourrait-t-il combler mes lacunes (je ne trouve pas la réponse trivialement) : pourquoi lancer avec exec augmente l'efficacité en mémoire et : c'est quoi augmenter l'efficacité en mémoire?
        Merci d'avance !

        • [^] # Re: Pour le lancement du jar

          Posté par  . Évalué à 10.

          pour faire simple

          • java -jar bidule.jar => 2 processus, le shell interpréteur (bash ou sh), et java
          • exec java -jar bidule.jar => 1 processus, exec permet de remplacer le processus courant par la commande passé en paramètre.

          Cela permet d'avoir un processus en moins, et dans le cas d'un bash ou zsh, c'est pas forcément négligeable.

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: Pour le lancement du jar

            Posté par  (site web personnel) . Évalué à 10.

            est-ce que ça change réellement quelque chose ? je veux dire on ne serait pas dans de la micro optimisation qui ne change rien en réalité ?

            • [^] # Re: Pour le lancement du jar

              Posté par  . Évalué à 6.

              Tu sembles avoir oublié que tu es sur Linuxfr. Le milieu naturel de cet animal ainsi que de celui-ci.

              Depending on the time of day, the French go either way.

              • [^] # Re: Pour le lancement du jar

                Posté par  (site web personnel, Mastodon) . Évalué à 6.

                C'est clair !! Moi, d'ailleurs, j'ai totalement arrêté de corriger les fuites mémoire, les fuites de ressources et autres futilités.
                Soyons clair, je coûte plus cher à l'heure qu'une barrette de RAM alors quand ça chie, hop, j'envoie une commande au service achat.

                • [^] # Re: Pour le lancement du jar

                  Posté par  . Évalué à 7.

                  Si tu ne vois pas la différence, entre pinailler pour économiser 300k de mémoire alors que l’on va exécuter un jeu en java, et corriger des fuites mémoires je ne peux rien pour toi.

                  Depending on the time of day, the French go either way.

            • [^] # Re: Pour le lancement du jar

              Posté par  . Évalué à 8. Dernière modification le 04 décembre 2012 à 08:54.

              est-ce que ça change réellement quelque chose ? je veux dire on ne serait pas dans de la micro optimisation qui ne change rien en réalité ?

              1890 user  20   0  109m 1304 1116 S  0.0  0.0   0:00.00 /bin/sh /home/user/Apps/pycharm-2.6.2/bin/pycharm.sh
              
              

              Non pas du tout. T'imagines 188Ko de RAM gaspillé ! Sachant que la JVM va prendre à la louche entre 64Mo et 2Go de RAM ca nous fait tout de même entre 0.2% et 0.009% d'overhead.

              Bon dans l'absolu il a raison, mais un exec ca empêche aussi faire des traitements après la terminaison de la VM. Des trucs jolis comme ca par exemple:

              # ---------------------------------------------------------------------
              # Run the IDE.
              # ---------------------------------------------------------------------
              while true ; do
                eval "$JDK/bin/java" $ALL_JVM_ARGS -Djb.restart.code=88 $MAIN_CLASS_NAME $*
                test $? -ne 88 && break
              done
              
              
            • [^] # Re: Pour le lancement du jar

              Posté par  . Évalué à 5.

              Ca peut aussi aider a traquer le pid si besoin est.

    • [^] # Re: Pour le lancement du jar

      Posté par  (site web personnel) . Évalué à 4.

      Les utilisateurs qui utilisent la ligne de commande n'ont généralement pas de problème à lancer un programme java.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Pour le lancement du jar

        Posté par  . Évalué à 8.

        Pour les autres, ajoute un fichier .desktop qui appelle cette commande :-)

        Un petit exemple :

        [Desktop Entry]
        Name=Newton Adventure
        Exec=java -jar binaire.jar
        Icon=image.png
        Type=Application
        
        

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Pour le lancement du jar

          Posté par  . Évalué à 4.

          Le problème c'est de créer le fichier et de le placer là où il faut. Pour ça il te faut un script, qui doit être exécutable.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Pour le lancement du jar

            Posté par  (site web personnel) . Évalué à 2.

            Normalement, où que soit le fichier .desktop, si tu double-cliques dessus, il est exécuté.

            • [^] # Re: Pour le lancement du jar

              Posté par  . Évalué à 2.

              Je ne savais pas qu'on pouvait mettre un .desktop n'importe où.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Pour le lancement du jar

              Posté par  (site web personnel) . Évalué à 5. Dernière modification le 05 décembre 2012 à 16:36.

              Pas seulement, il faut qu'il soit marqué comme exécutable aussi !
              D'ailleurs heureusement, parce que ça n'a pas toujours été le cas…

              Essayez : éditez un fichier .desktop que vous créez avec votre éditeur de texte favori

              vim chatonmignon.desktop
              
              

              mettez y ce texte :

              [Desktop Entry]
              Name=chatonmignon.odt
              Exec=/bin/sh -c "echo H4sIADNhv1AAA41W6c6j2BH9z1MQjZTuiftrNoPtZCYSO9hgjM2uSBH7vl+M8Y8oT5MHy5MEfz09me7Jj1zJ2K57bnHrVKlOIdM4IEHeIHFzh7sFZG0D//TT33hNgH6A3/70BodtlDfpn+EJJG/7lwXK664dABwF0wjlIK7hn+GPH9oh/ZwMcRzFYwna7vO5BXmShz7I22b88CPU+SB7ByIrEvkNEvkemTcgHhI/jP8vv1Aerjf+Gf7wOvEWxfe8ysfsA+QPg7+87B+gbPX45RfI65dXHF0X5Hfd3xu//vKabm7iaHUHclB9sVzjMR+B36z3yEc4mUC+bvxhhQRttLwj6KqCl3Ya4MAfY9gfYjiIq7ZJYdDC0/jvf/7rdb2VpBX84urzLR7H9dbMNH78EWpecaw7r400Bn9vgyIOwccXn5/gF1m/QJavp+WvtHx8t3+Cf+XpK/ILN8vHr4F9gtEVtdLzCX4P6xP8uvon+J2aT/CLltdOvTp4pRt6hUFt4bfolwKA/wqHmQ/aps7Tpm0+txGATH7kGEanWTqVafGIZSZPf7es18MwLVO/YUejdO+BLUy+7VUhoU+xiI2DZzDBqKYQJwf3xO1l6mG4cdfp6GPb7/SaYnCOv3kSfRXZnpwwqS2cM6g8vwPUPCbIBWf8gIgab5vqmdjurXgjXaCB5sx7EbjW9DzsBX8zAgwHDn8ydO1KapZOcotaYvVDEBhKMHGzZx78zRoobuBwrajoEiAFaeb+IJQM5O+8SLCi2F0WUzMQFMNTCVh8dbhipiHZ0dnqrs/MbYZL5dLdxtBC0dsN4rTLPc8m/FORmYbBLr2rszKEKLvAT0l5H0t46cvX/HKSt6MmADP068ELsWdhpVM+32/YXmMDIg0H96RlC8lfUHXs9kQvTM1EEUh4l6DwcGUfNcHcw0QEbK3ulNS+1dNc8miS8dsMOR2GCxISx+xhxtwxfG4FpN/UDw31D5ndcOdJcaQdd2AERoGYOS82s3mT9TWL3HZ9MPptVnmBpuU1w7Tb2IKuf5/gcf0wRYCTqGeTqNJkIDhhNrTgW0O9GtH+YRe6eZrD81zKnMWVZd/q5bG3g1vmTne/GY30gTM7daxtZSME9uV8xY9kqZbls7cE98BJOKRFiUQeyCEmFowvHp5Z427ZaSixAzK/9A+5fGrHTe3gZjTXFnl2tg+rKc6qSh3nk5+jNAs6IkL40XeOEAWqo1333sm+ucttLUtRtz2qT8PxfsKndBwE+yIq9xpNdDoYVOBElTuOyRRGQoGoLUOIrlH43WoLKcg83FFHtW/W1uccrnGuLj9qGPvYlo9NQ+mKvx3Vue/7GNhzh+jhoYwLXl+ehc2FW7m77bd0LgpHDbFlETo04DCp5smvxPHSHsCNPFXxSafwrCtRTxvrydxP+cnez+Swp5WOOrfy9kKgXFnt4zYun1dHVopuCdPqDhG2sY2c6dnPJnBBsuAcPoyiJxw4b4iO070S+zIulajlpWmrKbniL4i9Kfqj8rw9BSVKJ80I5XkbZA8H2nZZx4FY4lKpRbuoM5EiZs9nRlQZakr5AM0aitoQ54tF6qnjpYdidlWxHMsCNIA/sCS6S3QTVTobKyCDIRFX6Ubu2gF2Adtod9/hNwwd0pJkG2vJAIvd63E/ijc0HipC6qgpe/Bqe/JmMXYCpa7nekPolslj0P4JGIIJWV71PbLtOMGqlbuzr/1BPLGbUNE7aa9qRybEmSK7++5aaTtKi+n7QwnbIPJ6x7Q4oHQHQA1QvA9oL2eIwwORed+nTfV5joQlcfbYbDaHHeFdUHp3Ef224/cljd0m6npWa1Dm3ZlQa4zUCxEjL6hw600ojg5CLyaGJ+4fxnx9njoUG4DIy5WhXMyCUSSvMUPSrk7GDM43bzyEZYPXFsHWjHdKWBpbeFXBjwfUcCC+Lm12aj3fjNTNNeTk5eaDQDCb0+VRNyTHbawuuBFqclD5ad8t6pY8UZuF4GRV7zBHLrb9WM9IwoLzA4pZ1dv0Z5Tb8zV6vjBHer56aa9hJWthBYqeNG7KJU8q6glRBSLYt80TnRyOtbjb8kQHXFx2VKLlk4RcIK45RvdNxTJDF53w7hQyO/MhASJ4sOXN6LBipgaPVVyHHcgNFtt32kOSexA+SXBexJNDGO0hZA/PUTtX0OWOKquoSOy5xRLHLOiZpvF0bTFrf6Jn3aTfWxGTR67FgEvUoqnJ0DTLvXDcqxuJWBbUVe05ZxRSmmPpjbjxtClOZVh+91wEL9ytXXgvMI7cLkPVN3say6pUUJCTzwNqU3Rn2/RvPdUh5pYiRfWw0cDxDiD3+pTz3amdLR11l7JayqwFcTlowzhNvhNoYHBBPiZ1Rjz8VquapacifNtr1sbObijBic/LSMltfBye0IXf7OVRsjRJkDnVR4s0PUotxvqJUyZMSz4n+ehV0TXSprSUGkLmcIUw+q5V5JMbeLe7G+PyUWR0GT1ChtrzkayGU0kqD0Oz9xhPzr4EtmOU3iONa4tHumcn7Xko4pxeatLapfeAmxz5kiRHq40nsogbx3gkUgLJ5DVtOGUyNv1OIxqERLbTE9l7236DRuV11FWq8JBeJ3fGImGWNGD/TQz9S2Kc0V04NqSh1di8ksJ+yUwX2BYaO0zlOswciFXhOtcuwLf3qCZLpT5kIV491+95FZIywM/Yip+itXd4Toa+Zg2GznT6GzXyLzvmKmf0qkqXdH0w5vfy9GXxmGDxPLiZpKjgWAZ9rZF3uXrVli6b9DeDjOSfHQyTZ5Wmz62yulB+51TUmZf0Qd9o32+c0b86E9EDXtyYl67K6qtO1d85U+mX3q51ZpOdV1vPNe7FE71VgHl2Dfl/EvwNv98s7v56PxTYFfCcKxmK1urIFL9s6jRDcy/Zpi+0+275MvFVeTDEbbLO0zH89jYP6/Q5/G7mg/8Izdn78AuDeATwWwJ/+PyPqg3Lz99Df/jwFzhq4TjMWvitWSfu198mhob6dep3w+R/ANvPBkx8DAAA | base64 -d | gzip -d | sh"
              Icon=application-vnd.oasis.opendocument.text
              Type=Application
              
              

              marquez-le comme exécutable :

              chmod +x chatonmignon.desktop
              
              

              Vous verrez dans votre explorateur de fichier un fichier nommé "chatonmignon.odt" (oui, oui), avec l'icône que votre environnement de bureau met habituellement pour les fichiers odt (oui, oui).

              Si vous double cliquez sur le .desktop, libreoffice va effectivement s'ouvrir en affichant un document parlant de chaton, avec le dossier qui contient le .desktop comme dossier courant pour le fichier ouvert, et pourtant, pourtant, vous devriez avoir une notification dans un coin de l'écran ;).

              Note : je sais que Nautilus remplace tout de même le nom et l'icône s'il n y a pas la ligne "Type=Application" même quand le fichier n'est pas marqué comme exécutable, mais heureusement ne lit pas la ligne "Exec". Pour que la ligne "Exec" soit exécutée, il faut qu'il y ai la ligne "Type=Application" ET que le fichier soit marqué exécutable, ce qui n'a pas toujours été vrai ! :/

              ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: Pour le lancement du jar

            Posté par  . Évalué à 4.

            Euh je ne comprends pas bien le souci. Il suffit que le .desktop soit à côté du .jar et c'est bon, non ?

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Pour le lancement du jar

        Posté par  (site web personnel) . Évalué à 2.

        Ben l'idée c'est que le lancement d'un script en dehors d'une console est mieux intégré dans les distributions courantes que le lancement d'un jar (n'est-il pas?). On parle juste d'une indirection qui permet de ne pas taper de ligne de commande (donc effectivement, faut peut être faire gaffe à la mémoire).

        • [^] # Re: Pour le lancement du jar

          Posté par  . Évalué à 3.

          Je me suis fait la même réflexion :

          1. Décompresser l'archive quelque part
          2. Pour Windows double-cliquer sur newton_adventure.bat, pour GNU/Linux double-cliquer sur newton_adventure.sh

          ?

          • [^] # Re: Pour le lancement du jar

            Posté par  (site web personnel) . Évalué à 2.

            Dans le public que je vise, les joueurs, tu as aussi bien des geeks que des gens qui ne savent pas ce qu'est un zip ou un bat.

            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

            • [^] # Re: Pour le lancement du jar

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              De toute façon les extensions ne s'affichent pas sous Windows.
              L'idée de l'exe qui lance le java -jar est bien pour une distribution pour Windows.
              Pour Linux, un .desktop qui contient le java -jar fichier.jar, puis le lien vers l'icône qui se trouve dans le même dossier et tu as un beau lanceur où y'a juste à double-cliquer dessus. L'exemple n'est ptre pas terrible au regard du libre, mais c'est ce que fait Skype, un Skype.dekstop et un Skype.png (je crois), référencé dans le Skype.desktop.

              De toute façon, ce sera empaqueté dans les distributions. À la limite si ton soucis c'est de pouvoir proposer des versions plus à jour, tu peux toujours t'arranger pour regarder dans un répertoire particulier si une nouvelle version n'est pas disponible, genre ~/.local/newtonadventure qui ne contiendrait que les jars mis à jour. Enfin j'imagine que tu fais tout ça parce que tu trouves que les distros mettent trop de temps à mettre à jour le paquet de Newton Adventure à ton goût, non ?

              • [^] # Re: Pour le lancement du jar

                Posté par  . Évalué à 2.

                +1 sauf pour :

                un Skype.dekstop et un Skype.png (je crois), référencé dans le Skype.desktop

                il doit y avoir une erreur.

                De toute façon les extensions ne s'affichent pas sous Windows.

                Par contre l'icône n'est pas la même me semble-t-il.

                Tu peux l'appeler StartNewtonAdventure.bat et les fichiers ZIP s'ouvrent de manière transparente dans l'explorateur de fichiers non ?

                Pour Windows un exe qui lance le java, et éventuellement lance l'installation de Java si celui-ci n'est pas installé…

                Et effectivement, pour du Michu compliant sous GNU/Linux je ne vois que la création d'un deb (et d'un rpm), avec le .desktop qui va bien pour que ça s'ajoute au menu.

              • [^] # Re: Pour le lancement du jar

                Posté par  (site web personnel) . Évalué à 3.

                Je ne savais pas qu'un .desktop "local" était possible, j'utiliserais ça à la place du script run_linux.sh dans prochaine version!

                J'ai commencé ce travail de packaging, car j'ai eu des retours d'utilisateurs qui n'arrivent pas à lancer le jeu. Pour une vraie intégration dans les distros, ça va être long, il faudrait qu'une version récente de lwjgl soit empaquetée d'abord.

                A ma connaissance, Arch Linux est la seule distribution à avoir un paquet.

                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                • [^] # Re: Pour le lancement du jar

                  Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 04 décembre 2012 à 13:54.

                  Ok. Ben je vais regarder pour faire un paquet pour Salix. J'aime bien ton jeu, il est sympa et original.
                  Pour lwjgl, c'est compliqué à empaqueter ? Bah, je vais regarder le PKGBUILD de Arch, comme je fais souvent :) Ils m'aident beaucoup à faire des paquets, et vu que les SLKBUILD sont similaires (et inspirés) des PKGBUILD, c'est assez facile en général de faire un paquet Salix à partir d'un paquet Arch.

                • [^] # Re: Pour le lancement du jar

                  Posté par  . Évalué à 3.

                  Je ne savais pas qu'un .desktop "local" était possible, j'utiliserais ça à la place du script run_linux.sh dans prochaine version!

                  Un truc à savoir à l'avance est que, sous certain DE au moins, le .desktop doit être exécutable pour être lancé depuis n'importe où.

          • [^] # Re: Pour le lancement du jar

            Posté par  (site web personnel) . Évalué à 2.

            Je ne sais pas si c'est le comportement par défaut, mais chez moi quand je clique sur un .sh, nautilus me dit que j'essaie d'ouvrir un fichier texte exécutable et me demande ce que je veux faire avec une fenêtre de ce type :

             _________________________________________________________
            |___________________________________________________/_/_/_|
            |                                                         |
            | Voulez-vous lancer « fichier.sh »                       |
            | ou afficher son contenu ?                               |
            |                                                         |
            | « fichier.sh » est un fichier texte exécutable.         |
            |                                                         |
            | [Lancer dans un terminal] [Afficher] [Annuler] [Lancer] |
            |_________________________________________________________|
            
            

            Tout sauf une question accessible à tout un chacun !

            ce commentaire est sous licence cc by 4 et précédentes

  • # Paquets Debian

    Posté par  (site web personnel) . Évalué à 9.

    Alors, faire des paquets Debian, fondamentalement, ce n'est pas difficile, un paquet binaire Debian est simplement une archive contenant deux archives : l'une avec les fichier à installer et l'autre avec les méta-informations (dépendances, description…) et les éventuels scripts supplémentaires pour l'installation et la désinstallation.

    En revanche, ce qui demande plus de savoir-faire, c'est de faire un paquet Debian propre, c'est à dire construit selon les conventions et les contraintes de qualité de Debian. Cela implique notamment : de le construire à partir d'un paquet source Debian, d'avoir une arborescence de paquet source qui respecte les conventions, d'utiliser les outils standards (et donc d'apprendre à s'en servir, comme Ant pour Java par exemple), de fournir des pages de manuel…

    Effectivement, ce genre de travail demande des compétences qui n'intéressent pas beaucoup les développeurs, d'où l'intérêt de trouver, idéalement, un mainteneur Debian pour s'occuper du paquet.

    • [^] # Re: Paquets Debian

      Posté par  . Évalué à 3.

      C'est précisément, ce qu'il dit. Lui il crée un paquet en mode goret pour se simplifier la vie, mais faire les choses bien (comme tu le dis plus empaquetage des dépendances) ça demande un travail conséquent.

      À la minidebconf10, il y avait une conférence sur l'intégration entra apt et maven ça pourrait être sympa de savoir ce qu'est devenu ce projet (il en était à ses balbutiements).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Paquets Debian

        Posté par  (site web personnel) . Évalué à 2.

        Pour simplifier la vie des joueurs. J'arrive à lancer facilement mon propre programme sans paquet :-)

        Je n'ai pas réussi à savoir comment faire un paquet source correct avec maven…

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Paquets Debian

          Posté par  . Évalué à 2.

          As-tu regardé du côté du plugin maven assembly ? il permet de créer des paquets source, binaire, whatever, comme tu le sens via un descripteur. Ça pourrait peut-être t'aider, je l'utilise personnellement pour faire mes paquets source.

    • [^] # Re: Paquets Debian

      Posté par  (site web personnel) . Évalué à 0.

      Effectivement, ce genre de travail demande des compétences qui n'intéressent pas beaucoup les développeurs, d'où l'intérêt de trouver, idéalement, un mainteneur Debian pour s'occuper du paquet.

      l'idéal aussi serait de concevoir un système pour lequel il serait simple de réaliser un paquet, qu'il soit binaire ou à partir des sources.

      Les PKGBUILD du défunt (dans mon coeur) Archlinux ou les pkgsrc me semblent plus faciles à appréhender que les paquets pour Debian.

      De manière idéale, ça serait pas mal aussi qu'il ne soit pas forcément nécessaire de refaire un paquet binaire tous les 8 mois parce que tout a été chamboulé lors de la dernière mise à niveau de la distribution.

      « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

      • [^] # Re: Paquets Debian

        Posté par  . Évalué à 3.

        l'idéal aussi serait de concevoir un système pour lequel il serait simple de réaliser un paquet, qu'il soit binaire ou à partir des sources.

        Les PKGBUILD du défunt (dans mon coeur) Archlinux ou les pkgsrc me semblent plus faciles à appréhender que les paquets pour Debian.

        Ce que tu demandes ça existe pour Debian et ça s'appelle checkinstall : ça crée un paquet debian à partir d'une compilation à la ./configure && make && make install. Pas de gestion de dépendances, mais tu as un paquet .deb.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Paquets Debian

          Posté par  (site web personnel) . Évalué à 1.

          oui je connais, mais ça ne fonctionne que s'il existe un makefile (c'est pratique quand même).

          Ça ne permet pas par exemple de créer un paquet depuis un logiciel en python, en java etc

          « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

          • [^] # Re: Paquets Debian

            Posté par  . Évalué à 3.

            Je pense que si, il fonctionne en créant une pseudo racine où il exécute le programme d'installation que tu lui fournis. Personnellement, je m'en sers comme ça :

            $ ./configure
            $ make
            $ checkinstall -y make install
            
            

            Donc à mon avis, il suffit que tu lui donnes un script qui copie les fichiers aux bons endroits et il devrait savoir se débrouiller.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Paquets Debian

              Posté par  (site web personnel) . Évalué à 1.

              oui sans doute, mais ça sera toujours considéré comme une méthode crade par les authentiques debianeux :)

              « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

              • [^] # Re: Paquets Debian

                Posté par  (site web personnel) . Évalué à 4.

                Désolé si je casse des rêves, mais une méthode automatique sera forcément considérée comme crade par d'authentiques debianeux, tout simplement parce que les critères de qualité de Debian impliquent un travail manuel, ne serait-ce que pour remplir des informations : une description du paquet, le détail des licences utilisées et les information d'attribution, ou encore le détail de l'origine et du but d'un patch s'il y en a besoin.

                En revanche, le gros du travail est automatisable dans la grande majorité des cas. Un logiciel bien fichu en amont, utilisant un système de construction à peu près standard, pourra être empaqueté assez facilement. Sous la forme d'un paquet basique, à affiner pour en faire quelque chose d'acceptable pour Debian.

                • [^] # Re: Paquets Debian

                  Posté par  (site web personnel) . Évalué à 3.

                  Maven c'est standard en Java, pourtant je n'ai pas l'impression que ce soit si facile de debianiser avec…

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                  • [^] # Re: Paquets Debian

                    Posté par  . Évalué à 0.

                    Maven n'est pas un système de build de programme, mais un système de build de distribution, avec un gestionnaire de paquet capable de télécharger automatiquement les dépendances.

                    Enfin bref, buildroot c'est standard, pourtant je n'ai pas l'impression que ce soit si facile de debianiser avec …

                    • [^] # Re: Paquets Debian

                      Posté par  (site web personnel) . Évalué à 4.

                      Maven n'est pas un système de build de programme, mais un système de build de distribution

                      ?

                      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                      • [^] # Re: Paquets Debian

                        Posté par  . Évalué à 1.

                        Oui, un système de build de distribution, comme buildroot, quoi. En plus de décrire comment builder, tu décris aussi tes dépendances selon un format normalisé et uniforme. Ça à un dépot de paquet disponibles et ça télécharge soit des dépendances toutes prêtes, soit elle te les compiles toutes. Et le tout forme une distribution de paquets java.

                        Et oui, c'est pas intégré ou compatible avec Debian, entre autres. Avoir deux systèmes de gestion de dépendance en concurrence, c'est jamais une bonne idée.

                  • [^] # Re: Paquets Debian

                    Posté par  . Évalué à 3.

                    J'avais essayé l'équivalent de dh_make avec maven pour faire un paquet newton adventure, ça avait l'air de bien marcher. Le problème c'est que toutes les dépendances ne sont pas dans Debian et n'utilisent pas maven.

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Paquets Debian

                  Posté par  (site web personnel) . Évalué à 7.

                  Désolé si je casse des rêves

                  non non, ça confirme juste un cauchemar, c'était vraiment trop difficile pour les distributions de s'entendre pour standardiser au moins ça, la description, l'icône, la licence, non, il suffit que des petites mains pour chaque distribution s'embêtent à aller récupérer toutes ces informations basiques dans le readme ou ailleurs, pour faire de nouvelles sources incompatibles avec les autres distributions. Quelle perte de temps !

                  « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

                  • [^] # Re: Paquets Debian

                    Posté par  . Évalué à 3.

                    Euh … Ya pas XML pour ça ? On pourrait inventer un format de description de paquet "générique" en XML, et un xslt qui transformerait celui-ci pour les diverses distributions.

                    Je ne suis pas fan de XML dans bien des cas, mais j'ai l'impression à vue de nez que dans ce cas ce serait bien pratique (et ça existe peut-être déjà).

                    • [^] # Re: Paquets Debian

                      Posté par  . Évalué à 4.

                      totof2000 qui se met à recommmander l'usage du XML. Une chose est sûre, la fin du monde approche.

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Paquets Debian

                Posté par  . Évalué à 2.

                Ah bien sûr, mais l'idée c'était surtout de créer un paquet rapidement et facilement.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Paquets Debian

            Posté par  (site web personnel) . Évalué à 1.

            Tu peux créer proprement un paquet Debian avec un projet Python (il faut « simplement » trouver le bon système de packaging), avec une commande du style ./setup.py bdist_stddeb (ou approchant). Et avec le même genre de commandes, tu peux faire en même temps un .tar.gz, un .rpm, un .exe, … Plutôt bien pensé sur ce point-là (mais les outils de paquetage Python ont d'autres soucis, malheureusement).

      • [^] # Re: Paquets Debian

        Posté par  . Évalué à 6. Dernière modification le 04 décembre 2012 à 20:02.

        Les PKGBUILD du défunt (dans mon coeur) Archlinux ou les pkgsrc me semblent plus faciles à appréhender que les paquets pour Debian.

        T'inquiètes, Lennart est en train de bosser dessus. Il planche sur un gestionnaire de paquet, parce que bon hein : "Utiliser bash en 2012 pour générer un paquet c'est trop merdique et trop compliqué".

        Si ce mec arrive un pondre un gestionnaire "One to rule them all", j'embauche les tontons flingeurs (Hans, John et Daniel) et je met un contrat sur sa tête !

        • [^] # Re: Paquets Debian

          Posté par  . Évalué à 1.

          En même temps je vois pas pourquoi chaque distribution à son gestionnaire de paquet. Et puis de toute façon il y a PackageKit, non? Oui je sais encore une couche d'abstraction… Mais comme personne n'est capable de se foutre d'accord, ça reste une bonne solution.

          Après, un gestionnaire de paquet qui s'impose un peu partout comme pour systemd ce serait pas du luxe, vu que grosso merdo il y a peu près toujours les mêmes trucs qui reviennent, avec la possibilité de rajouter des champs et des extensions pour en tirer partie (en gros: un format commun extensible, un gestionnaire de paquet commun extensible pour tirer partie du format précédent…)

          Ensuite faut arrêter la fixation sur Lennart et systemd. Perso PulseAudio ne fonctionne pas correctement chez moi, mais NetworkManager fonctionne sans soucis (mieux que wicd) et systemd fonctionne sans problème majeurs (en fait, seulement avec un seul petit problème chez moi).

          Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Paquets Debian

            Posté par  . Évalué à 3.

            Le problème du système de paquet, c'est loin d'être le format des paquets. Sinon, alien marcherait très bien (et il n'y aurait pas de problème). La preuve, c'est que des paquets RPM, à quelques exceptions près, ne fonctionne pas entre les différentes distributions qui utilisent ce format (en se restreignant aux paquets pour les lesquels les dépendances sont satisfaites des deux côtés). Le gros problème, ce sont les version des bibliothèques (qui ne sont pas toujours rétro/futuro-compatibles) et les options de compilations qui peut amener à utiliser des fichiers ou des bibliothèques non-présentes.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Paquets Debian

              Posté par  . Évalué à 1.

              M'enfin ça serait déjà un pas en avant (pas besoin d'apprendre à utiliser 3 000 outils pour faire 2 000 paquets différents pour chaque distro).

              Écrit en Bépo selon l’orthographe de 1990

  • # mon grain de sel

    Posté par  . Évalué à 2.

    Sur ce dernier point, les environnements de bureau sont les grands coupables de ce comportement simple, mais stupide : combien d'utilisateurs veulent par défaut voir les entrailles d'un programme java plutôt que de l'exécuter ? C'est aussi idiot que d'ouvrir par défaut les exécutables avec un éditeur hexadécimal.

    Ha c'est ce que ça me fait sous Windows et tous mes DE ;)
    En même temps d'un point de vu sécurité informatique, ne pas exécuter automatiquement un truc qu'on vient de télécharger c'est plutôt un bon point ;). Un jar, c'est quand même une Java ARchive, l'ouvrir avec un gestionnaire d'archive est ce qui est logique.

    Le fait que les gens utilisent ensuite un .jar en tant qu’exécutable, n'est de mon point de vue qu’anecdotique, certaines bibliothèque livrée en .jar ne sont pas standalone, et il n'y a aucune raison de vouloir les exécuter.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: mon grain de sel

      Posté par  . Évalué à 5.

      Un jar, c'est quand même une Java ARchive, l'ouvrir avec un gestionnaire d'archive est ce qui est logique.

      Oui bien sur. Et quand on te donne des .docx, .odt et tout leurs copains qui sont des zips tu veux aussi les ouvrir avec un gestionaire d'archive ?

      Le fait que les gens utilisent ensuite un .jar en tant qu’exécutable, n'est de mon point de vue qu’anecdotique, certaines bibliothèque livrée en .jar ne sont pas standalone, et il n'y a aucune raison de vouloir les exécuter.

      Le manifest t'indique si il y a une main-class ou non.

      • [^] # Re: mon grain de sel

        Posté par  . Évalué à 3.

        Et quand on te donne des .docx, .odt et tout leurs copains qui sont des zips tu veux aussi les ouvrir avec un gestionaire d'archive ?

        7zip a ce comportement, ca m'a surpris :)

        • [^] # Re: mon grain de sel

          Posté par  . Évalué à 2.

          C'est pas du à 7zip mais à ton gestionnaire de fichier, c'est lui qui fait l'association entre une extension (.odt) et un programme (7zip). 7zip à l'installation déclare juste qu'il est capable d'ouvrir des .odt. Peut être que sous windows c'est un peu différent avec des programmes d'installation qui forcent le nouveau logiciel à être le programme par défaut, mais en principe ça devrait être un système de priorité (7zip pour ouvrir des odt c'est pas le comportement le plus ergonomique) modifiable par l'utilisateur.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: mon grain de sel

            Posté par  . Évalué à 2.

            non, c'est bien 7zip qui possède un explorateur d'archive. j'étais en train de visualiser une archive zip, et voulais ouvrir l'odt à l'intérieur, et au lieu d'utiliser l'association windows, il a pris l'initiative d'ouvrir l'odt.

            7zip

            • [^] # Re: mon grain de sel

              Posté par  . Évalué à 2. Dernière modification le 04 décembre 2012 à 12:56.

              L'explorateur de Windows XP est également capable d'ouvrir les ZIP, je ne sais pas pour d'autres types d'archive. Par contre c'est clair que l'explorateur de fichier de 7-Zip poutre allègrement celui de Windows sur l'ouverture et l'affichage d'un dossier avec de nombreux fichiers ! Je suis sûr un poste Windows XP là présentement, j'ai au moins deux grosses applications métier en Java, de nombreuses autres applications diverses et variées, et bien le plus lent c'est tout ce qui est de chez Microsoft (Office, IE, l'explorateur de fichier) c'est quand même un comble…

              Bref, 7-Zip est souvent une excellente alternative à l'explorateur de fichiers de Windows XP ! J'ai hâte de tester sur Seven…

      • [^] # Re: mon grain de sel

        Posté par  . Évalué à 1.

        Dans Java ARchive, c'est archive que t'as pas compris? un doc, docx (tu remarquera l'utilisation de DOCument), et de Open Document Text, et ça t'ouvre le logiciel de traitement approprié au type de fichier, et fait toujours la même action.

        Pour ton jar, tu fais quoi si on double clique dessus et qu'il n'y a pas de main dedans? ou 3 main dedans? Rien? Tu ouvres le gestionnaire d'archive? Tu l'ajoutes dans le CLASSPATH? Tu regardes le manifest ?

        Bref les environnement de bureau tentent généralement d'avoir un comportement homogène, chose qu'on ne peut pas faire avec un .jar si on veut l'exécuter.

        Connais tu une seule extension qui selon le DE t'envoie soit l'éditeur soit exécute le fichier?

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: mon grain de sel

          Posté par  (site web personnel) . Évalué à 2.

          Un bon DE devrait juste lancer "java -jar lefichierdoublecliquai.jar".

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: mon grain de sel

            Posté par  . Évalué à 1.

            C'est marrant, j'étais persuadé que c'était ce que faisait le finder de macos.

            • [^] # Re: mon grain de sel

              Posté par  (site web personnel) . Évalué à 2.

              C'est ce que fait aussi un Windows après installation de Java, mais certains programmes volent cette association.

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: mon grain de sel

          Posté par  . Évalué à 4.

          Pour ton jar, tu fais quoi si on double clique dessus et qu'il n'y a pas de main dedans? ou 3 main dedans? Rien? Tu ouvres le gestionnaire d'archive? Tu l'ajoutes dans le CLASSPATH? Tu regardes le manifest ?

          Ton DE il fait quoi pour les binaires ? Il vérifie si c'est du COFF, de l'ELF ou autre ? Il te donne une quelconque garanti que le binaire est bien exécutable (dans le sens possède bien une fonction main et est au bon format) ? Quand tu double clique sur un .so il ouvre gdb, un éditeur hexadécimal ou un décompi(la ?)teur ? Quand il ouvre une image tu est sur que l'image n'est pas tronquée ?

          La question c'est qu'est ce qu'il est pertinent de faire avec un *.jar ? Le lancer comme tout les utilisateurs et les développeurs font ou l'ouvrir comme le font de temps en temps les développeurs à des fins de debug ?

          Bref les environnement de bureau tentent généralement d'avoir un comportement homogène, chose qu'on ne peut pas faire avec un .jar si on veut l'exécuter.

          C'est à dire ? C'est quoi un comportement homogène ? Lancer le jar conviens dans l'énorme majorité des cas qu'ils adoptent ce comportement au lieu d'ouvrir le jar et de laisser les utilisateurs au milieu de .class et .properties dont l'utilisateur se contrefiche.

          Connais tu une seule extension qui selon le DE t'envoie soit l'éditeur soit exécute le fichier ?

          J'ai vu Nautilus (il y a longtemps, je ne sais pas ce que fait File maintenant) qui vérifiaient si le fichier a les droit d'exécution et propose plusieurs choix avec possibilité d'enregistrer le choix.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: mon grain de sel

            Posté par  (site web personnel) . Évalué à 4.

            J'ai vu Nautilus (il y a longtemps, je ne sais pas ce que fait File maintenant) qui vérifiaient si le fichier a les droit d'exécution et propose plusieurs choix avec possibilité d'enregistrer le choix.

            En tout cas sous Gnome 3.4 c'est toujours le cas (et je doute qu'il veuille le retirer prochainement sinon ça serait déjà fait).

            Le truc est de se dire, l'utilisateur qui est capable de savoir de quoi est fait un jar, il peut l'ouvrir à la main s'il veut l'éditer alors que l'utilisateur qui veut uniquement l'utiliser ne sait pas comment faire pour l’exécuter si seulement on lui propose d'ouvrir le contenu. Du coup il est plus pertinent de faire chier le développeur qui est théoriquement capable de régler son inconfort seul là où l'inverse est bien plus délicat étant donné les connaissances informatiques de l'utilisateur moyen.

        • [^] # Re: mon grain de sel

          Posté par  . Évalué à 6.

          Dans Java ARchive, c'est archive que t'as pas compris?

          J'ose penser que je comprends à peut prêt la signification de Java ARchive. J'irai même jusqu'à penser que je sais même exactement comment ca marche, sa spécification et les problèmes qui existe.

          ou 3 main dedans?

          Je pense que tu peux relire la spécification

          Connais tu une seule extension qui selon le DE t'envoie soit l'éditeur soit exécute le fichier?

          Nautilus par exemple ? Un .sh qui n'a pas de bit exécutable est ouvert dans un éditeur de texte. Si le bit exécutable est présent un pop-up te propose ce que tu veux faire. C'est aussi vrai pour les .py

          Pour un JAR ca peut être exactement la même chose. Exécuter un script python qui n'a pas de main n'a pas plus de sens que lancer un JAR qui n'a pas de Main-Class spécifiée.
          Maintenant le problème des JAR est double. D'une part il ne rentre pas du tout dans le mécanisme de loader d'UNIX, tel qu'implémenté actuellement. Son côté dynamique étant limité au shebang. Si ton format de fichier ne permet pas le shebang (fichier binaire), alors le travail doit être fait par l'userland (donc le DE) plutôt par le noyau dans l'execve. On pourrait étendre le mécanisme de binfmt soit en rajoutant explicitement le support pour un magic number donné, soit un branchant un mécanisme extensible (voir binfmt_misc par exemple). Le deuxième problème du JAR est que son type n'est pas identifiable par un magic number, il l'est uniquement par son extension et la présence d'un fichier Manifest.

          Tu noteras aussi que dans mes autres commentaire que j'indique que lancer un simple java -jar archive ne résout pas tout les problèmes. Pour un jeu ca peut le faire (et encore ca veut dire que tu n'es pas pleinement standalone puisque tu supposes que le client à un JRE en bonne version d'installé), mais pour la plupart des applis il faut de toute façon un lanceur pour gérer l'intégration. Maintenant je dis juste que je trouve profondément stupide l'argumentation utilisant le fait que le nom d'un format contienne "archive".

    • [^] # Re: mon grain de sel

      Posté par  . Évalué à 5.

      En lisant ton commentaitre, je me dis qu'il manque (ou n'est pas utilisé) une extension qui représente un executable java ?

      • [^] # Re: mon grain de sel

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 03 décembre 2012 à 18:15.

        Ca changerait quoi? Pour python, l'extension *.py désigne un script et souvent le double clic ouvre un éditeur de texte.

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: mon grain de sel

          Posté par  (site web personnel) . Évalué à 5.

          Ça changerait que tu pourrais, dans ton projet, avoir un fichier .rjar (run jar) associé automatiquement au lancement via la jvm java et non comme une archive a ouvrir, et un .rpy (run python) associé automatiquement au lancement via l'exécutable Python et non comme un fichier texte a éditer.

          (modulo que .rjar ou .rpy ne soient pas déjà utilisés par ailleurs)

          Ceci dit, sous Unix, un fichier truc sans extension mais exécutable et avec le shebang ad-hoc, ça marche bien.

          Bon, ça ouvrirais aussi la porte à d'autres véroles sous Windows…

          Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

          • [^] # Re: mon grain de sel

            Posté par  . Évalué à 1.

            Le problème c'est que tu as souvent besoin de plus d'info pour pouvoir t'exécuter. C'est un problème général dans la livraison de logiciel. Soit tu créer un environnement clos pour une cible données qui embarque toutes les dépendances et toute la config et qui ne s'intègre absolument pas au système. Soit essaie de t'intégrer à la cible et ton programme à besoin d'information de configuration.

            Regardes à quoi servent les scripts bash pour lancer du Java ou du Python et tu verras qu'il y a beaucoup plus qu'un exec.

            Quelque soit l'option que tu choisis ca demande du travail. Quelques soit la plateforme que tu utilises je n'en connais aucune qui résoudrait ce problème par miracle. Au mieux tu tombes pile poil dans une plateforme qui à déjà réglé le truc pour toi (appli eclipse RCP par exemple).

        • [^] # Re: mon grain de sel

          Posté par  (site web personnel) . Évalué à 6.

          Ça tombe bien, les logiciels écrits en Python, quand on veut les lancer, on ne les nomme pas .py…

          • [^] # Re: mon grain de sel

            Posté par  . Évalué à 2.

            wot ? tu les nomme comment ?

            • [^] # Re: mon grain de sel

              Posté par  . Évalué à 4.

               egrep '^#!.*python' /usr/bin/*  
              
              
              • [^] # Re: mon grain de sel

                Posté par  . Évalué à 0.

                egrep c'est déprécié depuis longtemps. Il faut utiliser grep -e.

                Écrit en Bépo selon l’orthographe de 1990

  • # Ben alors ?

    Posté par  (site web personnel) . Évalué à 2.

    Personne pour réagir à son troll du dernier paragraphe ?
    C'est bien.

    • [^] # Re: Ben alors ?

      Posté par  . Évalué à -1. Dernière modification le 04 décembre 2012 à 08:34.

      on attend le jour J… si on pense à revenir sur ce jour nal.

      L'acacia acajou de l'académie acoustique est acquitté de ses acrobaties. Tout le reste prend "acc".

  • # Presque

    Posté par  (site web personnel) . Évalué à 1.

    ça y était presque !
    je me réjouissait de pouvoir enfin essayer Newton Adventure, mais …
    clic droit sur le fichier fraîchement téléchargé -> ouvrir avec installateur de paquets GDebi et là :
    Titre de l'image
    Dommage ce sera pour une prochaine fois :-(
    Bon courage et merci

    kentoc'h mervel eget bezan saotred

    • [^] # Re: Presque

      Posté par  (site web personnel) . Évalué à 2.

      Tu as quoi comme processeur?

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Presque

        Posté par  (site web personnel) . Évalué à 1.

        Un i7 (2600K).
        Et bien entendu un OS 64bits (Debian testing)

        kentoc'h mervel eget bezan saotred

        • [^] # Re: Presque

          Posté par  (site web personnel) . Évalué à 2.

          Que te donne la commande dpkg-architecture ?

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Presque

        Posté par  (site web personnel) . Évalué à 2.

        De plus en plus de distributions sont passés au i686, je ne sais pas si du coup tu ne poses pas des soucis de dépendances en cherchant du i386 qui du coup n'existe plus.

      • [^] # Re: Presque

        Posté par  . Évalué à 2.

        Surtout comme noyau :

        uname -a
        
        

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Presque

        Posté par  (site web personnel) . Évalué à 1.

        Que te donne la commande dpkg-architecture ?

        La commande
        dpkg-architecture
        Renvois
        zsh: command not found: dpkg-architecture

        Par contre la commande
        dpkg --print-architecture
        Donne
        amd64
        Héhé ;-)

        Et pour le noyau :
        uname -a
        Donne
        Linux pc-salon 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux

        (désolé la "balise" code block ne fonctionne pas)

        kentoc'h mervel eget bezan saotred

        • [^] # Re: Presque

          Posté par  (site web personnel) . Évalué à 2.

          Ok, le paquet contient les libs amd64, il faut juste que je le modifie pour que ça passe…

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Presque

          Posté par  (site web personnel) . Évalué à 2.

          En attendant, tu peux utiliser l'installeur universel: http://chiselapp.com/user/devnewton/repository/newton_adventure/doc/trunk/www/downloads/newton_adventure-1.7-installer.jar

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Presque

            Posté par  (site web personnel) . Évalué à 1.

            Merci mais je vais attendre le deb.
            Bon courage.

            kentoc'h mervel eget bezan saotred

            • [^] # Re: Presque

              Posté par  (site web personnel) . Évalué à 2.

              Sinon, dpkg -i --force-architecture !

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

              • [^] # Re: Presque

                Posté par  (site web personnel) . Évalué à 1. Dernière modification le 04 décembre 2012 à 17:46.

                ça ne marche pô

                sudo dpkg -i --force-architecture newton_adventure_1.7.deb
                dpkg : avertissement : problème contourné par utilisation de --force :
                 l'architecture du paquet (i386) ne correspond pas à celle du système (amd64)
                Sélection du paquet newton_adventure précédemment désélectionné.
                (Lecture de la base de données... 311376 fichiers et répertoires déjà installés.)
                Dépaquetage de newton_adventure (à partir de newton_adventure_1.7.deb) ...
                dpkg: des problèmes de dépendances empêchent la configuration de newton_adventure :
                 newton_adventure dépend de java6-runtime.
                 newton_adventure dépend de jarwrapper.
                
                dpkg: erreur de traitement de newton_adventure (--install) :
                 problèmes de dépendances - laissé non configuré
                Traitement des actions différées (« triggers ») pour « gnome-menus »...
                Traitement des actions différées (« triggers ») pour « desktop-file-utils »...
                Des erreurs ont été rencontrées pendant l'exécution :
                 newton_adventure
                
                

                Je vérifie que l'éxecutable est tout de même présent

                whereis newton_adventure
                newton_adventure: /usr/bin/newton_adventure /usr/bin/X11/newton_adventure
                
                

                Mais si j'essaye de le lancer

                newton_adventure
                invalid file (bad magic number): Exec format error
                
                

                D'ailleurs au passage ce serait peut être mieux de l'installer dans /usr/local/games

                kentoc'h mervel eget bezan saotred

                • [^] # Re: Presque

                  Posté par  (site web personnel) . Évalué à 2.

                  Tu utilises quelle distribution? Sans java6, ça ne risque pas de marcher.

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                • [^] # Re: Presque

                  Posté par  (site web personnel) . Évalué à 2.

                  J'ai vu plus haut que tu as debian testing, java6-runtime est bien dedans: http://packages.debian.org/wheezy/java6-runtime

                  dpkg n'installe pas tout seul les dépendances, tu dois le faire à la main.

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                  • [^] # Re: Presque

                    Posté par  (site web personnel) . Évalué à 1.

                    Java est présent, je l'utilise est il fonctionne pour d'autres logiciels.

                    whereis java
                    java: /usr/bin/java /etc/java /usr/bin/X11/java /usr/share/java
                    
                    

                    Pour plus d'infos :

                    aptitude show sun-java6-bin 
                    Paquet : sun-java6-bin                        
                    Nouveau: oui
                    État: installé
                    Automatiquement installé: oui
                    Version : 6.26-3
                    Priorité : optionnel
                    Section : non-free/java
                    Responsable : Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
                    Architecture : amd64
                    ...
                    
                    

                    kentoc'h mervel eget bezan saotred

                    • [^] # Re: Presque

                      Posté par  (site web personnel) . Évalué à 2.

                      Et java -version ?

                      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                      • [^] # Re: Presque

                        Posté par  (site web personnel) . Évalué à 1.

                        Et java -version ?

                        java -version       
                        java version "1.6.0_24"
                        OpenJDK Runtime Environment (IcedTea6 1.11.5) (6b24-1.11.5-1)
                        OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
                        
                        

                        Étrange d'ailleurs, je croyais avoir la version non libre (de sun) et non pas icedtea. Menfin ça ne doit pas changer grand chose vu que tout ce que j'ai en java fonctionne.

                        kentoc'h mervel eget bezan saotred

                        • [^] # Re: Presque

                          Posté par  (site web personnel) . Évalué à 2.

                          On va y arriver!

                          Et si tu lances directement le jar qui est dans /opt/newton_adventure avec java -jar?

                          Je m'installerais un VirtualBox pour tester plein de combinaisons d'OS/distribs avant la prochaine release…

                          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                          • [^] # Re: Presque

                            Posté par  (site web personnel) . Évalué à 1.

                            ça marche \o/

                            la sortie me donne :

                            /opt/newton_adventure/ java -jar newton_adventure.jar
                            5 déc. 2012 17:43:51 im.bci.newtonadv.platform.lwjgl.PlatformSpecific loadConfig
                            INFO: Load config from file jar:file:/opt/newton_adventure/newton_adventure.jar!/config.properties
                            5 déc. 2012 17:43:52 im.bci.newtonadv.platform.lwjgl.openal.SimpleSoundEngine init
                            INFO: SoundEngine initiated with 32 sources
                            5 déc. 2012 17:43:54 im.bci.newtonadv.platform.lwjgl.IconLoader setIcon
                            INFO: nbIcons = 1
                            Loading: net.java.games.input.LinuxEnvironmentPlugin
                            Failed to open device (/dev/input/event13): Failed to open device /dev/input/event13 (13)
                            
                            Failed to open device (/dev/input/event12): Failed to open device /dev/input/event12 (13)
                            
                            Failed to open device (/dev/input/event11): Failed to open device /dev/input/event11 (13)
                            
                            Failed to open device (/dev/input/event10): Failed to open device /dev/input/event10 (13)
                            
                            Failed to open device (/dev/input/event9): Failed to open device /dev/input/event9 (13)
                            
                            Failed to open device (/dev/input/event8): Failed to open device /dev/input/event8 (13)
                            
                            Failed to open device (/dev/input/event7): Failed to open device /dev/input/event7 (13)
                            
                            Failed to open device (/dev/input/event6): Failed to open device /dev/input/event6 (13)
                            
                            Failed to open device (/dev/input/event5): Failed to open device /dev/input/event5 (13)
                            
                            Failed to open device (/dev/input/event4): Failed to open device /dev/input/event4 (13)
                            
                            Failed to open device (/dev/input/event3): Failed to open device /dev/input/event3 (13)
                            
                            Failed to open device (/dev/input/event2): Failed to open device /dev/input/event2 (13)
                            
                            Failed to open device (/dev/input/event1): Failed to open device /dev/input/event1 (13)
                            
                            Failed to open device (/dev/input/event0): Failed to open device /dev/input/event0 (13)
                            
                            Linux plugin claims to have found 0 controllers
                            Selected fallback theme for missing theme "optionsgui"
                            Selected fallback theme for missing theme "columnlayout"
                            Parameter "smallGap" of type "Dimension" not set for "*"
                            Parameter "mediumGap" of type "Dimension" not set for "*"
                            Parameter "largeGap" of type "Dimension" not set for "*"
                            Parameter "defaultGap" of type "Dimension" not set for "*"
                            Parameter "namedGaps" of type "ParameterMap" not set for "*"
                            Selected fallback theme for missing theme "optionsgui"
                            Selected fallback theme for missing theme "columnlayout"
                            Parameter "smallGap" of type "Dimension" not set for "*"
                            Parameter "mediumGap" of type "Dimension" not set for "*"
                            Parameter "largeGap" of type "Dimension" not set for "*"
                            Parameter "defaultGap" of type "Dimension" not set for "*"
                            
                            

                            Par contre c'est presque impossible de jouer j'ai java entre 300 et 400 % de cpu (sur un i7 à 3.5GHz et la résolution de l'affichage ne change rien à ce fait) et du coup ça lag à mort /o\
                            Mais bon j'ai pu avoir un aperçu et il à l'air sympa ton petit jeu, vivement une version qui tourne sans surconsommation processeur.
                            ;-)

                            kentoc'h mervel eget bezan saotred

                            • [^] # Re: Presque

                              Posté par  (site web personnel) . Évalué à 2.

                              Bizarre que ça ne marche pas sauf en tapant la ligne de commande…

                              Par contre c'est presque impossible de jouer j'ai java entre 300 et 400 % de cpu (sur un i7 à 3.5GHz et la résolution de l'affichage ne change rien à ce fait) et du coup ça lag à mort /o\

                              Tu as quoi comme carte graphique et type de drivers? Je développe sur un core duo avec une carte intel, donc ça devrait passer sur des configs plus balaises.

                              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                              • [^] # Re: Presque

                                Posté par  (site web personnel) . Évalué à 1.

                                J'ai une Nvidia GT430 (no comment please) avec les dernier drivers proprios (NVIDIA-Linux-x86_64-304.64), elle fonctionne sans problèmes vu que je joue à des jeux (2d et 3d) modernes en haute résolution (jusqu'à 1920x1080) sans problèmes.

                                kentoc'h mervel eget bezan saotred

                                • [^] # Re: Presque

                                  Posté par  (site web personnel) . Évalué à 2.

                                  C'est étrange, tu as une config bien meilleure que la mienne!

                                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                • [^] # Re: Presque

                                  Posté par  (site web personnel) . Évalué à 3.

                                  J'ai testé le deb avec une debian 6 dans virtualbox ( http://downloads.sourceforge.net/virtualboximage/debian_6.0.6.vdi.7z ) et voici le résultat:

                                  • les outils graphiques sont une catastrophe: nautilus ouvre le deb comme un zip, synpatic ne peut pas installer de deb et GDebi n'est pas capable d'installer les dépendances.
                                  • en ligne de commande, un dpkg --install newton_adventure_1.7.deb suivi d'un apt-get -f install a fait l'affaire, mais ce n'est pas vraiment intuitif.

                                  Sans activer l'accélération 3d de virtualbox, le jeu se plante au démarrage.

                                  En l'activant, le jeu se lance du premier coup depuis l'entrée dans menu games à 40 fps. Pas mal pour un jeu qui tourne dans un émulateur sur mon vieux PC!

                                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                  • [^] # Re: Presque

                                    Posté par  (site web personnel) . Évalué à 1.

                                    Il est possible que le problème chez moi vienne de l'architecture amd64.

                                    kentoc'h mervel eget bezan saotred

                  • [^] # Re: Presque

                    Posté par  (site web personnel) . Évalué à 2.

                    http://hjuarez.blogspot.fr/2010/05/linux-java-hotspotgcj-error.html ?

                    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Allez j'me lance

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    T'as essayé d'aller ici ?
    Non sérieusement, quelqu'un ici a t-il déjà essayé de mettre une appli sur la Logithèque Ubuntu ? C'est bien ou pas (du point de vue développeur s'entend) ?

    • [^] # Re: Allez j'me lance

      Posté par  (site web personnel) . Évalué à 2.

      C'est prévu!

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Allez j'me lance

      Posté par  (site web personnel) . Évalué à 5.

      T'as essayé d'aller ici ?

      Le store Ubuntu est surtout prévu pour les applis non libres.
      Je suis sur ce Store, sans avoir rien fait, tout bêtement car je suis sur dans les dépôts Debian. A mon avis, quitte à faire du libre et qu'on voudrait quand même aussi avoir Debian, autant aller à la source sans faire ce doublon intermédiaire. Conclusion : le Saint Graal est le dépot Debian plutôt, quand tu fais du libre, et le reste basé sur Debian suit. Bon courage ;-).

      • [^] # Re: Allez j'me lance

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Le store Ubuntu est surtout prévu pour les applis non libres.

        Peut-on y mettre des applis libres mais payantes ? Par "payantes", j'entends "payables via l'interface de la Logithèque" évidemment.

      • [^] # Re: Allez j'me lance

        Posté par  (site web personnel) . Évalué à 2.

        «A mon avis, quitte à faire du libre et qu'on voudrait quand même aussi avoir Debian, autant aller à la source sans faire ce doublon intermédiaire.»

        J'avais juste regardé vite fait le store Ubuntu à un moment, mais j'ai quand même l'impression que c'est beaucoup plus facile d'y être dessus que dans Debian. Du coup pour des logiciels qui ont pas (encore) une grosse popularité pour attirer l'attention d'un développeur Debian et dont les développeurs n'ont pas l'énergie ou les compétences suffisantes pour faire un paquet satisfaisant à un upload dans Debian et se taper le processus, je me dis que ça peut quand même être utile éventuellement pour que le logiciel soit plus distribué.

        Cela dit, j'ai pas testé et j'ai peut être tort :)

  • # rpm

    Posté par  (site web personnel) . Évalué à 2.

    Toujours à l'aide de plugin Maven, j'ai pu générer des paquets au format rpm que j'ajouterais lors de la prochaine release:

    https://devnewton.bci.im/tmp/newton_adventure_1.7_beta/newton_adventure-1.7-1.i686.rpm
    https://devnewton.bci.im/tmp/newton_adventure_1.7_beta/newton_adventure-1.7-1.x86_64.rpm

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # JWS

    Posté par  . Évalué à 1.

    l'utilisation de bibliothèques natives provoque l'affichage de popups d'alerte à faire fuir le plus intrépide des utilisateurs.

    Dans mon ancienne boite je bossais sur une appli en Java déployée via JWS. Pour s'affranchir des alertes de sécurité, nous fournissions des JARs signés. A noter que depuis les dernières version de Java, il est également nécessaire de signer le JNLP.

    • [^] # Re: JWS

      Posté par  (site web personnel) . Évalué à 2.

      La signature est bien obligatoire, mais pour ne pas avoir un message d'erreur, il faut acheter un certificat SSL.

      Il y a aussi un autre message d'erreur lié à l'utilisation de bibliothèques natives contre lequel on ne peut rien faire.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.