Newsgroup: it.comp.os.dibattiti
Titolo: Date uno sguardo a segusoLand? (un nuovo file manager).

Ciao a tutti!
Volevo chiedervi un'opinione su questo file manager FREE che sto
programmando (screenshot e download a 
http://segusoland.sourceforge.net
).
Non è la solita cosa :-) . segusoLand incorpora un nuovissimo paradigma
di interazione. Un nuovo modo di specificare cosa vuoi fare.
Io già lo uso. :-)
Se poi qualcuno può aiutare con il codice... io da solo non posso fare
più di tanto.
Ciao e auguri!
(Sono stato via per un po', ma non con le mani in mano)
-- 
Best Regards,
Maurizio Colucci
Please remove the uppercase letters "S,P,A,M":
seSgPuAsM...@tin.it

 più di tanto.
L'idea potrebbe essere interessante, se sviluppata per benino, ma l'UI e'
terribile (senza offesa, naturalmente).
Al di la' dell'ergonomicita' della stessa (dimmi, quanto ami la rotellina
del mouse ? :)) potevi tranquillamente implementare il tutto all'interno
di nautilus, con la *sua* interfaccia, che mi sembra estremamente piu'
comoda e curata, senza tutte quelle liste.
Potevi, a dir la verita', basarti sui tipi di files, dato che, anche se al
momento Nautilus non ha nulla di simile al tuo 'verb oriented', se metto
il mouse su un file mp3 il file mp3 parte, senza avviare null'altro
(credo, dovrei studiarla).
Io definirei sulla sinistra (dove c'e' "informazioni", "simboli" ecc.)
una listbox contenente i tuoi verbi, che risale l'albero delle directory e
in base ai tipi avvia il programma adatto, sul device adatto,
semplicemente aggiungendo, come avviene nel fm.
HAND,
  nicholas

 programmando (screenshot e download a 
http://segusoland.sourceforge.net
).
L'idea e` molto molto bella. Ma l'interfaccia grafica e` troppo
confusionaria e frammentaria, sembra buttata li` finche` qualcuno non
pensera` a riordinarla nel modo adatto.
Per il resto io lo trovo vermente un ottimo progetto. Ovviamente
opinione personale, io continuo pero` a preferire la shell perche`
sono piu` veloce, questo comunque potrebbe essere un validissimo
sostituto per molti file manager.
-- 
Valentino Volonghi, Regia SpA, Milan
Linux User #310274, Gentoo Proud User

 pensera` a riordinarla nel modo adatto.
Il problema è come...


 Il problema è come...
Come ti e` gia` stato suggerito, prova a integrarlo in nautilus e se
trovi chi ti appoggia il progetto scommetto che lo vedremo nel
prossimo gnome :)


 semplicemente aggiungendo, come avviene nel fm.
Grazie!


 (Sono stato via per un po', ma non con le mani in mano)
Direi che hai fatto qualcosa di notevole e secondo me ha i mezzi giusti per
finire sulla Gnome (la 2.6 no di sicuro ma la 3 magari si :)
-- 
Lawrence "Rhymes" Oluyede
http://loluyede.blogspot.com

 prossimo gnome :)
Io non sono dell'idea di integrarlo in Nautilus... Non so quanto
l'integrazione con quel coso possa aiutare il suo programma. Io invece
lo terrei un tool a parte, un bel file manager, funzionale e veloce...che
non debba avere nulla a spartire con quel bisonte di nautilus o altri
FM belli grossi. 
x seguso:
Magari dopo provo ad installarlo e ti faccio sapere come "mi sembra" :)


 finire sulla Gnome (la 2.6 no di sicuro ma la 3 magari si :)
