1 04/11/2026 10 min

Un AppImage funziona già da solo: lo scarichi, gli dai i permessi di esecuzione e lo lanci. Il punto debole, però, è l’integrazione con il desktop: se vuoi trovarlo nel menu applicazioni, aggiungerlo ai preferiti o avviarlo con un’icona pulita, conviene creare un collegamento desktop vero e proprio. La buona notizia è che non serve installare nulla a livello di sistema: basta un file .desktop fatto bene, più un’icona e il percorso corretto dell’AppImage.

Qui conviene ragionare come in un piccolo cambio controllato: lo stato atteso è avere un launcher visibile nel menu e cliccabile dal desktop; lo stato osservato, spesso, è un file AppImage che parte solo da terminale o da file manager. Le cause più comuni sono tre: il file .desktop non è nel posto giusto, il comando Exec punta a un percorso errato, oppure il desktop environment rifiuta il launcher perché non è marcato come affidabile o eseguibile.

Cosa serve prima di iniziare

Prima di scrivere il collegamento, verifica tre cose: il file AppImage esiste davvero, è eseguibile e sai dove vuoi conservarlo. La soluzione più pulita è tenere l’AppImage in una cartella stabile, per esempio /opt/applicazioni/ oppure ~/Applications/. Se lo sposti di continuo, il collegamento smette di funzionare e ti ritrovi con un menu che apre nulla.

Per un singolo utente, il posto più semplice per il launcher è ~/.local/share/applications/. Per renderlo visibile a tutti gli utenti della macchina, si usa invece /usr/share/applications/, ma lì servono privilegi amministrativi e ha senso solo se il software è davvero condiviso. In questo articolo parto dal caso più sicuro e reversibile: collegamento per un singolo utente.

Permessi e posizione dell’AppImage

Se il file non è eseguibile, il collegamento non partirà. Il controllo minimo è questo:

ls -l ~/Applications/NomeProgramma.AppImage
chmod +x ~/Applications/NomeProgramma.AppImage

Il primo comando ti mostra i permessi attuali; nel risultato, la presenza di una x tra i permessi indica che il file è eseguibile. Il secondo comando aggiunge il bit di esecuzione senza modificare il contenuto del file. È un’operazione reversibile: se vuoi togliere l’eseguibilità, puoi usare chmod -x sullo stesso file.

Se l’AppImage sta in una cartella temporanea o in un percorso sincronizzato che cambia spesso, il collegamento desktop diventa fragile. La scelta pratica è tenerlo in un path stabile, ad esempio ~/Applications/NomeProgramma.AppImage. Così il file .desktop non deve essere riscritto ogni volta.

Struttura minima di un file .desktop

Un launcher desktop è un file di testo con una struttura precisa. I campi essenziali sono pochi: nome visibile, comando di avvio, icona, categoria e indicazione che si tratta di un’applicazione. Un esempio base, da adattare ai tuoi percorsi, è questo:

[Desktop Entry]
Type=Application
Name=Nome Programma
Exec=/home/tuo-utente/Applications/NomeProgramma.AppImage
Icon=/home/tuo-utente/Applications/icone/nomeprogramma.png
Terminal=false
Categories=Utility;Office;
StartupNotify=true

La riga Exec è la più importante: deve contenere il percorso assoluto dell’AppImage. Evita di usare percorsi relativi, perché molti menu non li risolvono nel modo che ti aspetti. Terminal=false serve per le applicazioni grafiche; se il programma richiede davvero un terminale, allora va impostato su true, ma nel caso degli AppImage grafici è quasi sempre falso.

Il campo Categories aiuta il desktop environment a classificare il programma nel menu. Non è obbligatorio per farlo partire, ma senza categorie l’app può finire in una sezione poco sensata o risultare meno facile da trovare. Le categorie valide dipendono dall’ambiente desktop, ma stringhe come Utility, Office, Graphics, Development o Network sono tra le più comuni.

Per l’icona, meglio usare un file locale in formato .png o .svg. Alcuni AppImage hanno già un’icona integrata, ma l’integrazione nel menu è più affidabile se specifichi un file dedicato. Anche qui, usa un percorso assoluto.

Dove salvare il collegamento desktop

Per un solo utente, salva il file in ~/.local/share/applications/. Per esempio:

