Su VentureCake c’è un breve articolo che propone 10 possibili idee per migliorare Gnome.
Alcune sono veramente valide (come il supporto per SyncML su Evolution) altre di discutibile utilità (come l’highlight delle nuove applicazioni installate alla Windows).
Alla ben nutrita lista aggiungerei che onestamente mi piacerebbe che il copia/incolla con il tasto centrale funzioni allo stesso modo tra tutte le applicazioni GTK e che alcune finestre di configurazione si adattino anche a risoluzioni inferiori a 1024×768 (vedi le preferenze di Evolution).
E voi cosa suggerireste agli sviluppatori di Gnome?
alfdev
28 giu 2007 - 09:56 - #1Mi sa che servirebbe lavorare un pò sulle prestazioni di gnome….
cyber
28 giu 2007 - 10:01 - #2Solo due cose:
1. Rinominare i file con un click.
2. Avere l’anteprima dei files (es. immagini, pdf, ecc.) solo delle finestre desiderate.
Emmanuele
28 giu 2007 - 10:08 - #3il copy and paste via PRIMARY (quello con il tasto centrale del mouse, per intenderci) funziona perfettamente in tutte le applicazioni gtk+. se ti riferisci a problemi con firefox (o altri browser basati su gecko) allora non è colpa delle gtk+ ma di quelli della mozilla foundation, che hanno un’idea malsana di come debbano essere le applicazioni per X (e per Linux in generale).
mad_max
28 giu 2007 - 11:30 - #4Che si possa avere desktop virtuali Tematici.
Ad esempio per ogni desktop virtuale deve essere possibile nascondere le icone, cambiare la cartella a cui punta, cambiare lo sfondo.
mad_max
28 giu 2007 - 11:32 - #5“Mi sa che servirebbe lavorare un pò sulle prestazioni di gnome….” ?
+ veloce di così? é impossibile :)
*Gian*
28 giu 2007 - 11:35 - #6Due cose:
1)Nautilus veloce…e non che per aprire una cartella di 100 file senza anteprima ci metta dei secondi
2)Che quando trascino un oggetto su una cartella questa si apra alla OSX
Riccardo Raneri
28 giu 2007 - 11:49 - #7Poter disattivare l’antialiasing “alla ClearType” dei caratteri e ottenere font “sani” e belli sharp come Windows 2000/XP pre-IE7.
hardskinone
28 giu 2007 - 11:52 - #8Spero ci sia qualche gnome hacker in lettura altrimenti questi commenti servono a poco…
1) Prestazioni. Non sono mai abbastanza. Che fine ha fatto quell’hacker che ha compiuto miracoli prima dell’ultima versione? Postava spessisimo sul planet di gnome.
2) Una nuova versione del menù “Invia a…”. Quello di Windows è più funzionale: elenca i vari “luoghi” dove è possibile spedire un file ed include anche eventuali chiavette usb collegate. Quello di Gnome apre una nuova finestra al centro dello schermo e solo da lì si sceglie dove “Inviare”; e niente chiavette usb in elenco.
NoWhereMan
28 giu 2007 - 12:35 - #9@Emmanuele (Bassi?): in che senso idea malsana ? :)
ilgufo
28 giu 2007 - 12:38 - #10citando un’idea di Gian:
2)Che quando trascino un oggetto su una cartella questa si apra alla OSX
e i brevetti? questa cosa se non sbaglio e’ brevettata dalla apple no? :P
DaPlaya
28 giu 2007 - 13:52 - #11Forse la priorità maggiore sarebbe risolvere tutti i _PESANTI_ memory leak che affliggono gtk e libgnome.
Perché andare a cercare altre funzionalità se poi le librerie stesse non funzionano a dovere?
Una cosa per volta…
DierRe
28 giu 2007 - 14:20 - #12Nella visualizzazione a dettagli rendere possibile selezionare col mouse più file senza dover ricorrere a ctrl o shift.
Arael
28 giu 2007 - 14:25 - #13Ragazzi…non dimentichiamo i monitor multipli. Io per fortuna ho una nvidia e me la sono cavata con nvidia-settings. Il programmino che distribuisce la Nvidia. Direttamente da Gnome non è possibile configurare monitor multipli.
Questa è una limitazione non indifferente per un DE.
fedalmor
29 giu 2007 - 03:08 - #14Due parole: **desktop semantico**. :P
mad_max
29 giu 2007 - 07:14 - #15*desktop semantico*?
help. Qualcuno traduca.;-)
Emmanuele
30 giu 2007 - 01:23 - #16@gian:
1) nautilus per aprirmi una directory con 200 item e l’anteprima ci mettere meno di un secondo;
2) spiacente, brevetto apple; non è che non sia stato implementato (penso che l’ultima volta l’abbiano scritto in meno di cento linee di codice), è che poi non possiamo impacchettarlo e distribuirlo (i server GNOME sono in nord america);
@nowhereman:
nel senso che firefox è prima di tutto un’applicazione win32, *poi* è un’applicazione multipiattaforma, poi un’applicazione che gira su linux e solo alla fine è un’applicazione che usa GNOME; sicuramente, non un poster child per l’uso di X, della clipboard e delle GTK+.
@daplaya:
quali pesanti leak? dì la verità, cosa hai fumato? guarda che se dici le bugie poi gesù bambino piange.
prima che qualcuno ribatta: no, le gtk+ hanno leak. e hanno bug. *non* hanno “pesanti leak”, questo è poco ma sicuro. penso che un paio di librerie dello stack perdano quattro o cinque kb quando cambi tema dei cursori, ma è una cosa che va chiusa in XFixes non nelle gtk+. se usi valgrind sulle gtk+ vedrai delle perdite che neanche un idraulico - ma sono fasulle, e dovute allo slice allocator usato; lo spazio viene reclamato alla fine dal kernel, e non ci sono problemi.
@fedalmor:
il desktop semantico è una soluzione alla ricerca di un problema. taggare i file e cercarli in base (anche) alle tag va bene; fare il rating dei file (!) e infilarci note è un’idiozia.
@ossblog:
il primo suggerimento dei dieci è il più stupido - e lo dico io che non sopporto l’acronimo da anni, solo mi rendo conto che ormai non si può più cambiare perché il riconoscimento e il marchio sono stabiliti negli utenti. i restanti nove sono paccottiglia assolutamente inutile o specifica per distribuzione (desktop effect è una roba ubuntu, non GNOME upstream).
@arael:
prima di xrandr 1.2 non era possibile manipolare i dati e le geometrie dei monitor a runtime, se non conoscendo come funzionano le schede grafiche (e, guarda caso, solo i driver proprietari ci riescono); adesso è possibile, almeno con driver open - e le gtk+ stanno per avere delle funzioni per chiedere ai monitor la loro geometria e come orientarli; le GUI per la configurazione arriveranno (alcune già esistono, ma usano chiamate X dirette e vi assicuro che non è divertente).
@hardskinone:
si fa quel che si può per le prestazioni. se hai problemi specifici, fai del profiling e apri bug.
infamous
30 giu 2007 - 11:58 - #17@Emmanuele perchè sarebbe un idiozia avere note e rating come metadati? Sul rating posso anche capirlo, ma le note credo possano essere anche molto utili, penso ad un archivio multimediale per esempio.
Emmanuele
30 giu 2007 - 13:30 - #18le note e i rating hanno senso se e solo se condividi con altri utenti; per esempio, io aggiungo note, tag e rating a foto su flickr e a canzoni su last.fm. ma nella mia collezione, che uso solo io, perché dovrei mettere delle note sui miei file? e soprattutto, perché metterli su tutti i file?
*Gian*
30 giu 2007 - 13:50 - #19@Emmanuele+ilGufo
Scusate non sapevo che quella funzione “drag&drop” fosse un brevetto.Peccato, perchè come funzione la trovo comoda.Imparato qualcosa di nuovo: grazie.
@Emmanuele
A leggere sul forum di Ubuntu e anche su altri no ubuntizzati non sono l’unico che si “lamenta” che nautilus non sia velocissimo. Io quando apro la cartella: /usr/sbin (243 file) il mio laptop diciamo che soffre e ci impiega ad occhio 2/3 secondi, se apro /usr/bin invece rischio i pianti (qui i file però sono molti). Non so se dipenda dalla distribuzione in uso (ubuntu) o dal mio laptop o da cosa. Io entro le mie possibilità ho cercato di ottimizzare il mio sistema e tutto but no way. Questa è la mia esperienza di utente.
Just my 2 cent.
ilgufo
30 giu 2007 - 15:02 - #20effettivamente succede anche a me lo stesso che succede a *Gian* con nautilus… ma a parole e’ facile, pero’ realmente non credo… anche konqueror che tutti vantano per la sua velocita’ come fm (secondo me non lo e’ molto) fa lo stesso… idem per thunar
non so fino a che punto dipenda dal file manager ecco.
ossmlcr
30 giu 2007 - 15:18 - #21L’apertura lenta delle directory può anche essere un problema del filesystem sottostante: ad esempio ext3, che è un FS di tipo UFS con gli inode allocati separatamente dagli indici delle directory, può richiedere moltissimi accessi su disco per poter leggere il contenuto di una directory (potenzialmente se hai N files può richiedere fino ad N seek/read separati - ma dipende ovviamente da quanto è frammentato lo spazio degli i-node rispetto a come sono referenziati nella directory).
Mi ricordo ad esempio, quando avevo usato un pò di tempo fa reiserfs, di averlo trovato quasi istantaneo ad aprire directory di qualsiasi dimensione: non ne sono sicuro al 100%, ma la motivazione della lentezza potrebbe essere questa.
ossmlcr
30 giu 2007 - 15:20 - #22ha, dimenticavo: la differenza di reiserfs (e xfs, ntfs e forse qualche altro fs) è che ha gli i-node “fusi” nel descrittore della directory: per enumerare una directory è sufficiente leggere le direntries senza ulteriori letture su disco.
*Gian*
30 giu 2007 - 18:09 - #23@ilgufo + @ossmlcr
*Gian*
30 giu 2007 - 18:19 - #24@ilgufo + @ossmlcr
Sì anche a me rimane il dubbio amletico se il collo di bottiglia sia il file manager o il file system. Io se sullo stesso pc installo xubuntu ho l’impressione che thunar sia più veloce ma non di tanto. Mi piacerebbe provare a vedere se cambia qualcosa con Reiserfs, XFS o JFS.
PS
Scusate per il post precedente mi è partito così
infamous
30 giu 2007 - 22:56 - #25@emmanuele beh su tutti i file certamente non ha alcun senso, ma metti caso dovessi fare una ricerca prendendo in esame un numero considerevole fra testi/musica/film. Nella fase preliminare potrei taggare e mettere delle note su quello che mi interessa (magari anche concetti più complicati di quelli che si possono attribuire attraverso un tag) direttamente sul file e poi poter accedere ai media semplicemente cercando le note che ho scritto.
Faccio un esempio stupido, se avessi da fare un lavoro di ricerca su di un argomento X, potrei attraverso le note esprimere sinteticamente come l’argomento X viene trattato e se ci sono peculiarità, in modo poi da arrivare al film attraverso quello che voglio (cerco il dato media che tratta X in modo Y e il mio amico computer mi fa vedere tutti i file che ho taggato/descritto in quel modo).
Ovviamente, come dici tu, se ci fosse la possibilità di condividerle sarebbe tutto su un altro livello, ma anche l’suo privato imho può avere dei vantaggi.
Emmanuele
01 lug 2007 - 00:54 - #26@gian
/usr/bin e sbin sono directory problematiche: generalmente contengono solo binari, e il “file sniffing” per sapere di che file si tratta è lento - non essendoci estensioni per fare il primo passaggio “alla brutalona”. purtroppo non si può dire “okay, ha il bit eseguibile impostato, è un eseguibile quindi non chiedere oltre” dato che se monti un volume fat (senza cambiare l’umask) ti becchi tutti i file con bit eseguibile impostato.
così come il tizio che va dal dottore lamentandosi che il braccio gli duole quando lo muove e si sente rispondere dal dottore di non muoverlo, il consiglio che posso dare è solo: non aprite /bin, /sbin, /usr/bin e /usr/sbin con nautilus.
ossmlcr
01 lug 2007 - 08:12 - #27Allora un’idea per GNOME può essere questa: una cache user-owned salvata su disco che contiene le associazioni {nomefile/mimetype/data_ultima_modifica} caricata nella NautilusFileDetails, così da non dover sempre rileggere tutti i files nell’HD quando lo si visita.
-> anche se forse è brevettata anche questa strategia…
Emmanuele
01 lug 2007 - 12:01 - #28Allora un’idea per GNOME può essere questa: una cache user-owned salvata su disco
che devi leggere, quindi devi andare sul disco, quindi hai perso. :-)
la memoria di massa è il punto debole di tutte le operazioni, perché è di svariati ordini di grandezza più lenta della memoria. in più, nautilus è un solo processo, quindi non si può nemmeno chiedere al kernel di dare una mano via mmap().
purtroppo, o si prendono scorciatoie via euristiche, che però non sono affidabili al 100% (in quanto euristiche) oppure si aspetta qualche secondo.
Emmanuele
01 lug 2007 - 18:27 - #29oh, non avevo visto il commento #7
@Riccardo:
quella è una cosa che puoi fare con fontconfig - basta modificare il file di configurazione. personalmente, trovo i font di windows inguardabili, ma ognuno è libero di farsi del male nei modi e nelle forme che crede. ;-)
*Gian*
02 lug 2007 - 12:46 - #30@Emmanuele
Grazie per la spiegazione.