Speriamo, così posso smettere di lavorarci io :-P


 pensera` a riordinarla nel modo adatto.
Ho allegerito un po' l'interfaccia. Potresti riguardare gli screenshot
e dirmi se ora è meglio? 
(Più di questo non saprei cosa fare...)
Grazie ancora,


 Magari dopo provo ad installarlo e ti faccio sapere come "mi sembra" :)
Grazie mille! dovrai installare gtkmm e un altro pacchetto, ma č tutto
spiegato nel file INSTALL.


 programmando (screenshot e download a 
http://segusoland.sourceforge.net
).
Anche se come utility non fa per me, sembra proprio un bel lavoro.
Trovo anch'io che tutte quelle listbox siano ridondanti e non proprio
piacevoli alla vista.
Il più grande dubbio che ho riguardo questo file manager concerne la sua
espressività... pochi thread fa si parlava di shell object-oriented e
questo file manager, pur cogliendo alcuni aspetti essenziali del problema,
mi sembra limiti le attività a quelle esprimibili con (al massimo)
un'azione, un file, un programma, un device e un timing. Possiamo fare di
meglio?
Saluti.
-- 
\/               
wirix...@libero.it
          ICQ UIN: 3233084
/\ e l l o s s   (per rispondermi in privato, elimina il DEMONE)

 tutto quello che non ha senso con la selezione corrente).
Che strutture dati hai usato?
Forse se all'avvio fossero selezionabili soltanto sottoinsiemi selezionati
delle attività e dei programmi disponibili, si potrebbero migliorare i
tempi di risposta.


 Speriamo, così posso smettere di lavorarci io :-P
Eheh


 e dirmi se ora è meglio? 
Ok ma io sistemerei ancora una cosina: quando ho completato il processo
di selezionamento (verb e roba varia) il GO esce da parte alla risorsa
iniziale...mi sembra un po` scomodo dato che con tutta probabilita`
il mouse si trovera` dall'altra parte dell'interfaccia...


 un linguaggio che mi ha cambiato la vita!
Un linguaggio fantastico ma il codice generato non risulta, ehm, 
pesantuccio?
Non che conosca poi molto del prolog, anzi, ma su macchine deterministiche
quanto potrà essere efficiente?
(Sia chiaro, non critico la scelta, il progetto è tuo e usi il linguaggio
che preferisci; però vedere un programma del genere scritto in prolog mi
sorprende parecchio ^^;)
Saluti.
-- 
\/               
wirix...@libero.it
          ICQ UIN: 3233084
/\ e l l o s s   (per rispondermi in privato, elimina il DEMONE)
***      La macchina di Turing ha un baco nel programma      ***
***             e noi l'aggiusteremo con il C++!             ***

 Alla faccia del qualcosina... il mio pc sta compilando boost ;-)
Sei un grande, lo stai provando davvero!
(fai cvs update)
grazie


 pesantuccio?
Ora devo andare, ti rispondo stanotte! :-)


 (Più di questo non saprei cosa fare...)
Troppi bottoni IMHO. Ci vuole una configurazione per settare quelle
cose li`. Magari una finestra che si puo` attaccare a questa e che
contiene le varie opzioni in modo generale.
Inutile avere "sort by:" ripetuto sotto due finestre o i tasti sopra e
sotto che sono un po` scomodi. Poi dispatch cosa significa e che altre
view possono essere disponibili?
L'interfaccia dovrebbe poi prevedere un tasto "Ok" per confermare
quello che vuoi fare e non per forza il doppio click ad esempio.
Insomma... Io l'interfaccia base la fare con 1 tasto ok e con solo le
4 listbox (magari quella con i verbi la farei come combobox).
Comunque e` molto bello e te lo ripeto :).  Prova a chiedere a quelli
di xfce magari, il loro filemaganer ha il vantaggio di integrarsi alla
grande con samba ma per il resto e` ben lungi dall'essere cosi`
usabile, assomiglia al tuo e se il tuo lo fai cosi` sicuramente potrei
iniziare a usarlo.
Non riesco ad aiutarti nel coding perche` io preferisco python,
altrimenti lo farei sicuramente al volo. Magari se esistesse qualche
binding per prolog in python, ma non sarebbe una bella cosa.


 (fai cvs update)
Fatto! ciao


 meglio?
Per la verità, puoi specificare più di un file, device, tempo, ecc (poi
è la semantica del verbo che decide cosa succede e se questo è ammesso).
Ad esempio il verbo rename non ammette più di un file. il verbo
add-to-multiple-archive non ammette meno di due file.
Si può fare di meglio? Sarò limitato, ma non vedo cosa serva più di
questo... cioè, è raro che serva un argomento che non sia né un verbo,
né un file, né un device, né un programma, né un tempo. Se serve
qualcosa in più (tipo la qualità di stampa nel verbo 'stampa'), si
chiede con una dialog box, dopo che l'utente ha premuto "go".


 tempi di risposta.