mkdir -p ~/.local/share/applications
nano ~/.local/share/applications/nome-programma.desktop

Dopo averlo creato, rendilo eseguibile. Non è sempre obbligatorio, ma molti desktop environment lo richiedono o lo gestiscono meglio così:

chmod +x ~/.local/share/applications/nome-programma.desktop

Se vuoi provarlo subito, puoi anche copiarlo sul desktop grafico, ma non è la soluzione migliore per l’uso quotidiano. Il file nel menu applicazioni è più stabile e più facile da mantenere. Inoltre, una volta che il launcher è registrato nel sistema, puoi aggiungerlo ai preferiti o alla dock senza dover tenere un duplicato sul desktop.

Esempio completo con percorso assoluto

Questo è un esempio completo e realistico per un AppImage conservato nella home dell’utente:

[Desktop Entry]
Type=Application
Name=Krita AppImage
Comment=Editor grafico in formato AppImage
Exec=/home/mario/Applications/Krita-5.2.6-x86_64.AppImage
Icon=/home/mario/Applications/icone/krita.png
Terminal=false
Categories=Graphics;2DGraphics;RasterGraphics;
StartupWMClass=krita

La riga StartupWMClass è utile quando il desktop non associa correttamente la finestra aperta al launcher. Non è sempre necessaria, ma può risolvere il classico problema dell’icona duplicata nella dock o del launcher che non si “aggancia” alla finestra in esecuzione. Il valore va verificato caso per caso: non inventarlo a caso, perché deve corrispondere alla classe della finestra dell’applicazione.

Se non sai quale StartupWMClass usare, puoi prima fare a meno di questo campo e vedere se il launcher funziona comunque. È una modifica minima e reversibile: aggiungi il campo solo se noti un comportamento anomalo nella gestione della finestra.

Come trovare il nome corretto della finestra

Quando serve rifinire l’integrazione, il problema non è quasi mai l’AppImage in sé, ma il modo in cui il desktop identifica la finestra. Se il launcher parte ma la dock mostra un’icona separata, il desktop environment sta vedendo due entità diverse. In quel caso devi ricavare la classe della finestra e usarla nel file .desktop.

Su molti ambienti grafici puoi farlo con strumenti già presenti o con utility come xprop, selezionando la finestra dell’app e leggendo la proprietà WM_CLASS. Il dato esatto varia in base al toolkit usato dall’applicazione, quindi non esiste una regola unica. Il principio, però, è sempre lo stesso: osservi il comportamento reale e allinei il launcher a quello che il desktop si aspetta.

Test rapido del launcher

Prima di considerarlo finito, fai un controllo semplice ma rigoroso. Apri il file .desktop, verifica che non ci siano errori di sintassi, poi prova ad avviarlo dal menu o con un doppio clic. Se non compare nel menu, il problema è quasi sempre uno di questi: file nel path sbagliato, permessi mancanti, cache del menu non aggiornata o formato del file non valido.

desktop-file-validate ~/.local/share/applications/nome-programma.desktop

Se il comando restituisce silenzio o nessun errore, il file è formalmente valido. Se invece segnala campi mancanti o righe mal formate, correggi prima quello e solo dopo passa al test grafico. È molto più veloce sistemare un errore di sintassi che inseguire un launcher “muto” nel menu.

Su alcuni sistemi può essere utile aggiornare il database delle applicazioni dell’utente, soprattutto se il menu non si aggiorna subito. Un comando spesso utile è:

update-desktop-database ~/.local/share/applications/

Non tutti gli ambienti ne hanno bisogno, ma è un passo leggero e reversibile. Se il launcher è corretto e il desktop lo indicizza bene, l’app dovrebbe comparire nel menu dopo pochi secondi o dopo un refresh della sessione grafica.

Icona: dove metterla e come evitarne la perdita

L’icona è spesso il dettaglio che distingue un collegamento “arrangiato” da uno ben fatto. Se la lasci dentro una cartella che poi elimini o sincronizzi male, il launcher resterà funzionante ma visivamente rotto. Conviene quindi sistemarla in una directory stabile, per esempio nella stessa cartella dell’AppImage o in una sottocartella dedicata alle icone.

