Sommaire
- Du simple zip...
- ... au paquet d'installation
- Et Java Web Start ?
- Conclusion
- Mais... et Newton Adventure ?
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 Nonolapéro . É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 :
[^] # Re: Les retours de chariot à la main c'est mal
Posté par devnewton 🍺 (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 gasche . É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 Marotte ⛧ . É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 Zenitram (site web personnel) . Évalué à -2. Dernière modification le 04 décembre 2012 à 15:37.
Et je l'en remercie.
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 Shuba . Évalué à 6.
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 Zenitram (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 gasche . É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 MrLapinot (site web personnel) . Évalué à 4.
Et ça permet aussi d'avoir des diffs significatifs et lisibles quand on stocke son texte dans un gestionnaire de version comme git, svn ou darcs.
[^] # Re: Les retours de chariot à la main c'est mal
Posté par gasche . Évalué à 2.
Oui, même si en général
git diff --word-diff=colorest ton ami.[^] # Re: Les retours de chariot à la main c'est mal
Posté par MrLapinot (site web personnel) . Évalué à 2.
Si tu formates à 80 caractères et que tu modifies la première phrase d'un paragraphe, je ne pense pas que ça aide beaucoup (tout le paragraphe sera en rouge, non ? ou alors word-diff ignore les retours à la ligne ?)
[^] # Re: Les retours de chariot à la main c'est mal
Posté par gasche . Évalué à 5.
word-difffonctionne mot par mot et ignore donc les différences d'espacement, retours à la ligne inclus.[^] # Re: Les retours de chariot à la main c'est mal
Posté par CrEv (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 oinkoink_daotter . Évalué à 2.
Si. En plus, c'est un Apple Fanboy.
[^] # Re: Les retours de chariot à la main c'est mal
Posté par Frank-N-Furter . Évalué à 4.
Pas un Apple Fanboy, mais L'Apple Fanboy.
Depending on the time of day, the French go either way.
[^] # Re: Les retours de chariot à la main c'est mal
Posté par Sygne (site web personnel) . Évalué à 5.
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 gvdmoort . Évalué à 2.
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 CrEv (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 Zenitram (site web personnel) . Évalué à -10. Dernière modification le 03 décembre 2012 à 17:03.
Bienvenue sous Linux ;-).
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 :
Peu se mettre en :
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 devnewton 🍺 (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 BAud (site web personnel) . Évalué à -1.
si, bien sûr.
[^] # Re: Bienvenue et évolution technologique
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Comment?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bienvenue et évolution technologique
Posté par BAud (site web personnel) . Évalué à 2.
En étant modérateur, tout simplement.
J'en ai profité pour corriger 2-3 coquilles.
[^] # Re: Bienvenue et évolution technologique
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Merci!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bienvenue et évolution technologique
Posté par gasche . Évalué à 3.
Ou un commentaire…
Mais heureusement les modérateurs sont là (ou pas) pour corriger nos fautes de français, typos, et erreurs de mise en page. Chouette métier.
[^] # Re: Bienvenue et évolution technologique
Posté par CrEv (site web personnel) . Évalué à 3. Dernière modification le 04 décembre 2012 à 16:17.
Oui et non, puisque tu peux éditer un commentaire pendant un laps de temps (je ne sais plus combien) si personne n'y a répondu.
M'enfin on va pas refaire le débat à ce sujet ;-)
Edit: Plop
[^] # Re: Bienvenue et évolution technologique
Posté par julmx . Évalué à 4.
Le même package fonctionne sur mac et windows ?
[^] # Re: Bienvenue et évolution technologique
Posté par devnewton 🍺 (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 vida18 . Évalué à 1.
Quel logiciel utilises-tu pour développer le jeu ? Game Develop ? Unity ?…
[^] # Re: Bienvenue et évolution technologique
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Un moteur fait maison basé sur http://www.lwjgl.org/
En libre, il y a http://game-editor.com et http://jmonkeyengine.com/ aux logiciels que tu as cité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bienvenue et évolution technologique
Posté par vida18 . Évalué à -3.
Ok perso j'utilise Game Develop. Je n'ai pas trouvé plus simple pour faire un jeu 2D.
En plus il y a une excellente documentation.
[^] # Re: Bienvenue et évolution technologique
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Il a l'air propriétaire, donc bof…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bienvenue et évolution technologique
Posté par vida18 . Évalué à -10.
Pourquoi vouloir à tout pris vouloir utiliser QUE des logiciels libres !?
Moi tant que le logiciel fonctionne parfaitement sans bug sous Windows et Linux et que je peux compiler les jeux ainsi créés pour Windows et Linux alors "what else ?" ?
[^] # Re: Bienvenue et évolution technologique
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Si je passe du temps à créer un jeu avec passion, je préfère ne pas être à la merci d'un éditeur de logiciel qui peut changer de licence ou de prix à tout moment.
(Ca peut aussi arriver avec un logiciel libre, mais au moins j'aurais une chance de récupérer mon travail grâce à un fork).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bienvenue et évolution technologique
Posté par coïn . Évalué à 10.
La liberté
[^] # Re: Bienvenue et évolution technologique
Posté par El Titi . É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 CHP . Évalué à 6.
Euh…
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 El Titi . É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 CHP . Évalué à 6.
J'ai répondu à la question 'pourquoi il est moinsé comme ca', pas à la question 'pourquoi personne ne répond sur le fond'
[^] # Re: Bienvenue et évolution technologique
Posté par Guillaume Knispel . Évalué à 1.
Il n'y a pas de fond dans le trolling pur.
La méthode de traitement consiste à simplement ignorer. (Des fois c'est trop dur, alors on dérape, et on répond au lieu d'ignorer.)
[^] # Re: Bienvenue et évolution technologique
Posté par Dr BG . É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 Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# Pour le lancement du jar
Posté par vlamy (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 🚲 Tanguy Ortolo (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 :
[^] # Re: Pour le lancement du jar
Posté par vlamy (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 fearan . Évalué à 10.
pour faire simple
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 CrEv (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 Frank-N-Furter . É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 Blackknight (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 Frank-N-Furter . É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 ckyl . Évalué à 8. Dernière modification le 04 décembre 2012 à 08:54.
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:
[^] # Re: Pour le lancement du jar
Posté par Paf . Évalué à 5.
Ca peut aussi aider a traquer le pid si besoin est.
[^] # Re: Pour le lancement du jar
Posté par devnewton 🍺 (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 zebra3 . Évalué à 8.
Pour les autres, ajoute un fichier .desktop qui appelle cette commande :-)
Un petit exemple :
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 barmic . É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 barmic . É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 Thomas Debesse (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
mettez y ce texte :
marquez-le comme exécutable :
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 zebra3 . É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 vlamy (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 Marotte ⛧ . Évalué à 3.
Je me suis fait la même réflexion :
?
[^] # Re: Pour le lancement du jar
Posté par devnewton 🍺 (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 Cyrille Pontvieux (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 Marotte ⛧ . Évalué à 2.
+1 sauf pour :
il doit y avoir une erreur.
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 devnewton 🍺 (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 Cyrille Pontvieux (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 devnewton 🍺 (site web personnel) . Évalué à 2.
Merci!
Je ne connaissais pas Salix, mais ça a l'air pas mal.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pour le lancement du jar
Posté par boq . Évalué à 3.
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 Thomas Debesse (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 :
Tout sauf une question accessible à tout un chacun !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pour le lancement du jar
Posté par ariasuni . Évalué à 2.
Oui c'est le comportement par défaut que même des IUT infos ont du mal à comprendre!
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pour le lancement du jar
Posté par vlamy (site web personnel) . Évalué à 1.
Mais où va la jeunesse !?
Ça promet, pour des futurs développeurs et informaticiens en tout genre :)
[^] # Re: Pour le lancement du jar
Posté par ariasuni . Évalué à 2.
Moi-même j'ai découvert la navigation mot par mot avec CTRL il y a 3-4 jours (oui j'ai honte).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pour le lancement du jar
Posté par vlamy (site web personnel) . Évalué à 1.
Je suis choqué, je viens de tester et ça marche aussi dans emacs :)
# Paquets Debian
Posté par 🚲 Tanguy Ortolo (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 barmic . É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 devnewton 🍺 (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 Lucas . É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 fravashyo . Évalué à 0.
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 zebra3 . Évalué à 3.
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 fravashyo . É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 zebra3 . É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 :
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 fravashyo . É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 🚲 Tanguy Ortolo (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 devnewton 🍺 (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 Batchyx . É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 devnewton 🍺 (site web personnel) . Évalué à 4.
?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Paquets Debian
Posté par Batchyx . É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 claudex . É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 fravashyo . Évalué à 7.
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 totof2000 . É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 claudex . É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 zebra3 . É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 flan (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 stopspam . Évalué à 6. Dernière modification le 04 décembre 2012 à 20:02.
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 ariasuni . É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 claudex . É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 ariasuni . É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 fearan . Évalué à 2.
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 ckyl . Évalué à 5.
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 manifest t'indique si il y a une main-class ou non.
[^] # Re: mon grain de sel
Posté par coïn . Évalué à 3.
7zip a ce comportement, ca m'a surpris :)
[^] # Re: mon grain de sel
Posté par barmic . É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 coïn . É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.
[^] # Re: mon grain de sel
Posté par Marotte ⛧ . É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 fearan . É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 devnewton 🍺 (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 oinkoink_daotter . É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 devnewton 🍺 (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 barmic . Évalué à 4.
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 ?
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.
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 Renault (site web personnel) . Évalué à 4.
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 ckyl . Évalué à 6.
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.
Je pense que tu peux relire la spécification
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 Graveen . É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 devnewton 🍺 (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 lolop (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…
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: mon grain de sel
Posté par ckyl . É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 🚲 Tanguy Ortolo (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 coïn . Évalué à 2.
wot ? tu les nomme comment ?
[^] # Re: mon grain de sel
Posté par ckyl . Évalué à 4.
[^] # Re: mon grain de sel
Posté par ariasuni . É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 Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Personne pour réagir à son troll du dernier paragraphe ?
C'est bien.
[^] # Re: Ben alors ?
Posté par LeXa1979 . É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 reynum (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à :
Dommage ce sera pour une prochaine fois :-(
Bon courage et merci
kentoc'h mervel eget bezan saotred
[^] # Re: Presque
Posté par devnewton 🍺 (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 reynum (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 devnewton 🍺 (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 Renault (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 barmic . Évalué à 2.
Surtout comme noyau :
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 reynum (site web personnel) . Évalué à 1.
La commande
dpkg-architectureRenvois
zsh: command not found: dpkg-architecturePar contre la commande
dpkg --print-architectureDonne
amd64Héhé ;-)
Et pour le noyau :
uname -aDonne
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 devnewton 🍺 (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 devnewton 🍺 (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 reynum (site web personnel) . Évalué à 1.
Merci mais je vais attendre le deb.
Bon courage.
kentoc'h mervel eget bezan saotred
[^] # Re: Presque
Posté par devnewton 🍺 (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 reynum (site web personnel) . Évalué à 1. Dernière modification le 04 décembre 2012 à 17:46.
ça ne marche pô
Je vérifie que l'éxecutable est tout de même présent
Mais si j'essaye de le lancer
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 devnewton 🍺 (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 devnewton 🍺 (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 reynum (site web personnel) . Évalué à 1.
Java est présent, je l'utilise est il fonctionne pour d'autres logiciels.
Pour plus d'infos :
kentoc'h mervel eget bezan saotred
[^] # Re: Presque
Posté par devnewton 🍺 (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 reynum (site web personnel) . Évalué à 1.
É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 devnewton 🍺 (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 reynum (site web personnel) . Évalué à 1.
ça marche \o/
la sortie me donne :
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 devnewton 🍺 (site web personnel) . Évalué à 2.
Bizarre que ça ne marche pas sauf en tapant la ligne de commande…
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 reynum (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 devnewton 🍺 (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 devnewton 🍺 (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:
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 reynum (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 devnewton 🍺 (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 Laurent Pointecouteau (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 devnewton 🍺 (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 Zenitram (site web personnel) . Évalué à 5.
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 Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2.
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 Lizzie Crowdagger (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 devnewton 🍺 (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 Yarma22 . Évalué à 1.
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 devnewton 🍺 (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.