Si può già fare (con tasto change view puoi visualizzare solo un
sottoinsieme dei file). Ma anche se visualizzi tutti i file, i tempi di
risposta non lasciano a desiderare.
Se fosse necessario, potrei ottimizzare sfruttando la coerenza
temporale... ma non ne sento l'esigenza per ora.
ciao :-)


 quanto potrà essere efficiente?
Per quel che so, se stai attento, ottieni algoritmi con la stessa
complessità (asintotica). Se non stai attento il backtracking ti può
fregare...


 binding per prolog in python, ma non sarebbe una bella cosa.
Grazie lo stesso!


 il mouse si trovera` dall'altra parte dell'interfaccia...
Forse vuoi dire che, se selezioni il verbo per primo, poi è sciocco che
il tasto go appaia vicino al verbo, perché ti costringe a tornare col
mouse vicino al verbo?
ok, ma non so come evitarlo. Potrei fare apparire un tasto GO accanto ad
ogni file, device o programma, ma sarebbe troppo pesante graficamente...


 ogni file, device o programma, ma sarebbe troppo pesante graficamente...
Ok lascialo pure com'è :) Io devo ancora rodare l'interfaccia :)


 altre idee per ottimizzare è benvenuto :-)
Sono sicuro che se si può fare di meglio in C++ si può fare di meglio
anche in prolog ;-).
Saluti!


 all'elemento su cui si indicizza perché influenza le prestazioni...
Sarebbe bello sceglierlo, ma swi-prolog indicizza sul primo.
ciao


 selezionare anche per primo.
L'utente a cui vuoi indirizzarti non le coglie queste finezze :).
Mo lo scarico e lo uso un po`, arriveranno altri commenti e se sei
fortunato mi metto a programmarci un po` sopra con i binding di prolog
per python (che sapevo esistessero e se non viene una schifezza... :))


 Sarebbe bello sceglierlo, ma swi-prolog indicizza sul primo.
Non puoi semplicemente cambiare l'ordine delle colonne? Ho l'impressione
che indicizzando sul limitato insieme {file, verb, ...} l'elevato numero
di collisioni degradi le prestazioni della hash table a quelle di una
lista.
Saluti.
-- 
\/               
wirix...@libero.it
          ICQ UIN: 3233084
/\ e l l o s s   (per rispondermi in privato, elimina il DEMONE)


 lista.
interessante.
Posso cambiare l'ordine, ma dovrei fare un grosso refactoring. Infatti
mi pare che per motivi tecnici il file vero e proprio (file.pdf) debba
essere l'ultimo argomento.
(Se vuoi sapere perché: è perché uso predicati parzialmente applicati
come argomento di altri predicati.
Cioè ho un predicato A che prende come argomento un file F e un predicato
B, e poi verifica se vale B(F). Questo si può fare solo se F è l'ultimo
argomento)


 come argomento di altri predicati.
Anche se non sapevo che si potesse fare, non mi sorprende per nulla che il
prolog sia higher order ;).


 a capirci qualcosa) perché non vorrei farti fare un lavoro inutile :-).
Grazie :-)
Uno dei pregi del prolog č che il codice č leggibilissimo.
Se ti serve commit access dimmelo!
'notte!


 finire sulla Gnome (la 2.6 no di sicuro ma la 3 magari si :)
Sicuramente no.
Nautilus e' integrato, e aggiungere le funzionalita' di questo FM a
Nautilus e' di diversi ordini piu' semplice che integrarne uno nuovo di
pacca.

 FM belli grossi. 
Mah, Nautilus fa X cose in piu' e non e' piu' cosi' pesante da almeno un
anno e mezzo. Forse puoi cominciare a usare Gnome 2.
HAND,
  nicholas

 non si può decidere...
Ma come no ? Mandi un mp3 sulla stampante ? :)
Vuoi usare un'altro device ? Il programma che avvii e' d'accordo, o
duplichi l'operazione ? Se ad esempio ho una stampante normale e una pdf
non e' il programma stesso a darmi la scelta ?
HAND,
  nicholas

 stesso a darmi la scelta ?
Certo, farai la scelta due volte, finché i programmi non saranno
riscritti... :-)
grazie del tuo tempo!
M


seguso <lo...@in.signature> writes:
Rispondo qua prima di andare a letto... sigh il tuo programma mi ha
preso piu` di quello che pensavo :).
Dunque: Interfaccia da riscrivere da 0, IMHO :). So che e` drastico ma
troppi bottoni, vanno veramente pensati in modo diverso, e tra l'altro
alcuni ancora sono riuscito a capire a cosa possano servire, figurati
cosa puo` pensare un novello una volta che li vede...
Nomi non standard nei tasti... L'utente vuole leggere "Cancel" o
"Annulla" o "Ok", non "forget it" o "Go". Ormai si e` abituato ai
Cancel e Ok e quelli devono restare, sa che con Cancel e` come se non
avesse fatto nulla e che con Ok conferma quello che vuole fare.
Devi usare un unico pulsante Ok, nel caso resti deselezionato il verbo
allora apri una dialog di selezione del verbo interessato.
I device non servono, puoi fare con delle dialog, nello stesso modo
con cui usi il tasto Ok.
Le dialog che apri ora poi sono troppo grosse, devono essere 1/4 al
massimo del monitor e devono stare in alto a sinistra appena sotto il
bordo del tuo filemanager (se questo e` in primo piano e completamente
dentro i bordi dello schermo, altrimenti solo in alto a sinistra con
un buon margine di 100/150 pixel).
Quei sette tasti sotto sono, a mio avviso, molto piu` utili dei tasti
sopra e dovresti come minimo riunirli in una toolbar.
All programs contiene troppe alternative allo stesso
programma... Dovresti usare un solo programma per ogni tipo di file,
in GNOME questa cosa esiste gia` perche` se non erro ci sono variabili
d'ambiente che richiamano il player, o il browser e via dicendo.
Per fare questo usi un file di configurazione se possibile.
Dispatch e change view li trovo oltremodo superflui, credimi. Spostali
dal di li` :), infila la funzionalita` in un altro modo.
Inutile avere Recent views, molto meglio avere il sort by con opzione
"most recently used".
Trovo macchinoso il dover aggiungere cartelle... Il FM deve gia`
sapere in che cartelle andra` a parare. 
Anche show lo trovo "sistemabile" con un sistema di configurazione.
IMHO, e` buona norma mettere i bottoni _SOTTO_ al widget a cui si
riferiscono. Io ho visto Add e ho pensato servisse ad aggiungere
devices come bisogna aggiungere i files/dirs. Invece poi ho capito che
era per i timing.
Inoltre devi trovare un modo piu` semplice di distribuire
l'applicazione secondo me, ci sono veramente molte dipendenze inusuali
e molti utenti che vorrebbero usare il tuo filemanager perche` ne
apprezzano l'idea rimarrebbero un po` spaesati, dovresti cercare di
fare qualcosa che abbia bisogno di pacchetti piu` usati e comuni o,
purtroppo (per te ovviamente), un linguaggio piu` comune.
Non riesci a fare tutto in C o C++? O ancora meglio python (cosi` ti
aiuto io, tanto mi sa che alla fine ti copio e qualcosina la scrivo
direttamente in python e vedo come viene fuori)?
Ora devo veramente dormire che tra 1 ora e mezzo devo svegliarmi :P.
Queste sono le prime cose che mi sono balenate per la testa, potrebbe
esserci molto di piu` magari. Per ora buon lavoro.


 programmando (screenshot e download a 
http://segusoland.sourceforge.net
).
Impressione visiva: troppe liste.
L'idea alla base è interessante: immagino tu usi il MIME-Type di un file
per poter associare un verb ad un filetype.
Il mio consiglio è: togli la lista dei verb, e mettili in un context menù
che si apre con un evento sul mouse; ridurrebbe il carico visivo
sull'utente, e potrebbe comunque essere accessibile con un evento
'popup' (Shift+F10).
Una cosa del genere la vogliono fare anche in Nautilus: potresi portare
il tuo codice, e dare una mano (forse addirittura è incluso nelle
Bounty, così guadagneresti pure qualcosa).
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)                 [ 
http://www.emmanuelebassi.net
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 pacca.
Vabbe` fate vobis, a me Nautilus non piace quindi non amo
l'idea che il suo bel fm finisca dentro Nautilus ma non e`
una decisione che devo prendere io


 anno e mezzo. Forse puoi cominciare a usare Gnome 2.
Sono passato da Gnome2 a XFCE perche` ritenevo Gnome2 ancora
un po` pesante :) So che sono stati fatti dei passi da gigante ma Nautilus
non mi era sembrato granche`. Senza contare il fatto che Gnome ha quel file
selector che proprio non mi piace. 
Ora con XFCE uso praticamente solo la CLI e quindi ho praticamente
smesso anche di lamentarmi ;-)


 esserci molto di piu` magari. Per ora buon lavoro.
Grazie moltissimo. Mi metto al lavoro!


 Una cosa del genere la vogliono fare anche in Nautilus: 
non lo sapevo... ho scritto sulla mailing-list ma gli sviluppatori di
gnome tacciono su questo...


 gnome tacciono su questo...
Bisogna cercare un po' in giro negli archivi. Qualche cosa si trova
anche sui blog degli sviluppatori.


 User-friendly non vuol dire riempire lo schermo di roba. ;-)
