Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Extension Nautilus pour créer des lanceurs

Roschan

Puisque j'ai l'impression que la création de fichiers .desktop est l'un des points les plus nuls de Nautilus, j'ai essayé de faire une extension pour Nautilus qui corrige un peu ce défaut : la voilà, si ça intéresse quelqu'un. Je serais en retour intéressé de savoir quel champ vous semble manquant (le but n'est pas d'être exhaustif ni de concurrencer MenuLibre, je me limite aux champs très courants, mais je n'ai certainement pas les mêmes que tout le monde)

bluc

Genial ton truc
Je viens de faire un lanceur pour Molotov , mais si je renseigne le champs Catégorie le lanceur ne se créé pas
et contrairement a une autre discussion le lanceur apparaît dans les Applis fréquemment utilisées , je n'ai pas mis de catégorie

Merci

Roschan

le champ catégories est un peu subtil, il faut un ; après chaque catégorie renseignée, et pas d'espace, c'est clairement un point à améliorer (quand tu dis qu'il ne se crée pas, c'est qu'il n'apparaît pas dans la grille, ou que le fichier n'existe carrément pas ?)

bluc

Je viens d'en recréer un autre et là ça fonctionne pas de probleme ..même en mettant catégorie
par contre la fenêtre de recherche de l'icone ne se ferme qu'avec le clic droit sur la barre de fenêtre mais pas ni par "Sectionner" ou "Annuler"et l'icone choisie n’apparaît pas sur la fenêtre de création du lanceur , pourtant le lanceur a bien l'icone

#!/usr/bin/env xdg-open
[Desktop Entry]
Name=Etcher
Comment=live-usb
Type=Application
Exec="/home/luc/.etcher-1.3.1-x86_64.AppImage"
Categories=Divers
Icon=/home/luc/Images/avatars logos/Etcher.png

En tous cas c'est pratique

Roschan

Pour les catégories, le mystère restera donc entier, mais pour les images, je pense comprendre où est le bug (je charge directement les images, sans les redimensionner, je pense que GTK n'aime pas trop), je tenterai de le reproduire (et de le corriger, bien sûr)

bluc

Plus de probleme avec les icônes

Roschan

normal j'ai carrément empêché qu'elle s'affichent quand c'est chargé depuis une image :p

kevlar

Bonsoir Roschan.
Merci pour ton travail. Je n'utilise pas Nautilus, n'étant pas sous Gnome, mais utilisant un LXDE plutôt modifié, ce qui me permet de te confirmer que ton extension fonctionne bien, même en dehors de Gnome ; bravo : par exemple, j'utilise Cardapio comme menu principal, et le lanceur s'y est créé comme un charme. Je voulais te faire deux remarques :
- lorsque l'on crée l'icône, le clic sur le bouton supérieur (choisir icône dans le thème) est déroutant, car il ne réagit pas si le programme n'est pas installé dans le système (enfin il me semble, car je viens de tester ton extension sur un programme que je suis en train de développer, qui n'est donc présent qu'en local) ; en revanche, pas de problème lorsque je clique sur l'autre bouton pour choisir une icône perso.
- peut-être parce que mon programme n'est que "local" pour le moment, lorsqu'il est lancé (c'est un binaire pur C) l'icône n'est pas celle que j'ai choisie, qui apparaît pourtant correctement dans le menu système.

Pour finir, une suggestion : pourrais-tu permettre aux développeurs qui souhaitent fabriquer des paquets Debian "conformes" ,une option pour récupérer où l'on veut le fichier .desktop produit par ton extension ?
Cordialement.

Roschan

Le bouton pour choisir une icône depuis le thème ne fonctionne pas si ton thème d'icônes n'est ni dans /usr/share/icons/ ni dans ~/.local/share/icons/
Or avec LXDE il est probable que ce soit encore les normes du début des années 2000, par exemple un dossier ".icons" qui traîne dans ~/

Je n'ai pas l'intention de supporter ces archaïsmes, mais ça peut se régler chez l'utilisateur par exemple en créant un lien symbolique vers l'emplacement attendu des icônes.

Lorsque l'appli est lancée, oui c'est assez indépendant du lanceur, je ne maîtrise pas tout mais il me semble que les applications peuvent définir leur icône.

Pour finir, une suggestion : pourrais-tu permettre aux développeurs qui souhaitent fabriquer des paquets Debian "conformes" ,une option pour récupérer où l'on veut le fichier .desktop produit par ton extension ?

Si c'est pour distribuer à des utilisateurs, il vaut mieux faire des lanceurs sérieusement, avec MenuLibre ou équivalent : je ne gère que quelques champs à peine, alors que les lanceurs en ont généralement des dizaines, traduits dans plusieurs langues. Si tu veux le récupérer, il est dans ~/.local/share/applications/

kholo

salut Roschan,
je me met doucement à Python,... donc je regarde tout ce qui traîne...
d'abord, merci pour tes partages...

j'ai installé "nautilus-launcher-creator-master", le fonctionnement est perfectible alors je vais me faire la main dessus...

sinon en lançant dialog.py à part, j'ai ce retour :

dialog.py:11: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk, GObject, Gio, GLib, GdkPixbuf

Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.

donc je le satisfait en ajoutant la ligne

gi.require_version('Nautilus', '3.0')
gi.require_version('Gtk', '3.0') # ICI !
from gi.repository import Gtk, GObject, Gio, GLib, GdkPixbuf

et, plus de ligne d'erreur

pour "update-and-compile-translations.sh"

IFS='
'
IFS=$'\n'

liste=`ls ./launcher-creator/locale/`

les quottes inversées sont remplacées par $( application )

liste=$( ls ./launcher-creator/locale/ )

quant au ls, sans vraiment chercher le fonctionnement du script :

#!/bin/bash

echo "Generating .pot file..."
xgettext --files-from=files-list --output=launcher-creator/locale/launcher-creator.pot

base_dir="./launcher-creator/locale"

for dossier in $base_dir/*
do
	if [ "${dossier##*/}" != "launcher-creator.pot" ]; then
		dir_out="$dossier/LC_MESSAGES"
		# echo "dossier $dir_out"

		echo "Updating translation for: $dossier"
		msgmerge $dir_out/launcher-creator.po $base_dir/launcher-creator.pot > $dir_out/launcher-creator.temp.po
		mv $dir_out/launcher-creator.temp.po $dir_out/launcher-creator.po
		echo "Compiling translation for: $dossier"
		msgfmt $dir_out/launcher-creator.po -o $dir_out/launcher-creator.mo
	fi
done

exit 0

Roschan

tu sais les traductions je m'en fous ce n'est clairement pas très intéressant à développer, tant que ça marche je ne vais pas chercher à bidouiller le script

si tu veux jouer avec du python, il y a sans doute des projets plus intéressants, ici c'est clairement du bricolage d'une grande laideur

moths-art

Super projet avec une vrai valeur ajouté !

Alors, quelques suggestions :

- un paquet deb (si il faut, je peux te faire une proposition via pull request)
- Le formulaire par étape est déroutant : on aimerait passer d'un onglet à l'autre sans passer par les précédents.
Si tu mets ça en place, pourquoi ne pas mettre une petite coche pour identifier que cet onglet à bien été complété.
Dans la même idée : différencier "suivant" de "terminer" qui n'a pas la même conséquence.
- l'ouverture d'un fichier .desktop va créer un .desktop.desktop
- La réouverture d'un fichier .desktop devrait (idéalement) le parser et pré-remplir les champs
Perso, je retouche souvent mes desktop donc c'est pas anecdotique
- du drag and drop pour les icônes (tu peux t'inspirer de mon projet https://github.com/mothsART/fluxboxlauncher)
- dans menulibre, y'a la suggestion via une petite arbo des catégories disponibles : ça serait sympa d'avoir la même fonctionalité.
- dernier point plus subtil : les .desktop, je les édites pour faire des .deb le plus souvent et leur soucis d'édition m'oblige souvent à regenerer un paquet.
Dans ton utilitaire, les exec et icon ont des chemins absolus correspondants aux fichiers physiques.
La cerise sur le gateau serait une checkbox (empaqueté pour Debian) qui parserais le fichier .install afin de donner le chemin du fichier une fois le paquet installé.

Roschan

- l'ouverture d'un fichier .desktop va créer un .desktop.desktop
- La réouverture d'un fichier .desktop devrait (idéalement) le parser et pré-remplir les champs
Perso, je retouche souvent mes desktop donc c'est pas anecdotique

attention ce n'est pas un éditeur de fichiers .desktop, ça n'ouvre jamais rien, je m'en sers pour donner un lanceur à mes scripts et mes appimages, ce n'est pas vraiment conçu pour être un outil de développement

lynn

Bonjour Roschan,

Il serait possible que le chemin par défaut du lanceur soit

~/.local/share/applications

plutôt qu'à l'endroit où se trouve la cible ?

Merci. 🙂

Roschan

C'est déjà le comportement par défaut si la cible est exécutable, mais là pour l'instant j'ai tout cassé pour tout refaire au propre

lynn

En fait, ce n'est même pas l'endroit ou se trouve la cible comme je l'ai écrit précédemment, c'est dans le répertoire personnel...

Que le fichier soit exécutable ou non n'y change rien... mais bon, avec une extension toute neuve, ça va fonctionner. 🙂

Roschan

Si si, je te le reconfirme, si le fichier est reconnu comme exécutable (ce qui n'est pas aussi fiable qu'on l'aimerait, certes) le type de lanceur est "application" et l'emplacement sera .local/share/applications, sinon c'est de type "lien" et dans le dossier personnel. Tu ne vas quand même pas m'apprendre le fonctionnement de mon code, même si c'est une ancienne version.

lynn

Roschan a écritTu ne vas quand même pas m'apprendre le fonctionnement de mon code, même si c'est une ancienne version.

Je n'ai pas la prétention de t'apprendre le fonctionnement de ton code (j'en serais bien incapable...) mais pour faire part de quelque chose que je constate !
Quand je choisi un fichier (exécutable, script, appimage ou autre), positionné comme exécutable, le chemin par défaut est toujours dans mon répertoire personnel, que le choix du type soit Lien ou Application.

Si tel avait été le cas dès le début, je n'aurais pas écrit mon message en #14.

lynn

Complément d'information :

J'ajoute un lien vers l'archive que j'utilise si toutefois quelqu'un d'autre peut constater si ça fonctionne avec le résultat attendu ou non.
Sur des installations neuves d'Ubuntu 18.04 et 19.04, le résultat est le même que celui décrit plus haut : l'endroit de création du fichier .desktop est systématiquement proposé dans le répertoire personnel.

Roschan

C'était pas la peine de t'embêter, on peut naviguer le dépôt github selon la date pour revenir à la version qui marchait. Ici ce qui nous intéresse est ligne 59 de __init__.py et ligne 100 de dialog.py

Après comme je l'ai écrit :

si le fichier est reconnu comme exécutable (ce qui n'est pas aussi fiable qu'on l'aimerait, certes)

Mais ça c'est la fiabilité de l'API ne Nautilus et de GLib, donc c'est pas mes ognons, de toutes manières la prochaine version devrait mettre à jour de force le chemin quand on change le type ("application"/"lien")

Page suivante »