1 21/05/2026 11 min

Creare un collegamento desktop per Eclipse su Ubuntu Linux non è solo una questione estetica. In pratica stai decidendo come il desktop environment deve avviare l’applicazione, quale icona mostrare, dove cercare il binario e con quali regole di fiducia trattare il file .desktop. Se salti un dettaglio, il risultato tipico è sempre lo stesso: icona che non compare nel menu, lancio che fallisce senza messaggi utili, oppure collegamento che funziona solo dalla shell ma non dall’interfaccia grafica.

Su Ubuntu il formato di riferimento è il file .desktop. È un file di testo, non un “collegamento” proprietario. GNOME, KDE, Cinnamon e gli altri ambienti lo interpretano per mostrare un’icona nel menu applicazioni, nel dock o sul desktop. Per Eclipse il punto delicato è che spesso l’installazione non passa da un pacchetto tradizionale, ma da un archivio estratto in una directory dell’utente, ad esempio /opt/eclipse o ~/apps/eclipse. Quindi il collegamento non deve dare per scontato un path standard.

Struttura minima del launcher .desktop

Un launcher funzionale per Eclipse ha pochi campi, ma devono essere coerenti tra loro. I campi davvero importanti sono Name, Exec, Icon, Type e, in molti casi, Terminal. Se il file è destinato al menu applicazioni, conviene anche aggiungere Categories per farlo classificare correttamente dal desktop environment.

Il principio è semplice: Exec deve puntare a un eseguibile reale, Icon deve riferirsi a un file immagine esistente, e il file deve essere leggibile dall’utente che avvia la sessione grafica. Se il percorso è sbagliato, il desktop non “indovina” nulla. Se invece il file è corretto ma non è marcato come eseguibile, il comportamento cambia da ambiente a ambiente: alcuni lo nascondono, altri lo mostrano ma non lo avviano.

Esempio pratico di file .desktop

Per una installazione classica in /opt/eclipse, un file valido può essere questo:

[Desktop Entry]
Version=1.0
Type=Application
Name=Eclipse IDE
Comment=Eclipse Integrated Development Environment
Exec=/opt/eclipse/eclipse
Icon=/opt/eclipse/icon.xpm
Terminal=false
Categories=Development;IDE;
StartupNotify=true

Se il tuo pacchetto Eclipse usa un’icona in formato PNG, puoi indicare anche un file come /opt/eclipse/icon.png. Il formato non è il punto critico; lo è la presenza reale del file e la leggibilità. Se preferisci una collocazione più ordinata per il desktop, puoi usare anche il percorso standard per le applicazioni locali, ad esempio ~/.local/share/applications/eclipse.desktop per il profilo utente, oppure /usr/local/share/applications/eclipse.desktop per una disponibilità più ampia sul sistema.

Dove mettere il file per farlo comparire davvero

Su Ubuntu il punto di deposito cambia a seconda dell’effetto che vuoi ottenere. Se il collegamento deve valere solo per il tuo utente, il posto giusto è ~/.local/share/applications/. Se deve comparire per tutti gli utenti, la directory è /usr/share/applications/ o, se vuoi separare il contenuto installato manualmente da quello gestito dal sistema, /usr/local/share/applications/.

Per il desktop, non basta copiare il file nella cartella giusta. L’ambiente grafico spesso applica controlli di sicurezza sul file .desktop, soprattutto se proviene dalla cartella Downloads o da un filesystem montato in modo particolare. Per questo conviene usare una directory standard e verificare i permessi. Il file non deve essere scrivibile da utenti non autorizzati se è condiviso a livello di sistema, e deve essere leggibile dall’utente interessato.

Una sequenza operativa pulita, lato utente, è questa:

mkdir -p ~/.local/share/applications
nano ~/.local/share/applications/eclipse.desktop

Dopo il salvataggio, se il desktop environment non aggiorna subito la lista applicazioni, basta fare logout/login oppure, in molti casi, riavviare la shell grafica. Alcuni ambienti ricaricano in automatico i launcher, altri sono più conservativi.

Verifiche prima di dare la colpa al desktop environment

Quando il collegamento non parte, la prima ipotesi non è mai “Ubuntu è rotto”. Prima si controlla se il binario esiste davvero e se parte da terminale. Eclipse, specie quando installato manualmente, può avere il launcher in una sottodirectory diversa da quella che ricordi. In più, il file eclipse può essere uno script wrapper che a sua volta invoca Java, quindi il problema potrebbe essere a monte, non nel file .desktop.