Eh, qui entriamo nel filosofico. :-) Ora riderai, ma ti dico che io sono
fermamente contrario al tasto destro, al drag-n-drop, al doppio click, al
tenere premuto, ai pulsanti piccoli, e pure ai menu per le azioni
frequenti. Il mio programma riflette queste convinzioni. :-).
Se il costo di rinunciare a tutte queste cose č mettere 100 pulsanti, li
metto.
Grazie mille


 troppi bottoni,
Potreste dirmi se ora va un po' meglio con il layout?
http://segusoland.sourceforge.net
(grazie e scusate la rottura di scatole)
PS: Tenete conto che la toolbar IN BASSO andrà via e diventerà un menu.
Fate finta che non ci sia. La toolbar in altro invece resta...


 
http://segusoland.sourceforge.net
Lo trovo decisamente piu` usabile...anche se sbatterei 
tutta la roba della toolbar in basso in un menu.
ciao!


 tutta la roba della toolbar in basso in un menu.
È proprio quello che voglio fare! Ok allora. :-) 


 Potreste dirmi se ora va un po' meglio con il layout?
Decisamente meglio ora. Da cambiare "Go" con "Ok", ma devo ancora
aggiornare il codice in locale e poi provarlo.


 tutta la roba della toolbar in basso in un menu.
Fatto!
 
http://segusoland.sourceforge.net/screenshots.html
Ora viene il brutto: rilevare i device presenti nel computer...
Qualcuno sa come fare?


 <icq:241572242>
But still I fear, and still I dare not
Laugh at the mad man (The Prophet's song)

 Qualcuno sa come fare?
Non ne ho la piu` pallida idea, in Windows so che in linea
di massima e` possibile ma in Linux non saprei proprio come fare


 /dev...
Forse e` meglio proc, io ho defvs ma in dev ho mille mila device
che non uso... non so se mi spiego.


 Qualcuno sa come fare?
