Une place pour une véritable innovation. Partagez vos propres utilitaires créés avec la communauté Manjaro.
Questions et discussions sur la programmation et le codage.
Répondre

journald logs en javascript

#1Messageil y a 1 an

Depuis quelques jours, je me teste le framework electron. version 1.0 sortie au mois de mai de cette année, mais existe depuis un an.

un programme electron c'est en gros: un noyau chromium que l'on réutilise pour écrire son application (bureau ou web) avec le langage javascript.
Intérêt :
  • portable sur linux, win et osx
  • interface html donc simple
  • "facilement" re-distribuable en beaucoup de formats : aur, AppImage ...build --linux Appimage pacman --x64

beurk :
  • chaque programme et un (noyau) chromium donc gros surpoids
  • interface html donc pas top avec le style de notre bureau

Pour nous, en bureau, c'est sympa car indépendant de gtk ou kde et rapide à écrire car uniquement html+[css]+javascript

Pour mon premier test, je suis partis avec quelque chose de "facile", une interface graphique à journalctl

ImageImage

Le résultat est disponible dans AUR sys-journald-bin pour l'instant uniquement au format AppImage (42Mo :rigole: )

Tout premier jet, je découvre :rendre: le code source suivra lorsque j'aurais fait un peu de ménage et que le programme sera plus finalisé. Pour l'instant il me sert surtout d'excuse pour découvrir nodejs.

Utilisation (pour l'instant) :
* recherche 3 modes : programme(dbus), unité(dbus) ou path (/usr/bin/dbus-daemon) : pas les mêmes résultats à chaque mode !
* La date est utilisée uniquement si le boot n'est pas spécifié
* nombre limité à 1400
EDIT:
* thèmes
* dialogue pour tous les détails sur la ligne de log + dialogue détails sur l'unité
* dialogue pacman -Qi et -Ql a partir des messages de log
* recherche dans les man en HTML et ballade entre les mans avec des hyperliens

journald logs en javascript

#2Messageil y a 1 an

Je désire passer a l'étape suivante, le mettre la prochaine version sur AUR, mais problème :

Ces programmes à base d'électron sont gigantesques :cartonrouge: mais, c'est la mode du moment, de plus en plus sont proposés avec ce framework. A moi de trouver l'installation la moins mauvaise :saispas:

Il existe pour nous au moins 3 façons de le distribuer via aur, mais je ne sais pas trop quoi choisir :

1) proposer les sources en téléchargement : "que" 2Mo à télécharger, mais yaourt(makepkg) va devoir installer node et npm, installer les composants, compiler ... résultat yaourt télécharge plus de 60Mo et le temps de compilation est longgggg.

2) proposer les binaires classiques, 32Mo à télécharger, install "rapide" mais 127Mo une fois installé(décompacté) :choc: comme avec la version 1)

3) utiliser le format AppImage, 50Mo à télécharger, install "rapide" et "que :rigole: " 50Mo une fois installé
explication: Appimage est un exécutable compacté auto extractible (dans /tmp/.mountXXX ), le problème c'est qu'il demande donc plus de temps à chaque lancement ! ps: on décompacte quand même un chromium : bonjour la réactivité :clindoeil:

La 2) est la plus classique, téléchargement "pas trop énorme" et application rapide, malheureusement cette solution demande un espace disque impressionnant.

Mon cœur penche pour la 3), ce qui me semble un bon compromis ... La version 1) est pour moi (en temps que développeur) clairement la plus facile et rapide (pas de compilation en local ni d'upload du gros binaire)
Choisir la moins pire, quel bonheur !

journald logs en javascript

#3Messageil y a 1 an

:bjr:
Hem, pas simple. Je penche pour la 2 qui me semble plus propre ou du moins plus conventionnelle....Yaourt crée , compile dans /tmp et donc ça reste aisément nettoyable , ne serait-ce qu'en redémarrant.
Reste qu'il vaut mieux avoir de la ram!

journald logs en javascript

#4Messageil y a 1 an

les versions 2) et 3) sont les mêmes :
PAS de compilation, on télécharge directement le binaire (que je dois uploader), la seule différence c'est le format du binaire : 2) classique, 3) compressé auto-extractible

Pour la ram : 100 Mo dans /tmp/ c'est pas énorme, et même avec les 3 solutions on a en plus 2 fichiers *.asar qui eux aussi se décompressent a l’exécution, c'est inhérent au framework electron (application javascript/nodejs qui embarque chromium)

OUI, c'est pas génial electron, même nul: énormes applis pour pas grand chose, mais c'est la mode du moment : multi-os (win,linux,osx) et pas de dépendances puisque c'est en fait du html/javascript donc du point de vue des dev :aime: ...

mon PKGBUILD dans aur sys-journald-bin solution 3 : (ou autre sur aur)

prepare() {
    cd "${srcdir}"
    mkdir -p "${srcdir}/opt/${_pkgname}"
    7z x -y "${srcdir}/${_pkgname}-${pkgver}-${pkgrel}-x86_64.AppImage" usr/share/icons
    install -v -Dm755 "${_pkgname}-${pkgver}-${pkgrel}-x86_64.AppImage" "opt/${_pkgname}/${_pkgname}.AppImage"
    mv "${_pkgname}.desktop" "${srcdir}/opt/${_pkgname}/${_pkgname}.desktop"
}

package() {
    cd "${srcdir}/"
    cp -rp usr "${pkgdir}/usr"
    cp -rp opt "${pkgdir}/opt"
    mkdir -p "${pkgdir}/usr/bin/"
    ln -s /opt/${_pkgname}/${_pkgname}.AppImage ${pkgdir}/usr/bin/${_pkgname}   
}

solution 2:

package() {
  cd "${srcdir}/"
  rm -rf "${srcdir}/opt/${_pkgname}/resources/app.asar.unpacked/node_modules/electron-winstaller-fixed"
  mv -f "${_pkgname}.desktop" "${srcdir}/usr/share/applications/${_pkgname}.desktop"
  mv opt "${pkgdir}/"
  mv usr "${pkgdir}/"
 
  mkdir -p ${pkgdir}/usr/bin/
  ln -s /opt/${_pkgname}/${_pkgname} ${pkgdir}/usr/bin/${_pkgname}
}

solution 1) un exemple : utilisation de npm qui est aussi un gestionnaire de paquets (javascript)

Répondre