Controlli rapidi utili:

test -x /opt/eclipse/eclipse && echo OK || echo KO
/opt/eclipse/eclipse --version
ls -l /opt/eclipse/icon.*

Se il comando test -x restituisce KO, il campo Exec punta al posto sbagliato o il file non è eseguibile. Se --version fallisce, il problema è nel binario o nelle dipendenze Java. Se l’icona non esiste, il collegamento potrebbe comunque partire, ma senza immagine o con un segnaposto generico.

Permessi e fiducia del file .desktop

Su alcuni ambienti grafici, un file .desktop appena creato può essere considerato “non fidato” e quindi non cliccabile con un doppio clic diretto. In quel caso il desktop mostra un avviso o richiede di autorizzare il launcher. Questo comportamento è normale: serve a evitare l’esecuzione accidentale di file scaricati da fonti non attendibili.

Se il file è nel profilo utente e vuoi renderlo avviabile dal desktop, verifica anche i permessi del file:

chmod 644 ~/.local/share/applications/eclipse.desktop
gio set ~/.local/share/applications/eclipse.desktop metadata::trusted true

Il secondo comando non è sempre necessario e dipende dall’ambiente grafico. Dove non è supportato, il launcher resta comunque valido se lo avvii dal menu applicazioni o se l’ambiente lo importa correttamente. Se vuoi evitare ambiguità, la strada più robusta resta posizionare il file nella directory applicazioni corretta e usare un percorso Exec assoluto.

Creazione del collegamento sul desktop vero e proprio

Se l’obiettivo non è il menu applicazioni ma un’icona visibile sul desktop, la logica cambia poco: sempre un file .desktop, ma collocato nella cartella del desktop dell’utente, ad esempio ~/Desktop/ o ~/Scrivania/ a seconda della lingua e della configurazione. Anche qui, però, il desktop environment può bloccare il file se non lo considera affidabile o se la directory del desktop non è abilitata a mostrare icone.

La procedura tipica è questa:

cp ~/.local/share/applications/eclipse.desktop ~/Desktop/
chmod +x ~/Desktop/eclipse.desktop

Su GNOME, a seconda della versione, il supporto alle icone sul desktop può richiedere estensioni o impostazioni specifiche. Se il file c’è ma non si vede, il problema può essere nell’abilitazione del desktop icon manager, non nel launcher. In quel caso la verifica non si fa nel file .desktop, ma nel comportamento dell’ambiente grafico: se il desktop non mostra alcuna icona, il file è probabilmente corretto ma la vista del desktop è disabilitata o gestita da un componente diverso.

Eclipse installato in una home o in una directory non standard

Molti installano Eclipse scaricando il tarball ufficiale e scompattandolo in una cartella privata, per esempio ~/Applications/eclipse o ~/tools/eclipse. In questo scenario il launcher deve essere costruito con un path assoluto, perché il desktop non eredita la tua shell e non espande variabili come ti aspetti. Mettere Exec=eclipse funziona solo se il comando è nel PATH del processo grafico, cosa che di solito non è garantita.

Se vuoi usare una directory personale, un esempio più solido è questo:

[Desktop Entry]
Version=1.0
Type=Application
Name=Eclipse IDE
Exec=/home/utente/Applications/eclipse/eclipse
Icon=/home/utente/Applications/eclipse/icon.png
Terminal=false
Categories=Development;IDE;

Qui il punto critico è la sostituzione di utente con il nome reale dell’account. Se vuoi evitare path hardcoded, puoi creare un piccolo wrapper shell nel tuo profilo, ma non è la scelta migliore se il collegamento deve restare semplice e leggibile. Un launcher .desktop dovrebbe essere chiaro da auditare, non un mini framework nascosto.

Uso del wrapper quando Eclipse dipende da variabili o opzioni particolari

In alcuni casi Eclipse richiede opzioni JVM specifiche, percorsi custom per workspace o variabili ambientali che non vuoi scrivere direttamente nel file .desktop. La soluzione pulita è un wrapper script, non una catena di shell nel campo Exec. Il wrapper ti permette di versionare le opzioni, testare la partenza da terminale e isolare i cambiamenti senza sporcare il launcher grafico.

Un esempio minimale:

#!/bin/sh
export ECLIPSE_HOME=/opt/eclipse
exec "$ECLIPSE_HOME/eclipse" -data "$HOME/workspace-eclipse"

Dopo aver salvato il wrapper, rendilo eseguibile e punta il file .desktop a quello script:

