PrimtuxMenu : vers l'infini et au delà

[mothsart]

Je viens de mettre en place un indice du nombre d'application pour chaque rubrique dans le menu.
Ca m'a permis d'identifier et de corriger pas mal de bugs sur mes scripts et sur l'insertion de données.

Pour bien en tenir compte, j'invite à faire systématiquement :

Code :

git pull && make db.init

J'ai également supprimé primtuxmenu.db du dépôt car c'est une source de confusion. Vu que c'est généré et potentiellement différent selon le poste, ça n'a plus rien à faire dans les sources.

[mothsart]

Dans l'idéal, j'aurais souhaité que les applications web soient pleinement intégrés au PrimtuxMenu.
Je m'explique : actuellement, ça ouvre une nouvelle instance de Firefox (ou un onglet) et par conséquent ça demande un peu plus de gymnastique (pour les élèves, surtout) et le risque est que l'onglet du Primtuxmenu soit fermé.

Ce que j'aimerais : avoir l'applicatif encapsulé (<iframe>) dans le primtuxmenu avec une petite flèche (e haut à gauche) permettant de revenir au panneau principal de recherche.
Le soucis de cette opération : les balises <iframe> n'accepte pas les contenus locaux (soucis de sécurité).
Du coup, il faut faire passé le contenu par du nginx.

Je propose de faire déjà un test avec un applicatif : mon éditeur de svg (que je connais bien et qui est utilisé côté prof donc moins critique).
Je vais créer le fichier de règle nginx et un fichier debian d'alias (pour que les données statiques soient présente dans un dossier du genre /var/html/primtux/editinteractivesvg)
Une fois que le test sera satisfaisant, il sera sans doute possible de réfléchir à migrer ces règles pour d'autres apps.

Je conçois que c'est encore un effort important et rébarbatif mais pour l'instant, je n'ai pas de solution plus simple qui me viennent en tête. (il doit peut-être exister une config Firefox qui permette de visualiser des contenus locaux dans une <iframe>)
Après, rien n'interdit de faire progressivement.
Qu'en pensez-vous ?

[Philippe Dpt35]

On va perdre en espace d'affichage pour les applications, ce qui est très ennuyeux pour la plupart des applications.
J'aurais notamment bien aimé trouver une solution d'affichage plein écran automatique au lancement des applications pour gagner en espace d'affichage.
Je pense qu'il serait préférable d'ouvrir non pas un nouvel onglet, mais une nouvelle instance. Pour les applications non Web, c'est ce qui se passe, l'ouverture d'une nouvelle fenêtre.

Sinon, j'ai enfin réussi ce matin à faire fonctionner le primtuxmenu par l'intermédiaire de Nginx, y compris dans un environnement non virtuel. Le fonctionnement en réseau est OK.

Je refais un dernier test sur une installation vierge pour m'assurer que tout est OK, et je détaille la procédure dans un prochain post.

[Philippe Dpt35]

Voici la procédure pour faire passer primtuxmenu par nginx.

Pré-requis
Installation de Nginx

Code :

sudo apt install nginx

Installation des paquets Python nécessaires

Code :

sudo apt install python3-pip python3-dev build-essential libssl-dev libffi-dev python3-setuptools

Installation des dépendances primtuxmenu et de composants python nécessaires

Code :

sudo apt install python3-flask python3-apt
sudo pip3 install wheel uvicorn quart

Procédure pour primtuxmenu

Dans le dossier de primtuxmenu
Initialisation

Code :

make db.init

Le nom des fichiers et répertoires pourra être adapté
Le N° de port (ici 5500) peut être changé

Placer les fichiers du dossier static de l'application dans le dossier
/var/www/html/primtuxmenu

Code :

