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
Faire l'appel sur TBI
#1
Bonjour,

J'avais codé un petit logiciel en python pour faire l'appel au TBI. Je l'ai utilisé en petite section, ça a permis aux enfants de vite se reconnaître. Je vous le partage en espérant qu'il puisse servir à quelqu'un.

[Image: 3.png]

Télécharger le logiciel
Répondre
#2
Merci pour ce partage.
Répondre
#3
Why not pour les maternelles... Merci!
Répondre
#4
Très sympa. Merci de la contribution.

Ce soft manque un peu de finition et d'être empaqueté pour être utilisé par tout un chacun.
Je vais essayé de te donner un petit coup de pouce.
Répondre
#5
Salut mothsart,
Content d'avoir ton avis (je pense donc que tu l'as testé!). Par contre je n'en ai plus l'utilité, alors je ne me sens pas trop de le maintenir et de l'améliorer. Si tu y vois un intérêt je te laisse faire Wink
Répondre
#6
Oui, j'ai testé Big Grin

Je n'y vois pas d'intérêt direct (je ne suis qu'un parent d'élèves donc avec 2 enfants qui sont au primaire, pas besoin de faire l'appel).
En revanche, je suis sensible à l'utilité que ce soft peut avoir en classe et j'essai de participer à Primtux pas que à auteur de ce qui me plait ou me sert mais dans l'optique d'avoir un support numérique le plus riche et adapté à l'enseignement en général.

Je vais déjà empaqueter ton soft pour qu'il puisse être installé/désinstallé proprement. (également par des moldus)

Pour ce qui est de le corriger, on verra dans un second temps.

Pour l'améliorer, c'est moins certain. On verra : en fonction de mon temps et de l'intérêt suscité.

Est-ce que ce soft a une licence ? La question porte aussi bien pour le code que le contenu (images par exemple).
Pour le code, l'idéal serait une licence bsd ou gpl.

kimented a écrit :Par contre je n'en ai plus l'utilité, alors je ne me sens pas trop de le maintenir et de l'améliorer.

Je comprend tout à fait. C'est déjà assez généreux de nous faire part de ton soft.
Répondre
#7
J'ai mis dans le zip un fichier readme où j'autorise quiconque à faire ce qu'il en veut (dans le genre de la WTFPL). Je pense que mettre une licence plus contraignante ne sert à rien (en tout cas ça ne m'apporterait rien de plus), mais sinon BSD ça me va aussi. Je n'ai pas pris la peine de faire ça plus proprement ^-^

Les images proviennent d'Openclipart, c'est du CC0/domaine public mais je n'ai pas noté les noms des auteurs. Il y a quelques icônes provenant du thème Tango qui est dans le domaine public. Après, peut être qu'il y a des images qui conviendraient mieux, à voir...
Répondre
#8
Ah, j'avais vu le fichier README mais pas la license.

Je pense que je vais mettre de la BSD plus par soucis d'uniformisation.

Images dans le domaine public, c'est parfait.

Citation :Après, peut être qu'il y a des images qui conviendraient mieux, à voir...

Oui, aucune urgence.
Je me concentre sur l'empaquetage sans rien toucher d'autre... le reste, ça sera du bonus.

Comme toujours, rien n'est parfait. Le soft a le mérite d'exister. Ca peut répondre à un besoin donc c'est top.
C'est dev dans un langage simple et populaire (et déjà éprouvé au sein de Primtux). Résultat des courses, il pourra très bien être amélioré ou servir d'exemple à d'autres softs.

Primtux est une distribution donc l'idée sous-jacente c'est bien de :
- mettre à dispo le max d'outils pour l'enseignement avec des process éprouvés. (installation via apt)
- donner de la cohérence à un ensemble de softs hétérogènes
Répondre
#9
Bonjour
En tant qu'erun je suis intéressé pour le présenter en maternelle...

j'aurai bien testé mais je ne sais pas comment

j'ai une primtux dg i-686
j'ai dézippé et j'obtiens une liste de fichiers et de répertoires

si je clique sur appel_1.py il ne se passe rien

