slacky.eu

Su slackware 14.2 ho in uso due applicazioni installate attraverso il pachidermico "flatpak":
- Gimp
- Scribus.

Come ambiente grafico utilizzo "dwm" (https://dwm.suckless.org), il quale presenta una utility chiamata "dmenu" che in pratica consente di richiamare gli eseguibili per lanciarli in modo abbastanza semplice:
- tastoWin + p (o Alt+p se si ha l'impostazione di default)
- digitare il nome dell'applicazione/script che sia nel PATH
- e invio per eseguire il programma

Con flatpak avevo pensato di realizzare un wrapper del genere. Ad esempio il comando da eseguire per avviare Scribus sarebbe: Piuttosto scomodo...
Ne ho fatto uno script che esegue quel comando, da terminale funziona e scribus si avvia quasi istantaneamente, poi va be' il mio PC non è una scheggia di suo quindi una certa "latenza" si vede ma è dovuta all'avvio di Scribus indipendentemente da flatpak.

Se richiamo quello stesso script scribus.sh attraverso dmenu, quindi senza aprire un terminale ecc... la cosa dovrebbe essere più comoda, ma c'è un comportamento intollerabile. Ovvero scribus parte dopo circa 10 secondi o più.

Ho provato a lanciare il comando flatpak visto sopra direttamente da dmenu, senza script bash in mezzo quindi. Ma purtroppo rilevo lo stesso abnorme "delay".

Quindi in sintesi, lanciare l'avvio di un'app con flatpak attraverso dmenu comporta il problema che l'app si avvia dopo 10 secondi buoni.
Lo stesso comando lanciato da terminale porta all'apertura della stessa app istantaneamente.

Che problema potrebbe avere dmenu con flatpak?

Aggiorno un attimo la situazione.
Ho fatto qualche prova lanciando flatpak da terminale in modo verboso e dirigendo lo stderr su un file di log. Poi ho copiato lo stesso comando in dmenu (Mod+p seguito da ctrl+shift+y per incollare il comando), ho rediretto però lo stderr su un file diverso questa volta. Alla fine ho 2 logs. Il primo relativo all'avvio quasi istantaneo dell'applicazione scribus da terminale, il secondo log relativo al lancio da dmenu.

In sintesi è saltata fuori una riga di errore in più, presente solo nel log dell'avvio da dmenu, che potrebbe dare un'indicazione di dove stia il problema della lentezza esagerata di avvio: Cercando in rete si trovano diversi suggerimenti che però per il momento no mi hanno aiutato a risolvere il problema né a capire bene quale sia precisamente.
Trovo eventuali relazioni con "dbus", ma nel mio caso dbus c'è e la sessione dwm viene avviata con dbus-launch: Inoltre trovo una soluzione per raspberry in cui risolvono installado il pacchetto "at-spi2-core".
Sul mio sistema c'è, tra l'altro risulta installato e sovrascritto dalla versione multilib compat32 spero non si a quello il problema. Se vi venisse in mente qualcosa... grazie in anticipo!

Riprendo un attimo questo topic perché ho testato meglio la situazione e rilevo che la lentezza di avvio di applicazioni tramite flatpak non è limitata al solo dmenu, ma anche all'apertura di files dal filemanager:
ho provato ad esempio ad aprire un immagine sia da Dolphin che da Thunar.
Click destro, "open with" GIMP.

Quel Gimp è collegato ad un file .desktop apposito che di fatto esegue il comando "flatpak run org.gim.GIMP". In pratica si tratta dell'unica installazione di Gimp che ho e che appunto fa parte di flatpak.

OK, il problema è che l'avvio di Gimp inizia dopo circa 20 secondi (non 10 come avevo scritto nei primi post senza cronometrare per bene) e si conclude circa 5 secondi dopo. In pratica si ha la finestra di Gimp non prima di 25s di attesa.
C'è qualcosa che non va evidentemente.

La cosa singolare è che lanciando il comando dal terminale (flatpak run org.gimp.GIMP) si ha la stessa finestra di Gimp aperta regolarmente in circa 5 secondi.

In soldoni il problema riguarda solo l'avvio da applicazioni legate all'interfaccia grafica del sistema, quindi sia dmenu che vari file manager.
Ho anche trovato un link che spiega come la cosa potrebbe essere legata a fontconfig che flatpak gestirebbe in modo sconveniente ricreando in memoria ogni volta il set di fonts o qualcosa del genere ho letto al volo... ad ogni modo la soluzione sembrerebbe fare l'upgrade di fontconfig, che per la Slackware-14.2 che ho ancora in uso ha poco senso adesso probabilmente passando a slack-15 non si ha il problema, ma a quel punto non mi servirebbe neanche più flatpak perché sia scribus che gimp sarebbero compilabili in modo nativo sul sistema, cosa che personalmente trovo più che preferibile.

Il link all'articolo sarebbe questo:
https://blogs.gnome.org/alexl/2018/01/1 ... tup-times/

Devo dire che non sono sicurissimo che sia lo stesso problema perché lì parla di lentezza al primo avvio, nel mio caso invece il problema è riproducibile enne volte anche dopo aver chiuso GIMP: se lo riapro richiamandolo da file manager impiega di nuovo 25 secondi. Ho anche provato ad aprire prima un'immagine con Gimp e lasciandola aperta ho provato ad aprire un documento .sla con Scribus, ma nonostante di fatto flatpak fosse già avviato per Gimp, anche Scribus ha impiegato sui 25 secondi circa per aprirsi.
Quindi boo.

Ho creato una pezza, tanto per convivere con questo problema per spero non più di un mese, quando dovrei aver fatto l'upgrade alla 15.0. Uno script che controlla ogni due secondi se c'è un file chiamato flatpak.run. Se lo trova lancia "flatpak run $(cat flatpak.run)". Poi ho fatto due script uno per Gimp e l'altro per Scribus che non fanno altro che scrivere sul file flatpak.run il nome del flatpak ID corrispondente all'applicazione specifica (tipo echo "org.gimp.GIMP" > flatpak.run).
In questo modo è come se lanciassi il comando da terminale, perché di fatto il primo script è una sorta di demone che gira lanciato appunto da terminale, anche se poi se ne va in background ecc...

Perdona la curiosità, ma perché usare flatpak per quei due software?

Perché mi è stato impossibile installarne la versione più recente sulla 14.2.
Con Scribus ero riuscito a mettere la 1.5.1 ma avevo dovuto installare poppler più recente di quello di sistema, e ora non ricordo più i dettagli ma avevo dovuto metterlo come alternativa in opt in modo che solo Scribus vi si appoggiasse e non venisse coinvolto tutto il sistema, il ché altrimenti avrebbe portato a dover ricostruire poi un sacco di roba (forse anche pacchetti ufficiali) che dipende in qualche modo da poppler. Vedi? Avevo messo la 0.68 mentre quella di sistema era la 0.45 e Scribus con questa non funzionava.
Le versioni successive non ero più riuscito a farle compilare e avevo rinunciato, poi ho visto che flatpak poteva essere un'alternativa. In effetti ora uso Scribus 1.5.8 senza troppi problemi a parte come descritto il "lag" di 25 secondi all'avvio.

Per Gimp idem. Sulla 14.2 l'attuale versione 2.10.30 l'avrei vista col binocolo.

Se mi fossero servite più applicazioni in versione aggiornata non avrei sfruttato flatpak ma probabilmente sarei passato a slackware current o sarebbe stata la volta buona per testare arch.

Ah, pardon.
Ora puoi aggiornare alla 15 volendo.
Io uso current e a volte ho ugualmente quei problemi.

Per aggiungere il supporto flatpak a dmenu e simili (bemenu per wayland dwl) basta aggiungere in ~/.bashrc o ~/bash_profile:
Appariranno fra la lista dei vari eseguibili identificati tipo "org.blender.Blender".