Su Linux, co i kernel 2.6, hai sysfs a disposizione. Altrimenti... penso
lspci e lsusb per i due bus, poi /proc per altri dati (scsi, memoria,
etc).


 che non uso... non so se mi spiego.
La stragrande maggioranza sono symlinks ai veri device --- la 
compatibilità è necessaria --- quelli si possono riccamente ignorare.


 /dev...
Grazie mille. Scusa, devfs è quella cosa che torvalds aveva deprecato?
Quindi non mi interessa, vero?
Dove posso trovare un po' di documentazione? 
www.linux.org
 suppongo... :-)


 etc).
Ommioddio... mi sento già male con tutte queste sigle. Grazie


 Dove posso trovare un po' di documentazione? 
www.linux.org
 suppongo... :-)
Si, anche se la struttura del devfs è simile al procfs, tipo
/dev/ide/0/...
molto regolare.


 Non direi... alla fine sarà il devfs a vincere.
devfs ruleggia, e non capisco come faccia ad esserci gente che ci dia
contro :P
-- 
il *Vide* - ICQ #5301833
Powered by Gentoo
http://www.heavy-metal.it

 contro :P
Comprendo questa avversione, ma solo per macchine mission critical... io 
ne uso solo una, ma non ha linux :( ha AIX...
Altrimenti, il devfs è una vera chicca :)


 Quindi non mi interessa, vero?
