PrimTux, la distribution éducative

Version complète : Adaptation bureau administrateur pour utilisation d'un TBI
Vous consultez actuellement la version basse qualité d’un document. Voir la version complète avec le bon formatage.
Pages : 1 2
Bonjour,
Je poursuis mon adaptation pour l'utilisation en classe d'un TBI par les professeurs suivant les retours d'expérience utilisateurs

J'ai déjà soumis des deb concernant l'utilisation de partages spécifiques, la configuration pour l'utilisation de plusieurs écrans, et je suis entrain d'adapter le bureau pour une meilleure utilisation des crayons (pointeurs) optiques dans les menus du bureau (clavier virtuel, lancement d'applis, etc...)
(je publierai tout cela pour la version 4)

Pour cela je souhaite modifier certains fichiers de conf (dans .fluxbox .config) en créant un deb pour l'installation.

J'aurais besoin de connaître les procédures d'installation des dossiers de skel pour l'administrateur afin de pouvoir installer et desinstaller mes packages sans nuire à l'installation normale (de primtux4)

Donc de quel(s) package(s) dépendent ces fichiers de config , ou tout au moins comment sont-ils générés, sachant que ma procedure d'installlation après avoir ajouté/modifié les dossiers de squelettes fera une installations réversible dans les dossiers de config de l'utilisateur administrateur .


Merci de votre coopération
Disons qu'en théorie un .deb ne doit pas modifier les /home...
L'utilisateur est créé tout simplement juste avant lla compilation avec un

Code :
useradd --password oymab1U7DSUmg -m -k /etc/skel administrateur
Hello,

Sur le principe , j'ajoute un nouveau squellette dans le repertoire skel-tbi , puis dans la procédure postinst, je sauvegarde les fichiers existants dans le dossier de l'utilisateur (administrateur seulement) et installe les nouveaux fichiers de conf.
Je n'ai pas prévu la restauration des fichiers de conf sauvegarder....
C'est possible d'avoir un visu du deb que tu as fait ou que tu envisages ?
Comme ça, je serais d'avis d'avoir effectivement un script mais pas en postinst mais avec une action utilisateur après installation.
Je sais que c'est un peu moins user-friendly mais je vois dans ta proposition 2 transgressions à ce qui est attendu par un utilisateur Debian d'un paquet deb :
- la modification de fichiers de conf personnels
- un postinst sans un postrm : donc une fois que t'as installé le paquet, tu peux pas revenir en arrière

Pour le passage à la Primtux 4, on c'est lancé dans l'aventure d'un script de migration.
Je pense que ça nous a fait grandir et qu'il est désormais plus prudent,
si on veut envisager un futur de script de passage 4 à la 5 de faire les choses au goutte à goutte.

Même si, d'un certain côté on peut voir ta contribution comme un bugfix, c'est en réalité une feature.
De ce fait, il ne relève plus du cadre de Primtux 4 mais de son successeur.
Le proposer dès maintenant via une action utilisateur : pourquoi pas.
C'est limite un paquet qu'on pourrait qualifié de backports dans l'univers Debian/Ubuntu. (Ce qui veulent des fonctionnalités correspondants à la version suivante peuvent mais c'est à leur risque et péril)
Le proposer par défaut = nouvelle iso (donc suffisamment de modifs pour que l'effort en vaille la peine)
je t'envoie le lien en MP

donc install et suppression doivent fonctionnées
Bon, j'ai parcouru les sources de ce que tu proposes. Je ne peux malheureusement pas approuver :

En gros, ton deb va prendre tout un tas de fichier de conf et écraser ceux existants.
Je suppose que 90% ne servent à rien et risque de bousiller une config perso.

Il faut vraiment que tu identifies ce qui va changer et éditer les fichiers en conséquence.
Enfin, je suis toujours pas fan de l'édition de fichier de conf via un deb.
salut
je te disais que ma conf nécessitait des ajustements,
ce n'est pas "tout un tas" mais environ 5 fichiers qui sont touchés, quelqu'uns ajoutés qui n'ont aucune conséquence sur le retour a la conf de base

Je m'y étais mal pris pour identifier les modifs, à l'aide de git c'est nettement plus facile,
je m'y étais mal pris aussi sur la méthode de mes adaptations en raison d'une méconnaissance de traitement des panneaux ... ou mes talonnements avaient modifié tout un tas de fichiers sans pour cela être nécessaire à ma conf....

donc avec plus de doigté je reduis très nettement le nombre de modification

Je reste sur le principe d'un deb, trop compliqué d'éditer fichier après fichier, et pour le retour en arrière c'est pire, éventuellement dans le cas d'une conf personnelle déjà adaptée, je peux au lieu de récupérer les originaux du squelette, reprendre ceux de l'utilisateur que je sauvegarde lors de l'installation...

Mais pour l'instant je pars de la config d'installation de primtux et appliquerai mon deb sur les nouvelles machines (et il y en a beaucoup c'est la raison du deb)

Sinon j'ai remarqué qu'il y a plusieurs fichiers de conf de libreoffice qui sont sans cesse modifiés.... alors que je ne lance même pas libreoffice ????
qu'est-ce qui peut faire cela ??
Ben si tu travailles sur les sources en ce moment ça bouge.
Bon, ben je vois que ça te fais progresser.
On dit bien que la perfection est atteinte non pas quand il ne reste plus rien à ajouter mais plus rien à retrancher.

Ca se vérifie grandement en informatique : on passe bcp de temps à supprimer le superflus.

lebardix a écrit :trop compliqué d'éditer fichier après fichier...

Ca dépend.
Je vois que tu as utilisé Git.
Serais-t-il possible d'avoir accès aux sources ?
L'idéal serait d'avoir un commit avec les fichiers de conf avant modif et après comme ça on peut avoir un visu du diff et te donner des conseils plus précis voir contribuer.

Je précise qu'il est toujours mieux d'avoir les sources d'un paquet debian : c'est plus facile de comprendre comment c'est généré quand on voit les fichiers control, rules, *.install etc.

lebardix a écrit :...je peux au lieu de récupérer les originaux du squelette, reprendre ceux de l'utilisateur que je sauvegarde lors de l'installation...

Mon objectif n'est bien évidement ni de freiner ton entrain et ton entraide. J'en suis reconnaissant.
Néanmoins, inclure ce genre de paquet dans Primtux c'est en assumer la responsabilité.
On gagne actuellement en visibilité donc c'est important de soigner la qualité.
Dans l'absolu, multiplier des paquets "magiques" (édition de conf) c'est ouvrir la voie à pleins de scénarios de soucis isolés, difficiles à débugger, comprendre, corrigé, maintenir.
Si on se dit que seulement 10% (donnée complètement arbitraire qui doit sans doute être optimiste) de ceux qui ont le soucis franchissent le pas du forum.
Que sur ces 10%, la moitié va allé au bout (sans jeter l'éponge avec une image aigrie ou réinstallation complète) ça pose un réel soucis.

T'es-tu déjà renseigné si la modif de fichiers de conf dans /etc n'est pas suffisante (même partiellement) ?

Reprendre le fichier de conf de l'utilisateur plutôt que celui du squelette est sans doute mieux car il prend en compte les changements opérés jusqu'à l'installation du paquet.
Néanmoins, ça ne prend pas en compte les changements de conf entre l'installation et la suppression de ton paquet.
Steph a écrit :Ben si tu travailles sur les sources en ce moment ça bouge.

Je ne parle pas des sources .., j'ai remarqué, en utilisant un git local pour bien identifier les corrections pratiques à mettre en place pour l'utilisation d'un TBI,
que des (enfin 2 pour l'instant) fichiers de conf de libreoffice étaient modifiés environ1 fois par minute (dossier .config/libreoffice/4/user/uno_packages....gramon.oxt et esscol.oxt )

.. qui est l'origine de ces actions ...et pourquoi ? alors que je n'ai jamais encore ouvert libreoffice sur cette installation à neuf...
@mothsart

Dans ma commune nous installons 30 classes avec des TBI ....ET PRIMTUX... le portable est à la disposition de l'enseignant, il peut l'emmener chez lui,.
dans la classe il insère son portable dans une station d'accueil et retrouve pour piloter son TBI primtux.

6 classes sont en PTX3 et j'ai intégré quelques fonctions qui permettent de mieux piloter le bureau avec les stylets du TBI.
comme par exemple la sélection du mode d'affichage entre le TBI, un écran secondaire attaché à la station et l'écran du portable, l'utilisation d'une tablette sans fil, des menus supplémentaires pour lancer les outils insdispensables par exemple la capture d'écran, le clavier virtuel...

pour les 24 autres classes ... PTX4 sera donc la nouvelle version et donc je prépare l'adaptation de cette version à
- d'une part : porter les améliorations déjà réalisées à la demande des enseignants
- d'autre part : rétablir l'apparence correspondante à PTX3 (pour le prof seulement) - parce que les menus sur les cotés, la simplification du panneau bas ne sont pas utilisables dès que l'on a deux écrans en mode étendu (même en mode dupliqué avec openboard) .

Je pense que les profs doivent rester dans le cadre de Primtux pour leur TBI, parce que
- ils auront aussi/ainsi accès sur leur TBI à l'excellente offre de Primtux,
- ils pourront présenter aux enfants les applications qu'ils seront sensés utiliser sur les postes enfants

Donc pour l'instant je termine ce deb pour le dernier item ci-dessus de façon à pouvoir déployer ces PC,
j'ai un compte git et donc je proposerais une branche tbi avec les modifications réalisées et on décidera alors la meilleur option pour pouvoir proposer une "version tbi"

est-ce correct ?

Il me reste un grave problème pour l'utilisation du stylet TBI dans les applications "enfants" qui passent en mode plein écran .... en cours d'analyse....
Plutôt que déroger aux règles des .deb (interdiction d'écrire dans les /home/USER par exemple), pourquoi ne pas plutôt envisager un script qu'un paquet ?
+1
Ok, ok donc comment faire pour modifier par script la composition des panel (lxde et xfce) ??

en gros , je rajoute des launchers, change des paramètres (ex panneau de gauche xfce -> panneau horizontal masqué automatiquement )
les fichiers concernés sont
4 nouveaux launchers xfce
le fichier du panel gauche .config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml
le fichier du panel lxde .config/lxpanel/default/panels/panel
un fichier de fluxbox .fluxbox/init

une premiere solution serait la copie de ces fichiers par un script proposé à l'utilisateur dans un menu, faut redémarrer pour la prise en compte correcte

l'autre solution tjs par script volontaire, serait de rajouter les launcher, modifier les parametres ... je ne vois pas trop ...
Tout ce que tu peux faire avec un paquet peut se faire par un script. Je ne vois donc pas ce qui te pose problème: si tu sais comment faire dans un paquet, alors le script pourra le faire. Mais le script t'autorise des opérations qui ne sont normalement pas permise dans un .deb, comme modifier ou copier des fichiers des home.

Pour les panels, tu peux par exemple faire ta configuration type, et copier les fichiers ou dossiers de cette configuration dans une archive. Par sécurité, dans le script, tu prévois une sauvegarde des fichiers ou dossiers de l'utilisateur qui seront modifiés afin de lui permettre de revenir en arrière. Le script désarchive ensuite tes fichiers aux emplacements voulus.

Tu peux encore prévoir des messages d'avertissement du type: "ce script va modifier les tableaux de bord. Si vous les avez personnalisés, ces personnalisations seront perdues. Le script fera toutefois une sauvegarde de la configuration existante et vous permettra de revenir en arrière si vous le désirez. Voulez-vous continuer ?"

Idem pour la configuration de fluxbox.
+1
bonsoir,

bon voilà les scripts d'installation et de désinstallation sont réalisés et testés
l’installation du deb ajoute un script dans /usr/local/bin/primtux/install-tbi.sh

donc pour l'instant il faut executer depuis un shell root
Code :
pour installer
bash -C /usr/local/bin/primtux/install-tbi.sh install

pour retour à la configuration avant l'install
bash -C /usr/local/bin/primtux/install-tbi.sh remove

il est nécessaire de redémarrer pour prendre en compte les modifs ou aorès les avoir enlever...

maintenant je pense à traiter dans le package deb, les procédure d'installation/desinstallation
postins
bash -C /usr/local/bin/primtux/install-tbi.sh install

et prerm
bash -C /usr/local/bin/primtux/install-tbi.sh remove

est-ce correct ?

ou puis-je déposer le deb ?
Au niveau technique, c'est correct.

Maintenant au niveau respect des règles de construction des paquets Debian, comme ça lance automatiquement un script qui écrit dans les home, j'en suis moins sûr. Je laisse aux plus compétents que moi en la matière dire ce qu'ils en pensent.

Dans le cas où ça pose problème pour le paquet, qu'est-ce qui interdit de simplement proposer le téléchargement du script avec un readme sur la manière de l'utiliser ?

Pour la migration de PrimTux2 et 3 vers 4, c'est ce qu'on fait: https://framagit.org/philippe-dpt35/migre-ptx2-3
Comme déjà dis ici ou dans un message privé : Ok, pour un script. Pas d'accord pour un paquet debian qui touche aux confs utilisateurs.
Si Debian ne le fait pas, c'est pour des raisons très sérieuses :
1. La plupart des confs se font dans /etc et correspondent à l'ensemble des utilisateurs. Les confs utilisateurs, si elles existent vont être prioritaire sur celles de globales.
2. Si plusieurs paquets ont accès à la même conf, on se retrouve avec pleins de scénarios non prévus, non reproductibles, difficile à débugger etc.

Ca met peut-être en lumière un manque :

Un onglet de migration dans l'accueil ou l'administration avec un bouton qui lancerait une liste de scripts.
Autant créer un skel-tbi dédié avec toutes les conf qui vont bien. PrimTux n'est pas faite pour le double affichage, je ne suis donc pas pour intégrer cette fonctionnalité dans des applications existantes. Elle est faite pour les élèves. Maintenant si c'est pour bricoler ça fera pire que mieux. Un deb qui contient une application graphique dédiée pour créer un utilisateur spécialement pour tbi ça peut se concevoir, mais je n'ai pas eu accès à ces fameux scripts.
Même si
Steph a écrit :PrimTux n'est pas faite pour le double affichage
, il me semble intéressant d'utiliser le video projecteur en grand groupe pour expliquer aux élèves certaines situations.
Le fait d'avoir à débrancher le pc portable du video projecteur avant d'être sur une session, sous peine d'avoir des affichages fractionnés, ne favorise pas l'utilisation de primtux. En plus, il y a un risque d'abîmer les prises et la connectique...

Pour moi, le double affichage ne doit pas seulement concerner le bureau de l'administrateur mais bien toutes les sessions, y compris celle de maternelle.
Plus ce sera facile de gérer un double affichage, plus on aura de chances de voir se développer primtux en utilisation scolaire.
Ce serait bien que cela soit un fichier deb ou un ensemble de scripts s'installant en au maximum 2 clics et qui ne nécessite que peu de compétences linuxiennes.

Alain
L'installation d'un script de ne demande pas de grosses compétences.
On télécharge le script, un clic droit sur l'archive pour la décompresser.

Ensuite, s'il n'y a pas besoin d'être root il suffit de double-cliquer dessus pour avoir une boîte de dialogue proposant de le lancer.

S'il y a besoin d'être root, une ligne de commande à copier-coller suffit.

Dans le cas où il faudrait absolument passer par une interface graphique pour le lancer en root, il est encore possible d'utiliser yad ou zenity dans un script. ça permet de créer facilement des boites de dialogue graphiques.
Bonsoir,

Ma config est effective, pour l'instant un deb permet de déposer dans Primtux :
- les fichiers de config,
- le script d'installation,
- les scripts de commande.

l'ajout du paquet deb ne fait aucune modification dans l'espace utilisateur,
le script d'installation, s'il est exécuté, modifie l'environnement de l'utilisation tout en mémorisant l'état actuel
le script d'installation permet le retour à l'état précédent

Je suis entrain de rédiger la documentation complète sur le Wiki de debian-facile.org
https://debian-facile.org/atelier:chanti...ion-de-tbi

donc en chantier, mais le deb est téléchargeable
Alain a écrit :Même si
Steph a écrit :PrimTux n'est pas faite pour le double affichage
, il me semble intéressant d'utiliser le video projecteur en grand groupe pour expliquer aux élèves certaines situations.
Le fait d'avoir à débrancher le pc portable du video projecteur avant d'être sur une session, sous peine d'avoir des affichages fractionnés, ne favorise pas l'utilisation de primtux. En plus, il y a un risque d'abîmer les prises et la connectique...

Pour moi, le double affichage ne doit pas seulement concerner le bureau de l'administrateur mais bien toutes les sessions, y compris celle de maternelle.
Plus ce sera facile de gérer un double affichage, plus on aura de chances de voir se développer primtux en utilisation scolaire.
Ce serait bien que cela soit un fichier deb ou un ensemble de scripts s'installant en au maximum 2 clics et qui ne nécessite que peu de compétences linuxiennes.:!

Alain

Le bureau du maître n'est pas celui des élèves. Le PC branché aux TBI, VPI... est en général un PC moderne, assez puissant pour exécuter PrimTux dans une machine virtuelle (ce que je fais d'ailleurs pour les explications collectives), sous windows ou linux. Parlons des logiciels TBI: alors openboard ok, mais il n'y a pas photo avec smart notebook, faut pas se leurrer non plus, en plus les epson son fournis avec, les smart aussi.
PrimTux est beaucoup mieux que windows en poste élève et en tout point, mais pour les affichages collectifs (et je peux aussi évoquer les problèmes de drivers), il faudrait peut-être être lucide et pragmatique, linux ne fait pas le poids tant au niveau drivers que logiciels, ça ne ma fait pas plaisir plus qu'à vous mais c'est une évidence. Bien sûr qu'il faudrait que ça change, mais force est de constater que ce n'est pas encore ça. Donc, à mon sens, cette utilisation ne sert que quand on ne peut pas faire autrement.
Bonjour Steph

À l'utilisation, le démarrage du pc prof c'est, pour nous, moins de 30s depuis la pose de la machine sur la station d'accueil et l'affichage d'une page web (primtux.fr) sur le VPI (ou toute autre application éducative) - (je ne compte pas la saisie du mot de passe...)-

avec une machine plus puissante sous W$ et une machine virtuelle Primtux, dans le meilleur des cas tu dirais .... 2 à 4 minutes avec plus ou moins de manipulations .....?
Je ne parle pas des mises à jour et compagnie....

les drivers ne posent plus guère de problème. Je pense que tu es un peu défaitiste sur ce sujet.

De plus, le fait que ce soit aussi l'outil du professeur, sa prise en main de Primtux fera qu'il pourra mieux accompagner les enfants dans leur utilisation de Primtux (choix des exercices, conseils, etc...)

Ce que je présente n'est pas compliqué, quelques ajustement dans les "panel" pour une meilleure conduite avec le stylet , une commande simplifiée pour gérer les écrans, une solution de pilotage hors du pupitre ou du tableau... tout le reste c'est du bon Primtux. Tongue

et coté lucidité.... maintenance Y PAS Photo ....applications disponibles ça se discute autour des besoins et des coûts...

a plus tard
Pages : 1 2