sudo mkdir /var/www/html/primtuxmenu
sudo cp -R ./static/* /var/www/html/primtuxmenu

Créer le fichier

Code :

sudo nano /etc/nginx/sites-available/pmenuconf

avec le contenu

Code :

server {
    listen 5500;
    location / {
      proxy_set_header Host $http_host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_redirect off;
      proxy_buffering off;
      proxy_pass http://uvicorn;
    }
   location /static {
      include  /etc/nginx/mime.types;
      # path for static files
      alias /var/www/html/primtuxmenu;
    }
}
  upstream uvicorn {
    server unix:/tmp/uvicorn.sock;
  }

Créer le lien symbolique

Code :

sudo ln -s /etc/nginx/sites-available/pmenuconf /etc/nginx/sites-enabled

Relancer Nginx par

Code :

sudo service nginx reload

Lancer l'application par la commande

Code :

uvicorn primtuxmenu:app --uds /tmp/uvicorn.sock

[mothsart]

Je comprend ton point de vue, Philippe sur l'espace d'affichage.

A celà, on pourrait envisager un menu qui ne s'affiche que temporairement et disparait. Dès qu'on s'approche du coin en haut à gauche, il réapparait.

Pour ce qui est du plein écran, c'est une bonne idée mais sans doute pas pour tout.
Pour les applis enfants, c'est sans doute la meilleur expérience utilisateur donc je serais favorable.
Néanmoins, il faut pensé à la sortie : bouton "quitter" parce qu'ils ne sont pas forcément sensibilisé aux raccourcis [F11] ou [Echap].

Ca peut se faire : https://developer.mozilla.org/fr/docs/We...creen_mode

Par contre, pour des applis tel que l'éditeur de SVG, c'est une mauvaise idée : on commence par glisser une image donc ça oblige à sortir du plein écran...

Si l'on envisage donc le plein écran pour tous les applis "clicmenu" et qu'on étende ça à d'autres (Prammatice, Aleccord, JClic etc.), on va éviter le fichier de conf nginx et l'alias mais pas l'ajout d'un composant (html/script/css) dédié.
Ca veut quand même dire rajouter ça et refaire les .deb de chaque... pas anodin.

Je pense qu'il serait préférable d'ouvrir non pas un nouvel onglet, mais une nouvelle instance. Pour les applications non Web, c'est ce qui se passe, l'ouverture d'une nouvelle fenêtre.

ca à l'air d'être possible : https://stackoverflow.com/questions/1293...ow-not-tab
Après, est-ce que c'est souhaitable... pour des applis hors web la question ne se pose pas.

On va attendre l'avis de Steph (voir d'autres) sur la question.

Un grand merci sur le process, Philippe, c'est top !

[mothsart]

quelques news :

J'avance toujours sur l'ajout/modification/suppression d'application.
Les grandes lignes sont posées et il est désormais possible de tester ce type de fonctionnalité.
C'est néanmoins loin d'être abouti et ça nécessite encore une paire d'ajustements/correctifs avant d'être pleinement utilisable.

[Steph]

Pour la 6 est-ce qu'on retarde ou est-ce qu'on fait une 6 avec les handymenus?

[mothsart]

Si tout le reste est prêt pour une v6, je partirais sur une version 6 livré dans les temps en gardant les handymenus.
D'une part, ça évitera de ce concentrer sur des correctifs de la distrib et du primtuxmenu.
Actuellement, je suis incapable de dire combien de temps il reste et quel dispo je vais avoir...

Rien n'interdit, à mon sens de faire un béta dans quelques mois et de communiquer dessus voir de sortir une 6.5 (ou 7) en cours d'année et de la peaufiner.
De même, il sera sans doute possible de dev un script pour que les possesseur de la v6 bascule sur le primtuxmenu.

Ce n'est que mon avis mais je trouve qu'il est important de garder des dates de livraison fixe. Plein de distros le fond (comme Ubuntu) : ça fidélise, ça montre que le projet reste actif et ça permet de communiquer périodiquement.
Ubuntu a souvent reporté des évolutions par manque de maturité. C'est pas grave : on privilégie la stabilité !

[mothsart]

Pour répondre à la demande de @guillaume, j'ai créé des tickets pour le PrimtuxMenu : https://framagit.org/mothsart/primtuxmenu/-/issues
avec des labels (tag) pour bien identifier/filtrer les devs à réaliser.
Du coup, on peut regarder les taches restantes pour la 0.1 (première version déployable) et également filtrer en fonction des compétences requise :

- frontend : aspect web côté navigateur (html/css/js) : des personnes tel que @Philippe pourrait intervenir
- backend : partie serveur en python et base de donnée
- intégration : paramétrage de nginx, systemd, création de paquet .deb
- contenu : maj de contenu via l'applicatif, normalement à la porté de tous

[mothsart]

Après pas mal d'absence, je me suis remis à dev sur le primtuxmenu.

1. Je suis pas loin de terminer https://framagit.org/mothsart/primtuxmenu/-/issues/6 : il manque la partie upload d'image, un descriptif avec de la mise en forme (graisse, italic, ajout de liens etc.) et sans doute un bon tour d'horizon de tests et correctifs.

Y'aura pas encore la possibilité d'éditer les menus (planifié là : https://framagit.org/mothsart/primtuxmenu/-/issues/13) mais ça me parait pas trop handicapant pour démarrer.

2. Pour https://framagit.org/mothsart/primtuxmenu/-/issues/14, j'ai fait plusieurs petites passes pour améliorer les choses.
C'est sans doute pas parfait mais ça se bonifie.

3. https://framagit.org/mothsart/primtuxmenu/-/issues/17 : j'étais embêté sur cet aspect mais j'ai désormais les grandes lignes en tête : un daemon dédié à ça piloté par systemd.
Y'a encore du taf mais c'est en bonne voie.

4. https://framagit.org/mothsart/primtuxmenu/-/issues/4 : Phillipe m'a déjà bien dégrossi le terrain.

5. Paquet debian https://framagit.org/mothsart/primtuxmenu/-/issues/1 : ça, une fois que tous le reste est opérationnel, ça ne devrait pas prendre long

J'essai de m'imposer un commit (même si c'est juste de la cosmétique) par jour et 3,4 heures par week-end mini pour venir à bout d'une version 0.1 d'ici 1 mois.

Une fois cette version finalisé, il sera possible de faire des tests via l'installation du paquet deb.
Sans doute qu'une 0.1.1 (avec les correctifs liés à vos remontés de bugs) pourra être utilisable.
Ca sera sans doute trop tard de "remplacer" les handymenus par le primtuxmenu pour la v7 mais on pourrait envisager dans les mois qui viennent un script de migration pour les plus aventurier.

[Steph]

Merci Jérémie! Je vais regarder comment ça fonctionne, et je verrai comment je peux participer, déjà pour la liste des applis...

[mothsart]

Point d'avancement : Bon, on était au final loin du compte pour https://framagit.org/mothsart/primtuxmenu/-/issues/6 :lol:
J'en ai profité pour améliorer par petites touches le visuel.
A force de persévérance, je pense être parvenu à une solution acceptable et utilisable.

Je ne suis pas dans les temps mais je commence néanmoins à être satisfait du travail réalisé.


Prochaine étape qui devrait m'occuper encore un peu : https://framagit.org/mothsart/primtuxmenu/-/issues/17

[Steph]

stephane@stephane:~/Téléchargements/primtuxmenu-master$ make server.run
make: *** Aucune règle pour fabriquer la cible « server.run ». Arrêt.

?

[mothsart]

Ah, le boulet :

J'ai mis server.run au lieu de run.sever dans le README.

[Steph]

Là ça marche et c'est pas mal! Mais quand je clique sur une appli elle ne se lance pas on propose l'édition.

[mothsart]

Bon, cool que ça plaise.

Effectivement, j'ai quelques soucis de gestion de session lié à la détection édition ou lecture.
Je vais essayé de corriger ça rapidement.

[mothsart]

Une petite note pour dire que je vais repartir sur des sessions d'améliorations/correctifs/stabilisation après de longs mois d'inactivité. Je vous tiens au courant quand j'estime que mes travaux sont suffisamment aboutis pour se re-pencher dessus.

[mothsart]

Bon, ça commence à être réellement satisfaisant : pas mal de de bugs résolus, quelques ajustements visuels etc.
Flask 2 étant désormais sorti, il n'y a plus d'utilité à utiliser Quart.
J'ai fait le nécessaire pour le passage sur ce nouveau framework.
Voici ce qu'il reste à faire https://framagit.org/mothsart/primtuxmen...name[]=0.1

[Steph]

Je vois que tu avances, si besoin de tests n'hésite pas, c'est tout ce que je peux faire parce que côté développement je sis un peu largué en lisant les issues!

[mothsart]

Je vais faire ça dans un premier temps : https://framagit.org/mothsart/primtuxmenu/-/issues/22
L'idée c'est d'avoir une couverture d'imprim écrans (qui permettra aussi de présenter le soft sans effort) qui devraient déjà valider que les principales fonctionnalités soient là.

Dans un second temps, je pense que https://framagit.org/mothsart/primtuxmenu/-/issues/8 serait possible à ton niveau.
L'idée c'est :
1. éditer les applications avec des vrais données via l'IHM.

2. créer une branche dédié pour ta modif

Code :

git checkout -b data/leNomUniqueDeLABranche

3. sauvegarder dans un fichier tes modifications pour les conserver dans git : 

Code :

make db.record

4. Donner un descriptif le plus précis possible de tes changements

Code :

git commit -m "la description des changements"

5. Envoyer sur le serveur

Code :

git push

6. faire une demande de fusion (Pull Request en anglais)

[mothsart]

Voilà, j'ai mis en place une liste (non exhaustive) de screenshots de l'applicatif automatisés avec Cypress :
https://framagit.org/mothsart/primtuxmen...le_spec.js

Celle-ci est un essai d'affichage (c'est du fake, la mécanique derrière est pas encore stable) de la partie "store" : on voit l'évolution en temps réel de l'avancement des installations des softs https://framagit.org/mothsart/primtuxmen...lation.png

Est-ce que ça vous semble pratique/cohérent ?

[Steph]

On ne peut pas avoir le tout sans le menu déroulant des notions? Un peu comme le handymenu mais à gauche...

[mothsart]

Je suis pas sur de comprendre : tu ne veux pas de menu déroulant des notions dans la session prof ?
Pour avoir quelque chose qui ressemble à https://primtux.fr/wp-content/uploads/20...-17-10.png

[Steph]

Si session prof c'est pas gênant, c'est là en fait:

https://framagit.org/mothsart/primtuxmen...20menu.png

Peut-on avoir le tout déroulé sous forme d'onglets à gauche?

[mothsart]

C'est bien entendu "possible" mais j'ai du mal à comprendre l'intérêt.
Parce que la navigation sera plus simple pour les enfants avec des onglets ?
Je vais te faire un imprim écran rapide pour validation