si je lance en commande python
j'ai administrateur@debian:~/Téléchargements/appel$ sudo python
[sudo] Mot de passe de administrateur : 
Python 2.7.13 (default, Sep 26 2018, 18:42:22)
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

si je lance administrateur@debian:~/Téléchargements/appel$ python appel_1.py
File "appel_1.py", line 10
SyntaxError: Non-ASCII character '\xc3' in file appel_1.py on line 10, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
administrateur@debian:~/Téléchargements/appel$

Utilisant pylote et m'en servant régulièrement je ne veux pas toucher au python installé

bref un empaquetage facile à mettre en place m'est indispensable !

Alain
Répondre
#10
Salut!
Je ne suis pas un spécialiste, j'ai fait cet outil qui correspondait à mes besoins. Pour l'empaquetage, je passe donc la main, mais qui sait je peux améliorer en cas de besoin (avoir des retours, ça motive Wink )

La dernière erreur que tu as viens du fait que c'est python 2.7 qui est utilisé, et mon logiciel nécessite python 3.5+. Pas besoin d'être administrateur pour l'exécuter (pas de sudo), essaie donc comme ça:

Code :
administrateur@debian:~/Téléchargements/appel$ python3 appel_1.py

Mais il risque de manquer des dépendances. En cas de besoin, installes les de cette façon:

Code :
sudo apt install python3-tk python3-pil

Une particularité du format zip c'est qu'il ne garde pas les droits sur les fichiers. Pour exécuter les programmes juste en double-cliquant dessus il faut les rendre exécutables. Tu devrais pouvoir faire ça en faisant un clic droit sur les programmes et en cherchant dans les propriétés. Sinon, en ligne de commande:

Code :
chmod +x appel_1.py

J'aurai pu faire une archive tgz qui conserve ces droits, mais les utilisateurs Windows auraient été embêtés (Ça marche aussi sous Windows, pour peu qu'on y installe Python3 et Pillow).
Répondre
#11
Allez voilà un chti paquet à essayer:

https://primtux.fr/appel-kimented_1.0_all.deb
Répondre
#12
Ah cool Smile ! C'est pratique pour essayer, mais pour vraiment utiliser (avec des photos de vrais élèves) ça ne marche pas. Il faudrait pouvoir charger des images depuis un dossier du répertoire utilisateur (ou écrire dans /usr/share/appel/eleves, mais ça nécessite les droits root).
Je peux essayer de modifier ça pour que ce soit mieux intégré, ou créer un petit outil de configuration pour paramétrer le logiciel et importer des photos.

PS: Je n'ai pas encore testé le .deb, j'ai pas de Primtux sous la main
Répondre
#13
Ben ça c'est dans l'appli que ça se passe... Le deb ne peut rien créer dans un home et tel que j'ai fait le paquet, même si c'est loin d'être conseillé, un user classique pourra y écrire, mais c'est tout ce que je peux faire à mon niveau, sauf à la limite si tu modifies le path des images élèves en le plaçant à /$HOME/eleves par exemple, là je peux entrainer la création du répertoire avec le .deb. Malgré tout subsistera l'écriture des fichiers dans le journal, et donc dans /usr/share.

Le paquet passe sur une ubuntu et une debian je pense.
Répondre
#14
Kimented :

Ce qu'il manque côté dev :

