Ici on n'a que votre IP, votre pseudo et votre adresse mail que nous ne traitons pas.
Quand vous êtes enregistrés, une seule requête permet de vous afficher les messages que vous n'avez pas lus.
NOUVELLE ADRESSE PERMANENTE DU DÉPÔT: https://mirrors.o2switch.fr/primtux/repo/debs
ATTENTION, MERCI DE NE PAS METTRE À JOUR PRIMTUX7 UBUNTU 20.04 VERS LA 22.04, LES HANDYMENUS NE SONT PAS ENCORE COMPATIBLES!
Merci de cliquer ici si vous souhaitez vous inscrire sur le forum.

Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
ClicMenu : A la campagne
#76
Sur le problème du dossier d'installation, il ne semble pas y avoir de réponse certaine. Sur le forum Debian, on me renvoie vers les listes de diffusion des développeurs Debian. Comme je n'ai pas envie de passer mon temps à écumer ces listes pour trouver la plus appropriée, d'autant plus que mon anglais est très basique, je propose la chose suivante pour toutes ces applications. Cela tient compte des réponses obtenues jusqu'à présent à ma question.

On place le lanceur de Firefox avec le lien vers le html de l'application dans /usr/bin.
On place les fichiers de l'application elle-même dans /opt/nom-appli.

Qu'en pensez-vous ?
Répondre
#77
J'en pense que les applis html on devrait les mettre dans /var/www histoire de ne pas être embêté le jour où on aura du php + le pb du fameux flash (gnash ne fonctionne pas chez moi aussi bien en Debian qu'en Ubuntu): un jour on ne pourra plus exécuter tout le flash en local et il faudra feinter avec un hostname, comme je vais le faire pour matou matheux.
Répondre
#78
Ce qui ressort des retours des forums, c'est que le dossier /var est réservé à ce qui est régulièrement modifié. Ce n'est pas le cas des applications pur html5 + javascript qui sont statiques et qui n'ont pas besoin de Flash.
Répondre
#79
Franchement est-ce que ça a une importance? Un site a toujours été dans /var/www. Moi ce que je veux c'est du pratique. On case tout ce qui est php et html dans ce répertoire, le jour où on veut les caser en ligne on n'aura pas à trier ce qu'on peut mettre ou pas, mieux que ça, celui qui veut les partager en réseau local sans avoir à tout copier sur tous les postes en sera bien plus satisfait.
Alors oui on peut changer le chemin des sources mais si tu prends le ctparental, il est bien dans /var/www.
Répondre
#80
Nouveau lien pour le test en ligne de l'application:
https://www.de-bric-et-de-broc.fr/test/a...lacampagne
ou
https://www.de-bric-et-de-broc.fr/test/a...index.html

Je suis en train de faire le paquet.

Quelqu'un a une idée pour l'icône de l'application ?
Le problème se posera pour les autres applications javascript. Fait-on une icône personnalisée pour chaque application, ou utilise-t-on une même icône les unifiant, marquant leur origine (les applications clicmenu) ?
Répondre
#81
Pour ceux qui ont étudié de façon approfondie les avantages/inconvénients des diverses licences libres, quelle licence conseillez-vous pour ces applications ? Si en plus vous pouvez préciser pourquoi, ce serait parfait Wink !
Répondre
#82
Pour les licences libres, je dirais qu'il y a 3 familles de licences :
- BSD
- GPL 2 et 3
- créatives commons

Les creatives commons c'est de la licence combinatoire. L'idée sur le papier est pas mal, dans les faits je trouve que ça fait doublon avec les 2 premières. (parce que la combinaison final aboutira souvent à une BSD, une GPL ou du propriétaire à peut de chose prête)

Entre la BSD et la GPL, la différence est principalement sur la protection de l'utilisateur.
La BSD met dans le domaine publique donc tout le monde peut en faire ce qu'il veut.
Par exemple, intégrer ton soft dans une suite logicielle éducative qui est entièrement propriétaire, modifier son code à sa convenance, en faire un usage commercial sans que personne ne puisse rien dire, sans en informer personne.