Mmm in Gentoo e` abilitata di default, quindi ti interessa :P
Inoltre molti lo usano che io sappia anche se io prima di gentoo
non l'avevo mai usato devfs


 non l'avevo mai usato devfs
devfs e` morto e sepolto. Ora come ora e` stato ridotto al minimo del
minimo per mantenere compatibilita` col passato. Il suo sostituto
sara` decisamente meglio.
udev+sysfs+hotplug
Detto questo NON basarti per nulla su /proc, ma proprio per
nulla. Guarda i sorgenti del kernel e linkati a quelli. 
Torvalds addirittura non considera minimamente quei programmi che sono
scritti guardando a proc perche` probabilmente anche lui se ne andra`
(o comunque cambiera` parecchio) con l'arrivo di sysfs e udev.
Occhio quindi a fare le cose per bene, soprattutto visto che usi C++
non dovrebbe essere troppo difficile.


 un po' all'antica).
Io e te non saremo mai d'accordo... Il principale mantainer di devfs
se ne e` andato dicendo che piu` di cosi` non poteva fare, chi l'ha
sostituito nei kernel 2.5 ha detto altrettanto. I limiti strutturali e
di design di devfs sono giunti alla fine e sara` giustamente
sostituito da qualcosa che fara` le cose meglio.
Tra l'altro il passaggio da devfs a udev e` quasi indolore, previa
installazione di sysfs-utils e udev (ora alla versione 011), e un
kernel configurato a modo. 
Nessun motivo per usare qualcosa che per gli stessi sviluppatori e`
insviluppabile.


 non dovrebbe essere troppo difficile.
Perche` non gli dici di usare gli interrupt in assembler? Forse e`
piu` semplice :)


 non dovrebbe essere troppo difficile.
Grazie, ci penserò. D'altronde io devo soltanto sapere il modello
dei device... cioe, il nome... e forwardarlo brutalmente ai programmi che
lo richiedono (che per ora non esistono :-))
Non sarà come sparare a una mosca col fucile?
Ultima domanda: non è che sai come enumerare le videocamere usb? :-)


 insviluppabile.
Si, ok, ma finchè non ci sarà qualcosa di stabile nel kernel... neanche 
nel 2.6 ci sarà udev, dunque o metti i vecchi devices oppure usi il devfs.


 (o comunque cambiera` parecchio) con l'arrivo di sysfs e udev.
Torvalds non dice sempre cose buone, dal mio punto di vista. Se dovessi 
fare qualcosa di simile a seguso, certamente considererei procfs come 
una valida soluzione, altrimenti, sarebbe meglio che lo buttassero al 
cesso... ma visto che il suo sviluppo non è morto 10 anni fa...
Per sysfs e udev, chi vivrà vedrà. E' prematuro parlarne --- a meno che 
qui qualcuno non l'abbia messo in piedi...


 che qui qualcuno non l'abbia messo in piedi...
Io l'ho messo in piedi e funziona, pero` non ho toccato il file di
configurazione e invece dovrei farlo per settare correttamente i
device della scheda audio e via dicendo.
Ora comunque sono tornato a devfs perche` non ho voglia di stare a
configurare quando devfs l'ho gia` configurato da tempo.
Gentoo tra l'altro supporta udev con l'ultima versione del baselayout
e i progetti di migrazione sono pronti, si aspetta che udev sia pronto
per un uso serio, ancora non supporta tutti i device ed e` un po`
immaturo, nulla di strano da un progetto con pochi mesi.


 devices oppure usi il devfs.
udev non e` nel kernel, e` userspace. Ha bisogno di RAMFS (su cui
viene montata /dev), procfs e di sysfs dal kernel (e dell'assenza di
devfs). Il resto (hotplug, sysfsutils e udev vero e proprio) sono tool
userspace.
Ora come ora comunque e` vero che udev non e` completo, appena lo
sara` pero` non ci saranno motivi per mantenere devfs visto che il
primo puo` ricopiare il naming standard del secondo.