* Que les images proviennent de l'espace utilisateur.
J'aurais tendance à mettre dans /home/<user>/.config/apppel/eleves
(Je suis pas fan de /$HOME/eleves car rien n'interdit l'utilisateur d'avoir déjà du contenu à cet endroit... surtout que "eleves" me parait vraiment pas le nom de répertoire improbable)

e chemin via un fichier de config.

On peut néanmoins proposer un exemple quand le dossier est vide.

* Il faudrait un soft de démarrage qui permette à l'utilisateur de choisir entre les 4 types d'appel.

* Qu'un mini-outil permette de remplir le dossier.
Par exemple, un drag de l'image ou on saisie le nom dans la foulée, l'image est resizé à la volé. (ou message d'erreur quand elle est trop petite)

* appel_1.py appel_2.py appel_3.py ont tous le même soucis au lancement (pas le cas de appel_ecrit.py) :

Code :
'PosixPath' object has no attribute 'rfind'()

* un vrai nom. appel c'est pas un nom.

Je vais créer un dépôt Git une fois ce verrou tombé.

Ce qui manque ou ne vas pas niveau empaquetage :

- le postinstall avec un chmod 777 (ça marche sans changer de droits : selon l'emplacement, les droits unix sont bien gérés)
- l'executable doit être dans /usr/bin (et non /usr/share)
- il manque un descriptif dans le .desktop
- l'exec peut se faire comme ça (grâce au shebang) :
Code :
Exec=python3 /usr/share/appel/appel_1.py

Les évols possibles :

Stocker en base de données et par conséquent mémoriser les appels.
Par conséquent, avoir le récap des appels précédents.
Pouvoir répondre à des questions du genre :
- qui était absent lundi
- combien de fois Marius était-il absent depuis le début de l'année
etc.
Avoir les appels de plusieurs classes.

Alain : tu as sans doute des idées, tu peux compléter.
Répondre
#15
mothsart:
Oui c'est un peu ce que j'ai relevé comme problème. Pour moi c'était plus pratique d'avoir tout dans le même dossier Big Grin

Pour le bug que tu remontes il faut que j'investigue, parce que «chez moi ça marche» sous Linux Mint, Fedora et Windows. Ça dépend peut-être de la version de Python que tu utilises (3.6, 3.7 ?). Le bug est indiqué pour quelle ligne?

Question de débutant en Python: Pour le lanceur, est ce que vous savez comment faire en Python pour lancer un autre programme Python? Sinon, je crée des classe avec des noms différents pour chaque sous-programme que j'importe dans mon lanceur.
Répondre
#16
@mothsart => ce paquet est une base de départ, histoire de voir ce qu'on peut faire avec un .deb ou pas, donc le descriptif manquant dans le desktop et l'exécutable dans /usr/bin, ok c'est bon on sait, même si la commande du .desktop fonctionne très bien.
Le souci principal à mon niveau réside dans l'emplacement des répertoires qui vont être écrits. Il faudrait qu'ils soient créés avec le premier lancement de l'application dans le home de l'utilisateur, que les images et les logs du journal puissent être dans un répertoire du home aussi.
Je pense qu'une fois ces barrières passées son amélioration peut être envisagée.
Répondre
#17
Alors, le source est ici : https://framagit.org/mothsart/handsup

J'ai mis en place ce que j'ai dit. Soit :

1. J'ai nommé le projet "handsup" mais si quelqu'un a une meilleur idée, je changerais

2. quand on clone le dépôt et qu'on veut travailler en local, il suffit de lancer le fichier avec l'argument "--dev". ex :
Code :
./appel_ecrit.py --dev

3. quand le paquet est installé, il y a 4 exe créés (appel_1 appel_2 appel_3 et appel_ecrit)

On peut lancer ces exe directement dans un shell.
Si on passe par le desktop, ça lance appel_1

L'exe va chercher en premier dans /home/<user>/.config/handsup
Si le dossier n'existe pas, alors, il va chercher l'exemple fourni.

4. J'ai corrigé le bug signalé précédement

kimented a écrit :Question de débutant en Python: Pour le lanceur, est ce que vous savez comment faire en Python pour lancer un autre programme Python? Sinon, je crée des classe avec des noms différents pour chaque sous-programme que j'importe dans mon lanceur.

Peut-être que Tk a des process dédiés (je ne connais pas assez pour répondre).

Sinon, un simple :
Code :
os.system("lenomdetonsoft")

marche très bien.
Répondre
#18
J'ai oublié de dire que dans le readme, il y a ce qu'il faut pour générer son .deb
Répondre
#19
Bonjour
j'ai testé sous windows avec une collègue de maternelle et essayé plusieurs alternatives.

Finalement la collègue va s'orienter vers une animation scratch2 en plein écran où toutes les étiquettes de prénom d'élèves ou photos pour les ps seront rendues glissables et disposées en bas de l'écran, charge à eux de les bouger et les mettre dans la bonne zone d'écran école ou maison.
Il n'y aura pas de journal mais l'activité menée sur un tbi tactile avec des petits avec plusieurs etiquette visbles en même temps à l'écran a convaincu la collègue qui recherchait un outil très simple à la fois pour elle et pour les enfants et évolutif.
La possibilité d'adapter directement la taille des étiquettes noms ou des photos à l'activité grâce aux boutons de scratch, de pouvoir ajouter une consigne sonore et de sonoriser facilement les étiquettes noms ou photos est une des raisons pour lesquelles scratch a été retenu.
J'ai également présenté pylote ( en version portable et réduite qui date de plusieurs années et pour laquelle je n'ai pas eu à installer une autre version de python que celle préconisée par kimented) qui permettait de faire la même chose qu'avec scratch mais sans le son et sans reduction facile des photos (contrairement à scratch, il faut mettre les photos à l'échelle en dehors de pylote )

Mon outil générateur d'étiquettes virtuelles cf http://alain.botrel.free.fr (facile à utiliser si on utilise une souris ) n'était pas adapté à une manipulation au doigt ou au stylet sur tbi.
Je ne sais pas si ce genre de tbi est compatible avec linux ( j'essaierai une autre fois ) mais la tactibilité de l'écran est super intéressante à exploiter avec des petits.

Pour revenir au programme de kimented, sous windows j'ai essayé d'installer ensuite la version 2 de Pylote en rajoutant PYQT mais sans toucher au python 3.7 que j'avais installé pour appel , pylote n'a pas fonctionné alors qu'appel fonctionnait.

sous primtux (debian dg i686 ) j'ai installé le paquet de steph mais bien qu'un raccourci soit apparu dans le menu education cliquer ou double cliquer sur ce raccourci ne démarre rien
Avec le paquet de mothsart ( handsup ) les fichiers lanceurs comme appel_1 sont bien presents et démarrent une console mais c'est tout.
Vu mon expérience de non fonctionnement de pylote sous windows avec python 3.7, j'ai préféré ne pas aller plus loin et ne pas installer ce qui m'avait été conseillé par kimented car je tiens absolument à ce que pylote soit fonctionnel

Mothsart et Steph pouvez m'indiquer si dans votre installation pylote et appel fonctionnent.
Merci
Alain
Répondre
#20
Il semble que pylote2 utilise python3.
Sous Ubuntu 18.04 amd64 appel (mon deb) + pylote2 fonctionnent ensemble.
Répondre
#21
Alain a écrit :Avec le paquet de mothsart ( handsup ) les fichiers lanceurs comme appel_1 sont bien presents et démarrent une console mais c'est tout.

Tu peux me communiquer le message d'erreur quand tu lances appel_1 dans une console ? (sans doute une dépendance manquante)

Sinon, je confirme, pylote2 utilise python3 donc les 2 doivent marcher sur le même environnement.
Et même dans le cas contraire, sous linux des apps sous python 2 et 3 peuvent fonctionner en même temps... le seul probème que ça peut engendrer c'est que si on lance un soft python2 et un python3 simultanément ça lance 2 VM donc 2 fois plus mémoire utilisé. (pas top pour des villes bécanes ou des rpi)
Répondre
#22
Alain a écrit :Vu mon expérience de non fonctionnement de pylote sous windows avec python 3.7, j'ai préféré ne pas aller plus loin et ne pas installer ce qui m'avait été conseillé par kimented car je tiens absolument à ce que pylote soit fonctionnel

Si tu parles des install de python-tk et python-pil, tu peux y aller les yeux fermés, ça n'interfère en rien les deps de pylot qui sont autours de qt.

Ton soucis sur le deb "handsup" provient sans doute du manque de "python-tk" que j'ai oublié.
Je viens de mettre à jour : https://framagit.org/mothsart/handsup
Répondre
#23
kimented :
Ya plusieurs choses qui me dérange dans ton soft.
Le but n'est bien évidement de critiquer mais de transmettre mon expérience et améliorer la maintenance/évolution du soft.

1. Les 4 variantes sont à 80 % du copié/collé.
C'est pas pratique pour faire évoluer ton soft. A chaque modifs, faut penser à le faire 4 fois.
Le mieux dans ce cas (en python) est de faire de l'héritage.
Une classe parente qui fait les opérations identiques et des classes enfants qui font avoir les opérations spécifiques.

2. Les imports avec des "*". Deux soucis liés à ça :
- ça va charger en mémoire des choses inutiles.
- ça peut occasionner des conflits de nom.
Ex : from dep1 import * et from dep2 import *
Toutes les 2 ont la fonction "display"
python plante quand on fait un "display()" car il sait pas laquel utilisé.
Avec des imports strictes, tu t'en rends compte dès le début et surtout tu évites des comportements bizarres quand tu fais des upgrades de libs.
Imagine que "dep2" en version 1.0 n'a pas la fonction "display" et que la 1.1 l'a.
En changeant de la 1.0 à la 1.1, tu vas entrainer un bug.

3. Les ouvertures de fichiers se font avec "with".

4. Eviter les variables globales. Encapsulé dans une classe, c'est mieux.

5. Essayer de cloisoner dans des fichiers ce qu'il faut éviter de mélanger :
- l'accès à l'inteface graphique
- la conf
- l'accès
- les opérations de bases

6. Un versioning digne de ce nom

7. Y'a des print ,des commentaires et des lignes de code commenté un peu partout.
J'aurais tendance à afficher les print dans un mode debug.
Les commentaires sont pas toujours intéressants.
Par exemple : # Programme principal : devant if __name__ == '__main__':
C'est valable pour tous les softs python donc pas besoin de le préciser.
Le code commenté, faut éviter et plutôt s'intéresser à des outils comme git qui permettent d'avoir l'historique du code et le différentiel.
La, on sait pas trop pourquoi c'est là : un code qu'on a oublié de supprimé, un test, une fonctionnalité avorté etc.

Je propose une branche rapide (refactoring) pour rectifier le tir (premier jet, faudra que je fasse une repasse dessus donc sans doute des régressions):
https://framagit.org/mothsart/handsup/tree/refactoring

Ça supprime déjà presque 650 lignes de code redondant.

Un autre point que je risque d'aborder dans un second temps : mettre en place des tests. (le point 5 évoqué précédemment permettra également de mettre ça en place)
C'est vachement sécurisant pour du dev et j'essai désormais d'en mettre partout et dès que je commence un projet.
Répondre
#24
mothsart:
J'ai cloné le dépôt, et j'arrive à lancer les programmes avec l'option --dev tel que tu l'as indiqué. L'option --dev est une option de Python?
Vu que je n'ai pas d'expérience dans ce genre de chose, je ne sais pas comment travailler sur la version téléchargée de git (tout dans le même dossier) de telle façon qu'elle fonctionne également une fois packagée (installée dans le système) : il y a des choses à considérer?
Répondre
#25
kimented a écrit :J'ai cloné le dépôt, et j'arrive à lancer les programmes avec l'option --dev tel que tu l'as indiqué. L'option --dev est une option de Python?

Non, pas du tout. C'est une option que j'ai rajouté (il suffit de regarder le code : utilisation de "sys.arg") et en l'utilisant, ça contraint le soft à ne se baser que sur le dossier environnant.
En revanche, si tu enlèves cette option, le soft va chercher les images etc. dans les chemins propre à l'installation. (par ex : /usr/share/icons/hicolor/scalable/apps/handsup.png)
L'idée de travailler en mode "dev" est donc de t'éviter de te concentrer sur des soucis de chemins, de droits etc. (tu travailles sur les fonctionnalités et le déploiement est dissocié du code)

Dans le README.md, tu as le détail de "comment packager" et lancer le soft après ça.
Si tu veux savoir ou c'est installé, il suffit de se rendre dans le dossier "debian" (https://framagit.org/mothsart/handsup/bl...up.install principalement)
Répondre


Atteindre :


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