Si tu pars sur la GPL, ça donne une vrai assurance à l'utilisateur (bon dans les faits, c'est sans doute discutable): les 3 premières libertés essentiels :
Liberté 0. La liberté d'exécuter le logiciel, pour n'importe quel usage ;
Liberté 1. La liberté d'étudier le fonctionnement d'un programme et de l'adapter à ses besoins, ce qui passe par l'accès aux codes sources ;
Liberté 2. La liberté de redistribuer des copies ;

Une assurance pour le dev et la communauté autours du soft :
L'obligation de faire bénéficier la communauté des versions modifiées.

La GPL 3 améliore un peu l'existant en encourageant à mettre en place le code sur un espace publique, à fournir une doc quand il y a des dépendances et à éviter que des fonctionnalités du logiciels soient dégradé à cause du matériel.
(Exemple tiré par les cheveux (ou presque) : imagine un ordi qui bloquerait le drag and drop tant que t'as pas regardé une pub, payé un abonnement etc.)

Perso, quand je sais pas ou que je m'en fou, je met du BSD.
Sinon, c'est GPL 3.

Comme ça, je te conseillerais la GPL, c'est ce qui y a de plus éthique à mon sens mais vu les explications, fait ce qui te semble le mieux.
Répondre
#83
Merci pour les infos.
ça sera du GPL3 !
Répondre
#84
Voici le paquet :
http://www.primtux.fr/Documentation/appl....0_all.deb

Lanceur dans /usr/bin, fichiers dans /var/www
Répondre
#85
Je viens de revoir l'application compte-tenu des remarques faites ici et sur linuxfr.org :
  • les enclos changent de position en fonction du tirage aléatoire des animaux. Ainsi on a toujours les poules dans le poulailler, les lapins dans le clapier, etc.
  • plus de bouton commencer. Le jeu démarre dès clic sur un bouton de niveau.


Comme il m'a fallu revoir tout le html et le css (la routine javascript était relativement facile à mettre en place), d'autres bugs ont pu apparaître et un nouveau test approfondi de l'application est nécessaire.

Nouveau lien pour le test en ligne:
https://primtux.fr/applications/alacampagne/
Répondre
#86
J'ai joué de 1 à 10 une fois et ça marche, avec et sans erreurs.
Répondre
#87
Test rapide : J'ai des soucis de responsive sur l'éolienne et le pommier lors du resize et lors du drag.
Répondre
#88
Peux-tu être plus précis ?

Lors du drag, je suis obligé de les mettre en arrière plan en modifiant les z-index sinon il n'est plus possible de déposer les animaux dans les enclos. Je n'ai pour l'instant pas trouvé d'autre solution étant donné que je suis obligé de scinder les différentes images pour permettre la rotation des enclos.

Pour le resize, leur position peut très légèrement évoluer compte-tenu du fait que les images sont indépendantes des enclos.
Répondre
#89
Philippe a écrit :Lors du drag, je suis obligé de les mettre en arrière plan en modifiant les z-index sinon il n'est plus possible de déposer les animaux dans les enclos.

Il faudrait que je regarde le code à tête reposé mais le soucis me semble à ce niveau.
Tu ne devrais pas changer les z-index. (y'a rarement des bonnes raisons de toucher aux z-index d'ailleurs, c'est la boite de pandore ça avec les !important)

Normalement, tes animaux doivent être drag dans des zones invisibles situé au dessus des autres (donc naturellement, avec leur place dans le DOM et non pas avec des z-index)
Si tu fais ça, t'auras pas ce genre de soucis.

Ces zones sont définis dès le commencement de l'exercice et ne bouge pas tout la durée de celle-ci.
Répondre
#90
mothsart a écrit :Normalement, tes animaux doivent être drag dans des zones invisibles situé au dessus des autres (donc naturellement, avec leur place dans le DOM et non pas avec des z-index).
Ces zones sont définis dès le commencement de l'exercice et ne bouge pas tout la durée de celle-ci.
Oui, si les enclos ne changent pas de place !
Là ils doivent changer de place, et certains éléments d'illustration doivent se trouver au-dessus (éolienne, arbre, fermier et leurs ombres).

Pour faire ce que tu dis, il faudrait avoir 2 div qui se superposent, celle du dessus étant seule en mesure de recevoir les animaux. ça pourrait être faisable, mais compte-tenu du fait qu'il y a aussi à intégrer les indications d'exercice (animaux et nombre), d'erreur (croix rouge), des zones réduites par rapport à l'illustration de l'enclos pour ne pas que les animaux en débordent, et que je suis parti sur de la mise en forme avec du flex, ça nécessiterait de revoir encore complètement le html et le css.

ça ira donc comme ça, le fait que certains éléments s'estompent pour mettre en avant les enclos ne m'apparaissant pas aberrant (déposer un animal sur un arbre pour le mettre dans un enclos pouvant tout autant paraître curieux !).

Le problème, sur cette application, est que :
  • c'est l'une des toutes premières que j'ai faites (avec donc un manque de connaissances et d'expérience)
  • le graphisme est venu après le moteur javascript, et intégrait de nombreux éléments complexifiant le fonctionnement (enclos de tailles différentes compte-tenu des bâtis, non rctangulaires, bâtis au sein même des enclos, abreuvoirs, etc.)

Donc actuellement je me contenterai de corriger les problèmes de fonctionnement, quitte à accepter certaines libertés quant à la réalité (après tout, c'est une application de numération, et le graphisme n'a surtout qu'un rôle illustratif et esthétique).

Je ferai mieux sur les suivantes ! Wink
Répondre
#91
Je suis en train de te faire un correctif.
Dès que c'est acceptable, je ferais une demande de merge.

Philippe a écrit :Je ferai mieux sur les suivantes !

J'en doute pas.
Répondre
#92
Pour les sources des dernières modifications, tu as bien vu que c'est sur la branche "enclos", et non sur la branche master ?
Répondre
#93
Oui, Philippe : pas de prob. (j'avais lu ton commentaire sur linuxfr)
Répondre
#94
Voilà, c'est disponible sur la branche "enclos-responsive" qui part de "enclos".
Y'a sans doute plein de petits détails à réajuster mais j'ai réglè les soucis de z-index et par la même occasion j'ai allégé pas mal ton css.
Je vais essayé de t'expliquer ce que j'ai fait point par point.
Répondre
#95
Je viens de jeter un oeil rapidement et j'ai plusieurs problèmes:
  • les deux premiers animaux de la réserve se chevauchent;
  • l'éolienne est en arrière plan
  • l'ombre du fermier a disparu (sans doute parce qu'elle est en arrière-plan)


Sinon j'avais amélioré sur la branche enclos: les images en 1er plan ne s'estompent plus toutes au moment du drag, mais une à une uniquement lorsque chacune d'elle est survolée.
Répondre
#96
En premier, j'ai commencé à virer les z-index car je comprenais pas leur raison d'être.
J'ai fait pareil pour les différentes tailles d'écran (media queries) avec des paramètrages spécifiques.
Cumuler plein de tailles d'écran, tu as dût t'en rendre compte, à modifier ça devient vite chronophage.

Une fois le travail de nettoyage terminé, j'ai attaqué l'organisation du html.
Le mieux, à mon sens était d'avoir une zone invisible de "drop" par dessus et une zone d'affichage des enclos indépendants.

Pareil, je pense que tu t'es embêté avec les placements des éléments tel que l'arbre et l'éolienne.
Le soucis de z-index la dessus était lié au fait que tu utilisais un placement avec flexbox ou tu avais des goutières non proportionnels.
La j'ai scindé en 2 tailles : portrait et paysage.
portrait : on resize en fonction de la largeur de l'écran et paysage en fonction de la hauteur.

Il y a encore du z-index sur la zone de drag et sur les animaux mais avec un peu d'astuce, je devrais pouvoir les enlever.

Dans tous les cas, je conseil de ne pas faire de css à la volée dans le js.
Le mieux c'est de donner des comportements avec des classes.
Le js ne s'occupe que d'ajouter ou enlever ces classes. ça à plusieurs avantages :
- tout ton css est au même endroit.
- moins de calcul de placement à la volée.

J'ai utilisé la propriété "clip-path" en css car elle permet de préciser une zone de drag non linéaire.

Philippe a écrit :Je viens de jeter un oeil rapidement et j'ai plusieurs problèmes:
...

Oui, sans doute des détails.
J'ai eu vraiment peu de temps donc je suis allé à l'essentiel.
Je vais refaire un tour dessus dans les jours qui viennent.
Répondre
#97
Je découvre clip-path qui m'aurait effectivement été bien utile !

Si j'ai bien compris, les zones de drop sont invisibles et n'apparaissent qu'en début de drag.

Pour le principe de travail uniquement avec les changements de classe plutôt que les modifications du css par javascript, c'est cette méthode que je privilégie dorénavant avec l'expérience, expérience que je n'avais pas encore lors du développement de à la campagne !

En testant, il y a d'autres problèmes: les animaux "s'empilent" dans les enclos au lieu de s'afficher les uns à côté des autres. Dans a réserve également, ils finissent par se mettre les uns sur les autres, pas seulement les deux premiers.

Tu as effectivement bien simplifié les media queries.
J'avais été contraint de multiplier la différenciation selon les proportions à cause des débordements de la zone de drop.
Dans ce que tu as fait, en mode portrait, les zones de drop débordent cependant de plus en plus des enclos au rétrécissement de la largeur.
Il n'y a en revanche pas de problèmes en mode portrait.
Répondre
#98
Philippe a écrit :Pour le principe de travail uniquement avec les changements de classe ...

Pas de prob, aucune critique derrière.
Le but c'est que tu montes en compétence et aussi qu'on ai les mêmes mode de fonctionnement pour que le code soit facile à reprendre.

Les animaux "s'empilent" : oui, je vois => passage en position "absolute".

Je suis clairement allé un peu vite en recette. J'ai dev en mode paysage et j'ai regardé en rapide en mode portrait.
Je repasse sur tout ça.
Répondre
#99
Voilà, j'ai "normalement" corrigé tous les soucis évoqués précédemment.
Un soucis récurent venait de l'utilisation de position en "absolute" au lieu de "relative".
Le principale soucis avec ça c'est que ça nécessite de maintenir tous les éléments en absolute en fonction des tailles d'écrans.
Pour s'en sortir, la meilleur méthode (à mon sens) et d'avoir des éléments conteneur qui sont en absolue.
Je leur met un background-color pour voir les déplacements en responsive et je m'assure que le centrage est bon partout. (voir https://www.alsacreations.com/article/li...n-CSS.html quand on a des fuites mémoires ou des doutes)
Une fois ce point règlé, on ajuste tout ce qui est à l'intérieur de ces divs englobantes avec des positions en relative avec des unités en pourcentage.
Du coup, tout ce déplace en fonction du parent et y'a plus de blagues.

Comme convenue, il n'y a désormais plus aucun z-index.
Une zone de drag devant les autres mais transparente et des décors à l'arrière.
Les 2 divs ont une arborescence très proche, ce qui permet de factoriser des règles css.

J'ai factorisé encore un peu le css, supprimé un peu de dead code etc.
C'est sans doute pas parfait mais ça avance.
Répondre
Je t'ai fait une demande de merge : https://framagit.org/philippe-dpt35/alac...requests/2
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)