A la deuxième tentative, sans cette clef USB, l'installation se poursuit et s'achève normalement.
MATE est un bureau séduisant. Depuis Ubuntu 15.04 (Vivid Vervet), il existe une variante officielle de Ubuntu déclinée avec le bureau MATE. La version 18.04 bénéficie donc d'un peu de recul. Cette page rend compte d'un petit essai en vue d'évaluer la possibilité de l'utiliser comme distribution principale de travail.
La machine de test utilisée est un ordinateur GrosBill, 64 bits mais ancien et d'entrée de gamme (un First GB3T135 de 2008). Peu performante, elle dispose quand même de l'UEFI et fonctionne de manière satisfaisante. Elle est utile pour tester des installations diverses et variées.
Ubuntu Mate 18.04 va y être installée à la place d'une 16.04 installée antérieurement, à côté d'une distribution SUSE déjà présente sur le disque.
Lancée à partir d'une session live sur une clef USB, l'installation se déroule comme d'habitude, en récupérant les partitions déjà créées. Elle prend une quinzaine de minutes mais rencontre quelques écueils :
Au cours de l'installation, par erreur, l'utilisateur a choisi la disposition de clavier "Français - Français (variante,
sans touche morte)".
Du coup, la frappe de la touche [^] (à droite de [P]) suivie de la frappe de [e] écrivait ^e au lieu de ê.
Pour corriger cette erreur, actionner le menu "Système > Préférences > matériel > Clavier".
Ceci ouvre une boîte de dialogue "Propriétés du clavier" dont l'onglet "Agencements" permet d'ajouter la disposition souhaitée :
puis d'enlever la disposition erronée :
La disposition "variante" donne un clavier azerty étendu qui permet, notamment, d'écrire œ en tapant [AltGr][o].
Malheureusement, ce changement n'est pas effectif immédiatement. En particulier, il ne suffit pas de sélectionner le nouveau clavier dans la liste pour "tester les réglages", comme le laisse croire abusivement le champ inférieur de la boîte de dialogue.
Au démarrage suivant, le changement est appliqué et persistant.
Au premier lancement, Firefox (Quantum 65.0) se plante. Une réinstallation par "Système > Administration > Software Boutique" lui permet de se lancer mais en anglais. L'installation n'a pas mis en place complètement les fichiers de traduction. Par le menu "Système > préférences > Personnel > prise en charge des langues", tous les paquets manquant s'installent, cette fois c'est bon.
Toutefois, alors que le dossier /home a bien été conservé dans une partition spécifique (et non re-formatée!), les onglets de Firefox se retrouvent de nouveau au-dessus de la barre d'adresse. Vérification faite, pourtant, le fichier userChrome.css, qui gère la présentation du navigateur, est bien à sa place. Une recherche sur internet semble indiquer que des changements ont eu lieu dans la prise en charge de cette fonction. Sur support.mozilla.org, une discussion affiche un contenu beaucoup plus développé que celui antérieurement utilisé. Le fait de placer ce fichier userChrome.css dans le dossier caché chrome du profil (faire [Ctrl][h] dans "Dossier personnel" pour afficher ou créer .mozilla/firefox/[suite2car].default/chrome) puis de relancer Firefox remet la barre d'onglets à la "bonne" place, juste au-dessus du contenu de l'onglet. Cela fait relativement beaucoup de code css pour ce seul petit résultat ; il n'est pas sûr que tout soit indispensable... - un petit sujet d'étude pour plus tard.
Le gestionnaire de paquets Synaptic, tout-à-fait indispensable pour l'auteur, n'est pas installé par défaut. Il s'installe facilement à partir de la "Software Boutique".
Après l'installation, un clic droit sur le dossier "Public" dans le gestionnaire de fichiers (caja) ne propose pas le choix "Options de partage" qui, normalement, permet de partager un dossier. Pour obtenir cette fonction, il faut installer le paquet caja-share qui ajoute des fonctionnalités supplémentaires au gestionnaire de fichiers Caja. Ce paquet utilise Samba (d'après la description de son paquet (visible dans Synaptic),"Samba est une mise en œuvre du protocole SMB/CIFS pour les systèmes Unix, fournissant une interopérabilité de partage de fichiers et d'imprimantes entre Microsoft Windows, OS X et les systèmes basés sur UNIX"). Il faut donc installer le paquet samba et, tant qu'on y est, on installe aussi smbclient et cifs-utils, qui sont des outils complémentaires permettant d'effectuer et de gérer le partage des fichiers en réseau.
Malgré cela, le partage en réseau ne fonctionne pas. Après un peu de recherche, il s'avère qu'il faut encore installer le paquet system-config-samba, qui, d'après sa description est "une interface utilisateur graphique pour créer, modifier et supprimer des partages et des utilisateurs Samba".
Une fois installée, cette application apparaît dans le menu "Système > Administration > Samba".
Toutefois, comme indiqué par sa documentation, son lancement est affecté par deux erreurs mineures.
Ouf, maintenant, system-config-samba se lance et ouvre la fenêtre qui permet de créer et rendre opérationnel le partage :
Cela fait, il faut donner au dossier les droits de lecture et écriture voulus. Ici, s'agissant du dossier Public, il est ouvert à
tout le monde en lecture et écriture.
Et ça marche, le dossier est utilisable par les autres ordinateurs du réseau, à l'aide du protocole smb, avec son adresse composée du
nom de l'ordinateur et du nom du dossier (qu'il est possible de vérifier avec le moniteur système).
Vérification du nom dans le moniteur système
Vue du dossier Public depuis un autre ordinateur du réseau.
Cela pourrait être plus simple mais on y arrive.
L'excellent programme GNU de manipulation d'images GIMP n'est pas installé par défaut dans Ubuntu depuis quelques distributions (jugé trop spécialisé?). Bien sûr il est dans les dépôts d'où il peut s'installer en deux clics dans Synaptic. Cependant, pour Bionic, il y figure en version 2.8 alors que la 2.10 vient de sortir. L'auteur de cette page souhaitant tester la pérennité des scripts qu'il a écrits en script-fu et python, c'est la dernière version qu'il désire.
GIMP 2.10 peut être installé en utilisant des méthodes "récentes" (avec SNAP ou avec flatpak) mais l'auteur préfère utiliser la méthode classique et éprouvée utilisant Synaptic :
Voilà, c'est fait.
Les scripts en Scheme sont dans /home/[USER]/.config/GIMP/2.10/scripts où [USER] est à remplacer par le nom d'utilisateur.
Les scripts en Scheme fonctionnent directement à une remarque près : il semble que l'interpréteur TinyScheme comporte un bogue
sur l'affichage des nombres. La fonction number->string ajoute ".0" au nombre sorti. Par exemple, au 5 février 2019,
à la console, (number->string (log 10)) produit "2,302585093.0" :
La fonction suivante permet de contourner cette erreur.
(define (nombrenchaine
R ; reel en entree
)
(let* ( ; initialisation des variables locales
(chainedonnee (number->string R))
(fin2chainedonnee (substring chainedonnee (- (string-length chainedonnee) 2) (string-length chainedonnee)))
(deb2chainedonnee (substring chainedonnee 0 (- (string-length chainedonnee) 2) ))
(chaineretour "")
) ; fin de l'initialisation des variables locales
(if (string=? fin2chainedonnee ".0") ; si number-string R produit une chaine se finissant par .0
(set! chaineretour deb2chainedonnee) ; alors on ne retient que le debut de cette chaine sans .0
(set! chaineretour chainedonnee) ; sinon on la retient entierement
)
) ; fin du let* de nombrenchaine
Cette fonction supprime la sous-chaine caudale ".0", si elle existe. Pour contourner le bogue, remplacer les number->string du programme par nombrenchaine. Cette solution n'est pas très satisfaisante mais elle permettra d'attendre la correction du bogue.
Les scripts en Python sont dans /home/[USER]/.config/GIMP/2.10/plug-ins où [USER] est à remplacer par le nom d'utilisateur.
La version GIMP 2.6 (version de travail actuelle) est dans un environnement disposant de Python 2.7.6. Pour la version GIMP 2.10 en cours de test, c'est 2.7.15rc1 qui est installée. S'agissant de la même version "2.7", il ne devrait pas y avoir trop de différence. Néanmoins, il y a quand même eu une intervention à effectuer.
L'un des scripts tentait d'optimiser le calcul d'une transformation en utilisant des tuiles. Sous GIMP 2.6, ce script comportait une maladresse de codage : la taille des tuiles (64px) était inscrite "en dur" dans le code ; par exemple :
tn = int(layer.width / 64)
Cette maladresse était tolérée par GIMP 2.6 qui s'exécutait sans s'énerver. Sous GIMP 2.10, elle provoque un plantage du script.
Elle a été corrigée sur les indications de Massimo Valentini (merci à lui). Il faut remplacer la ligne incorrecte précédente par :
tn = int(layer.width / gimp.tile_width() )
et la même chose pour la hauteur avec gimp.tile_height(). Ce seul changement permet au script de fonctionner sous GIMP 2.10 (bien qu'il produise au terminal un avertissement critique "(Gimp-Core-CRITIQUE: gimp_drawable_merge_shadow_buffer: assertion 'GEGL_IS_BUFFER (drawable->private->shadow)' failed" non élucidé pour l'instant).
Les autres scripts ont fonctionné sans modification, y compris le modèle de script utilisant une interface gtk élaborée avec glade : modele-python-fu-gtk.tar.gz.
Si vous avez plusieurs ordinateurs avec des versions de GIMP différentes, vous ne pourrez a priori pas lire les fichiers XCF créés par GIMP 2.10 avec les versions plus anciennes.
Le format natif de GIMP (XCF pour eXperimental Computing Facility [université de Berkeley]) est un format évolutif. Il a été notamment étendu pour incorporer les nouvelles fonctionnalités apportées par GIMP 2.10. Du coup, si GIMP 2.10 sait bien ouvrir les fichiers créés avec des versions plus anciennes, l'inverse n'est pas vrai. Par exemple, la tentative d'ouverture d'un fichier enregistré par GIMP 2.10 avec GIMP 2.6 produit le message d'erreur :
GIMP Erreur
L'ouverture de « 130308_tas2bois_1280x1024-NEW_XCF.xcf » a échoué : Erreur XCF : la version 11 du format XCF non prise en charge.
Et GIMP 2.10 NE propose PAS d'option du type "Enregistrer sous l'ancienne version XCF".
Cependant, au moment d'enregistrer, la boîte de dialogue fait savoir si l'image en cours utilise ou non des fonctionnalités
nouvelles de GIMP 2.10 et donc si le fichier XCF sera incompatible ou non avec les anciennes versions de GIMP.
Cliquer sur le ⊞ qui précède ce message le transforme en ⊟ et développe le message pour indiquer quelles caractéristiques de l'image vont
engendrer un fichier illisible par les anciennes versions de GIMP :
Dans l'exemple illustré par l'image précédente, GIMP signale que l'image utilise le mode de calque "Normal" ajouté dans GIMP 2.10. Bien sûr, le mode "Normal" existait avant GIMP 2.10 mais il a dû être ré-écrit dans le nouvel environnement d'une manière incompréhensible par les versions plus anciennes.
Si l'image n'utilise pas de telles nouveautés, alors le message n'est pas présent dans la boite de dialogue et le fichier produit sera
lisible par les anciennes versions ; par exemple :
Toutefois, ce cas de rétrocompatibilité restera exceptionnel (et sans doute voué à disparaître) car, d'après le registre des nouveautés de GIMP 2.10, il y a eu des changements significatifs affectant le format de fichiers, notamment :
Il faut donc prendre ses dispositions en conséquence.
Les étapes suivies pour installer ce scanner performant furent :
sudo cp /usr/lib/sane/libsane-epkowa.* /usr/lib/x86_64-linux-gnu/sane/
EDIT (12/05/2019) : au lieu d'en faire une copie, il est plus satisfaisant de créer un lien symbolique vers les fichiers epkowa parsudo ln -sfr /usr/lib/sane/libsane-epkowa* /usr/lib/x86_64-linux-gnu/sane
#chmod device EPSON group
ATTRS{manufacturer}=="EPSON", DRIVERS=="usb", SUBSYSTEMS=="usb",
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="*", MODE="0777"
Ensuite, allumer le scanner, le brancher sur un port USB et lancer l'utilitaire de numérisation : Applications > Graphisme > Image Scan! for Linux ou Simple Scan.
Normalement, Digikam est un logiciel pour KDE mais il n'a pas son pareil comme outil de gestion de flux et, surtout, qui sache non seulement maintenir une base de données relatives aux images mais aussi inscrire dans les fichiers des photos les métadonnées définies par l'utilisateur.
Auparavant, son installation obligeait à importer de nombreuses bibliothèques de KDE et, du coup, à créer un système quelque peu incohérent. Depuis la version 5.3.0, sortie le 7 novembre 2016, Digikam est disponible sous la forme d'un exécutable appimage. Ce fichier est autonome c'est-à-dire qu'il contient toutes les dépendances dont il a besoin. Certes, il n'y a pas de miracle, du coup, son volume est important. À l'heure où cette page est écrite, la version disponible est digikam-6.0.0-x86-64.appimage, qui pèse environ 408 Mio.
Au premier abord, la nouvelle version 6.0 fournie sous cette forme fonctionne bien sous Ubuntu-Mate Bionic.
La première nouveauté remarquée est qu'il est possible de définir une application par défaut autre que l'éditeur de photos inclus pour ouvrir les photographies et de la lancer avec un raccourci spécifique ([META][F4]). La photo sélectionnée peut ainsi être ouverte rapidement dans GIMP 2.10. C'est un confort appréciable qui manquait cruellement à la version 4. Après édition dans GIMP 2.10, digikam récupère le résultat en retrouvant bien les métadonnées apparemment bien traitées par GIMP 2.10 et, semble-t-il, avec une plus grande stabilité que la version 4.14 précédemment utilisée par l'auteur de cette page. Celle-ci avait en effet une fâcheuse tendance à planter au retour de GIMP. Ceci reste à vérifier dans la durée.
Cette version de la nuance Ubuntu-mate n'installe pas par défaut le paquet printer-driver-cups-pdf nécessaire à l'installation d'une imprimante virtuelle produisant des fichiers PDF. Plus de détail ici