Se usi un file .svg, in molti casi ottieni una resa più pulita su schermi ad alta densità. Se preferisci un .png, scegli una dimensione ragionevole, ad esempio 128x128 o 256x256, così il desktop non deve ridimensionare in modo aggressivo. Il formato non cambia il funzionamento del launcher, ma incide sulla qualità percepita.

Avvio con argomenti e variabili d’ambiente

Alcuni AppImage accettano parametri di avvio, e il campo Exec può includerli. Se vuoi passare un file da aprire direttamente o un’opzione specifica, aggiungila dopo il percorso dell’eseguibile. Attenzione però al formato: il launcher desktop non gestisce sempre bene gli spazi se non sono quotati correttamente. In generale, meglio testare prima il comando da terminale e poi trascriverlo nel file .desktop.

Exec=/home/mario/Applications/NomeProgramma.AppImage --new-window

Se il programma richiede variabili d’ambiente, puoi inserirle direttamente nel launcher, ma solo quando serve davvero. Per esempio, alcuni software possono aver bisogno di un tema specifico o di un’opzione per la compatibilità grafica. In questi casi è meglio documentare bene la modifica nel file stesso, così in futuro capisci subito perché il launcher non è identico all’esecuzione standard.

Problemi comuni e come riconoscerli in fretta

Il primo problema classico è il percorso sbagliato in Exec. Il sintomo è semplice: dal menu sembra partire, ma in realtà non succede nulla. Il controllo veloce è aprire il file .desktop e confrontare il percorso con il file reale. Se hai rinominato l’AppImage, spostato la cartella o cambiato utente, il launcher va aggiornato.

Il secondo problema è il file non eseguibile. In quel caso il file compare magari nel menu, ma l’avvio fallisce senza messaggi chiari. Il controllo è il solito ls -l e, se serve, chmod +x. È una correzione minima, non distruttiva, e non altera il contenuto dell’applicazione.

Il terzo problema è la cache del desktop environment o del file manager. Alcuni ambienti aggiornano subito il menu, altri lo fanno in ritardo. Se hai già validato il file e i permessi, un logout/login o il refresh del menu può bastare. Prima di cambiare altro, verifica sempre che il problema non sia semplicemente di indicizzazione.

Versione pronta all’uso con commenti utili

Se vuoi un modello da adattare al volo, usa questo come base e modifica solo i campi segnati:

[Desktop Entry]
Type=Application
Name=Nome App
Comment=Descrizione breve
Exec=/percorso/assoluto/NomeApp.AppImage
Icon=/percorso/assoluto/icona.png
Terminal=false
Categories=Utility;
StartupNotify=true
# Facoltativo: aggiungi StartupWMClass solo se serve per la dock

Questo schema è intenzionalmente semplice, così riduci gli errori. Se l’app ha bisogno di categorie più specifiche, puoi aggiungerle senza toccare la logica del launcher. Se il desktop supporta azioni aggiuntive, puoi estendere il file in un secondo momento, ma per partire basta questo.

Rollback semplice se qualcosa va storto

Il vantaggio di questa procedura è che il rollback è immediato: basta eliminare il file .desktop o rinominarlo. Se hai modificato anche l’AppImage o l’icona, puoi lasciare intatto il binario e rimuovere solo il launcher. Nessun servizio di sistema viene toccato, quindi il raggio d’azione è limitato al tuo utente e al suo menu applicazioni.

Se vuoi tornare allo stato iniziale, rimuovi il file creato in ~/.local/share/applications/ e, se necessario, aggiorna di nuovo il database delle applicazioni. L’AppImage resta utilizzabile da terminale, quindi il rollback non blocca il software: elimina solo l’integrazione grafica.

Checklist finale per un collegamento fatto bene

  • Il file AppImage è in un percorso stabile.
  • Il file è eseguibile con chmod +x.
  • Il launcher .desktop è in ~/.local/share/applications/.
  • Exec usa un percorso assoluto corretto.
  • L’icona punta a un file reale e leggibile.
  • Il file passa desktop-file-validate.
  • Se serve, la classe finestra è stata verificata per evitare icone duplicate.

Una volta sistemati questi punti, il collegamento desktop per un AppImage si comporta come una normale applicazione installata: appare nel menu, si può aggiungere ai preferiti e si avvia senza passare dal terminale. La parte importante è mantenere il launcher semplice, con percorsi stabili e controlli verificabili. È questo che lo rende robusto nel tempo.