chmod +x ~/bin/start-eclipse [Desktop Entry]
Name=Eclipse IDE
Type=Application
Exec=/home/utente/bin/start-eclipse
Icon=/opt/eclipse/icon.png
Terminal=false
Categories=Development;IDE;

Questo approccio è utile anche quando devi passare opzioni come memoria heap, parametri di debug o una workspace separata per progetto. Non conviene però abusarne: se il launcher deve fare troppe cose, stai già spostando complessità fuori posto.

Diagnosi rapida quando il collegamento non compare nel menu

Se il file è stato creato ma Eclipse non compare nella ricerca applicazioni, il problema di solito è uno di questi tre: file salvato nel percorso sbagliato, nome file non terminante con .desktop, oppure sintassi del launcher non valida. I desktop environment tendono a ignorare i file non conformi senza spiegazioni dettagliate.

Controllo rapido della presenza e del contenuto:

ls -l ~/.local/share/applications/eclipse.desktop
sed -n '1,20p' ~/.local/share/applications/eclipse.desktop
desktop-file-validate ~/.local/share/applications/eclipse.desktop

Il comando desktop-file-validate è molto utile perché segnala errori di sintassi, campi mancanti o valori non conformi. Se non è installato, puoi aggiungere il pacchetto che lo fornisce, ma prima verifica se il tuo sistema ha già gli strumenti desktop standard. Il suo output è spesso il modo più rapido per distinguere un problema di formato da un problema di path.

Icona corretta e coerenza visiva

L’icona ha un impatto pratico più alto di quanto sembri. Un launcher senza icona o con un’icona sbagliata viene confuso con altri collegamenti, soprattutto se gestisci più versioni di Eclipse o più IDE. Per questo conviene usare un file immagine dedicato, con un nome leggibile e un percorso stabile. Se il tema grafico supporta scaling diversi, un PNG ben fatto è spesso più affidabile di un formato troppo esotico.

Se vuoi verificare che l’icona sia raggiungibile, non basta guardarla nel file manager. Serve controllare il path reale:

file /opt/eclipse/icon.png
stat /opt/eclipse/icon.png

Se l’icona è dentro l’archivio di Eclipse e non vuoi copiarla altrove, va bene comunque, ma assicurati che la directory non cambi a ogni aggiornamento. In caso contrario il launcher si rompe al prossimo upgrade manuale, e il problema non è il desktop: è la tua dipendenza da un path volatile.

Approccio consigliato in ambiente misto o gestito

In un ambiente con più utenti o con workstation gestite, conviene standardizzare il launcher. La soluzione più prevedibile è installare Eclipse in una directory comune, creare il file .desktop in /usr/local/share/applications/ e mantenere il path dell’eseguibile stabile. In questo modo tutti gli utenti vedono la stessa voce di menu e il supporto operativo non deve inseguire copie personali sparse nelle home.

Se invece vuoi lasciare libertà all’utente, resta nel profilo locale, ma documenta almeno due cose: dove si trova l’installazione di Eclipse e come verificare il launcher. La manutenzione vera non è creare il file .desktop; è evitare che tra tre mesi qualcuno lo trovi non funzionante dopo un aggiornamento manuale o dopo un cambio di directory.

Checklist finale operativa

Quando hai finito, la verifica minima dovrebbe essere questa:

  1. Il file eclipse.desktop esiste nel percorso corretto, ad esempio ~/.local/share/applications/ o /usr/share/applications/.
  2. desktop-file-validate non segnala errori di sintassi.
  3. Exec punta a un binario reale e avviabile con path assoluto.
  4. Icon punta a un file esistente.
  5. Il collegamento compare nel menu applicazioni o sul desktop, a seconda della posizione scelta.

Se uno di questi punti fallisce, non si corregge alla cieca. Prima si identifica il livello del problema: sintassi del launcher, path dell’eseguibile, permessi, fiducia del file o supporto del desktop environment. È il modo più veloce per arrivare a un collegamento stabile senza trasformare un file di testo in una caccia al tesoro.

In sintesi pratica: per Eclipse su Ubuntu, il metodo più robusto è un file .desktop con path assoluti, salvato nella directory corretta per l’ambito desiderato, validato con desktop-file-validate e testato con un avvio reale del binario. Se ti serve portabilità tra utenti o versioni, aggiungi un wrapper script. Se ti serve solo un accesso rapido, resta essenziale e non inventare complessità dove non serve.